Subject: Call for presentations

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 18 Jun 2003 09:33:06 +0200

With this mail I would like to ask for presentations for the first slot 
of the multi6 WG.

Please send me

- - Presenters name
- - Draft name
- - Rough time estimate needed

Again, please note that this is not supposed to be a in-depth 
presentation of your proposal (or multi6 related draft) it is supposed 
to be a opportunity to give an overview, make clarifications and ask 
questions.

Best regrards,

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Jun 2003 09:36:33 +0859 ()

Kurt;

> With this mail I would like to ask for presentations for the first slot 

When will the presentations for the second slot be requested?

> to be a opportunity to give an overview, make clarifications and ask 

How are the differences between the first and the second slots?

> - - Rough time estimate needed

Will do so, after it is clarified to which slot should we make
presentations.

							Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Jun 2003 18:38:28 -0700

> Will do so, after it is clarified to which slot should we make

that all depends on what your presentation is, does it not?

randy

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Jun 2003 12:34:51 +0859 ()

> that all depends on what your presentation is, does it not?

We, for example, have a topic on a completed design of multi6
solution.

But, I'm asking what presentations are called for for the
second slot.

Or, do you mean any presentation is acceptable for the second
slot?

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 20 Jun 2003 18:25:04 +0200

> When will the presentations for the second slot be requested?

To be honest, I have not planned on making a specific announcement for 
the second slot.

> How are the differences between the first and the second slots?

Our intention is to use the first slot for presentations on multi6 
related topics (architecture, solutions, cookie recipes, what you want) 
. If we have a serious problem with time in the first slot we can let 
that spill into the second slot(currently this does not seem to be an 
issue), but the second slot is meant  for discussions on how we should 
move forward and what the architecture should be. So the first slot is 
to be seen as input for the second one. Note that we expect the design 
team to present their work in the second slot as well. Generally the 
second slot is more to be seen as "open mike" tough. And also 
discussions on new milestones, charter etc. But that will be last and 
more administrative.

Hope this clarifies the intentions of the agenda a bit.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 20 Jun 2003 18:27:24 +0200

> We, for example, have a topic on a completed design of multi6

First slot.

> Or, do you mean any presentation is acceptable for the second

No, we are hoping to have a discussion on the way forward in the second 
slot (in terms of architecture - if you think that me and Sean are 
doing a poor job and should start growing tomatoes instead you will 
have to talk to us and Randy in the bar ;-) ).

Best regards,

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 23 Jun 2003 09:24:35 +0200

I will add them. 15 mins per draft sounds a lot to me, but that will be  
subject to total time used.

Best regards,

- - kurtis -

On måndag, jun 23, 2003, at 09:17 Europe/Stockholm, FUJIKAWA Kenji  
wrote:

> Kurt;
>
> We have already submitted internet-drafts that are related
> to multi6 WG. They can be downloded from
> 	http://www.users.kudpc.kyoto-u.ac.jp/~r52802/draft-ohira-assign- 
> select-e2e-multihome-00.txt
> and
> 	http://hage.tori.cc/~arifumi/draft-arifumi-lin6-multihome-api-00.txt
> , and will be downloded from ftp.ietf.org soon.
>
> We would like to make presentations abount them, so would
> you assign slots for us? We'll be glad if you assign 15min
> for each draft.
>
> FYI, we now manage more than 200 wireless APs based on
> 802.11b in Kyoto city, Japan, and all of them supports
> IPv6. We are also planning to multihome them. I believe our
> platform is the largest IPv6 wireless environment in the
> world, and will be the largest wireless multihomed
> environment.
>
> The followings are detailed information on drafts:
>
> ID:        draft-ohira-assign-select-e2e-multihome-00.txt
> Title:     IPv6 Address Assingment and Route Selection
>            for End-to-End Multihoming
> Speaker:   FUJIKAWA Kenji (Kyoto University)
> Abstract:
>    IPv6 suppose that network is hierarchical. Though the present IP
>    network topology is not hierarchical at the point of multihoming.
>
>    In this document, we clarify that
>     a) how to assign address blocks to ISPs and sites in order to
>        achieve multihome environment without destroying hierarchical
>        structure of IPv6
>     b) requirements in order for end hosts to select an adequete route
>        from multiple routes when multihoming.
>
> ID:        draft-arifumi-lin6-multihome-api-00.txt
> Title:     Basic Socket API Extensions for LIN6 End-to-End Multihoming
> Speaker:   Arifumi Matsumoto (Kyoto University)
> Abstract:
>    This document describes a method for multihoming support in
>    application layer.  We extend the basic socket API(Application
>    Programming Interface) and propose some new interfaces for
>    multihoming.  Multihoming nodes are expected to have multiple
>    addresses.  The existing socket APIs, however, are not designed to
>    manipulate multiple addresses in a connection.  Proposed APIs help  
> an
>    application to handle multiple addresses, to avoid connection  
> failure
>    and to do load-balancing possibly.  Right now, the proposed APIs are
>    for LIN6 nodes, one of the mobile protocols.  This is because LIN6's
>    addressing architecture, which is called "8+8", is very friendly and
>    consistent with multihoming.  In this document, we propose a host-
>    based multihoming solution and which is called end-to-end
>    multihoming.  In end-to-end multihoming, a fault-tolerant connection
>    can be achieved relying not on routers but on the pair of end-nodes
>    only.
> ---------------------------------------------------------------
> FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
>  WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html
>                         TEL +81 75-753-5387 FAX +81 75-751-0482
>                               E-mail [email-masked]
>

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Mon, 23 Jun 2003 16:17:30 +0900

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Kurt;

	http://www.users.kudpc.kyoto-u.ac.jp/~r52802/draft-ohira-assign-select-e2e-multihome-00.txt

   manipulate multiple addresses in a connection.  Proposed APIs help an
   application to handle multiple addresses, to avoid connection failure

---

From: marcelo bagnulo <[email-masked]>
Date: 23 Jun 2003 18:10:02 +0200

Hi,

I have some questions about draft-arifumi-lin6-multihome-api-00.txt.

I fail to understand the idea behind this proposal.

I mean, if i understand correctly, the draft proposes an API that it is
capable of handling the multiple address that result when a site is
multi-homed and it uses PA addresses.

However, it seems somehow linked to LIN6 (LIN6 is mentioned multiple
times in the document), but i fail to understand how. AFAIK LIN6 maps
multiple different addresses in a single address, making the change of
address transparent to transport layer and above.

So LIN6 handles multiple addresses in the IP layer making it transparent
to upper layers and the proposed draft proposes a way to handle multiple
addresses. How is this compatible? i mean the upper layers, see one LIN6
address or multiple addresses?
If the upper layers are aware of the multiple address, what do you need
LIN6 for?

An additional question is about address discovery. I mean how do the end
nodes find out what addresses are available at the other end? There is a
mapping agent mentioned, but where is this mapping agent located? which
addresses does it announce? all the available addresses or just the ones
that are reachable at the moment? if the latter, how does it find out
whether an address is reachable or not?

Another question is related to security, i.e. how do you authenticate
the addresses actually belong to the node that is claiming its
ownership? This is a very important and difficult issue as far i can
tell, and it should be addressed.

Finally, how the multi-homed node communicates the alternative address
to be used when the address that is being used fails? 

I hope you clarify these issues to me, thanks, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 24 Jun 2003 01:08:46 +0859 ()

Kurt;

Masataka Ohta
> - - Draft name
draft-ohta-multihomed-isps-00.txt (just submitted)
> - - Rough time estimate needed
10 min.

The draft is attached.

						Masataka Ohta

INTERNET DRAFT                                                   M. Ohta
draft-ohta-multihomed-isps-00.txt          Tokyo Institute of Technology
                                                               June 2003

                   Multihomed ISPs and Policy Control

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   Policy control of next level ISPs, delegated address spaces from top
   level ISPs, is discussed.

   While global policy coodination requires top level aggregators, local
   policy can be controlled with next level aggregators.

1. Introduction

   Considering that some people has been arguing to have 4 byte AS
   numbers, the number of ISPs will grow indifinitely

   On the other hand, having small number of TLIs will make full routing
   table small that it can be expected that most hosts has full routing
   table, reducing the problems with destination and source address
   selection.

   An obvious solution is to have layers of ISPs, as was specified in
   IPv6 to have TLA (Top Level Aggregator) and NLA (Next Level
   Aggregator) that they can be allocated to TLIs (Top Level ISPs) and

M. Ohta               Expires on December 23, 2003              [Page 1]

INTERNET DRAFT     Multihomed ISPs and Policy Control          June 2003

   NLIs (Next Level ISPs, correspondingly.

   The probelm, however, is whethere and how the number of TLIs can be
   controlled.

2. Robustness

   An essential property of ISPs is robustness of its service that it is
   almost mandately that NLIs are multihomed to multiple TLIs.

   It is, then, expected that some sites are multihomed to multiple TLIs
   and/or NLIs.

   It is expected that NLIs have multiple prefixes each belonging to
   multiple TLAs, all of which is delegated to sites.

3. BGP Policy Control

   BGP Policy is controlled by identifying ISPs not by address prefix
   but by AS numbers.

   Thus, a next level ISP not having its own TLA can still fully control
   its policy.

   Moreover, neighbour ISPs can adjust their policy using the full
   prefix of the ISP.

   However, to limit the size of global routing table, an AS and
   prefixes of the next level ISP at the distance must be discarded or
   merged with its TLA.

   But, it is better than a current multihoming practice that prefix of
   a multihomed site is propagated locally to give robustness against
   local failures, because multiple TLAs give robustness against global
   failures.

   Thus, it is not essential that ISPs have their own TLAs.

4. Limiting the Number of TLAs.

   There should be hard upper bound on the number of TLAs in the
   Internet.

   For example, some TLA may be supplied from RIRs with bidding.

   Some TLA may be allocated to each country (proportional to the
   population of the country) and delivered with the countrie's policy.

M. Ohta               Expires on December 23, 2003              [Page 2]

INTERNET DRAFT     Multihomed ISPs and Policy Control          June 2003

   The proper number of TLAs, it seems to the author, should be
   somewhere between 1024 and 8192.

5. Author's Address

   Masataka Ohta
   Graduate School of Information Science and Engineering
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3299
   EMail: [email-masked]

M. Ohta               Expires on December 23, 2003              [Page 3]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 24 Jun 2003 01:07:19 +0859 ()

Kurt;

Masataka Ohta
> - - Draft name
draft-ohta-e2e-multihoming-*.txt (-04- just submitted)
> - - Rough time estimate needed
20 min.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 24 Jun 2003 01:17:57 +0859 ()

Kurt;

> issue),

Then, it is just a call for presentation, not specifically to the
first one.

> but the second slot is meant  for discussions on how we should 
> team to present their work in the second slot as well.

So, you have got a slot from Randy, even though the agenda
is empty. Good job.

							Masataka Ohta

---

From: marcelo bagnulo <[email-masked]>
Date: 23 Jun 2003 18:54:53 +0200

Hi,

From the conclusions: 

"   The proposed way of multihome does not destroy the hierarchical
   structure of address space nor increase routing informations
   explosively because the addresses which are assigned to multihome
   site are always subsets of address space of upstream ISPs.

   All routers in a network do not have to concern about the route of
   outside of the network.

   This way of multihome can deal with source address filtering"

What do you mean by "the proposed way to multi-home"?

I mean, I couldn't find in the draft a description of any mechanisms to
multi-home...

I guess that there should be a reference to a concrete mechanism
proposal, Otha's e2e multihoming perhaps? but there are no references in
the draft, could you clarify this form me?

Besides, if i understand the draft correctly, it is about ingress
filtering and source address based routing, so have you checked C.
Huitema's draft about host centric multi-homing? 

Thanks, marcelo

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 24 Jun 2003 16:47:28 +0900

Hi Marcelo,
thank you for reading my document.

On 23 Jun 2003 18:10:02 +0200

> If the upper layers are aware of the multiple address, what do you need

Your understanding about LIN6 is absolutely correct.
In LIN6, the locator part of an IPv6 address isn't visible
to upper layers. This makes it possible to continue
existing sessions even when an LIN6 node moves and
its address is changed.
In this model, however, upper layers cannot make any
controls on outgoing packets' address and route. This
model, we think, doesn't benefit from multihoming.
So we make it possible to make an special socket through
which multiple locators are visible to upper layers
(application layer). This special socket are implemented
so that it can co-exist with normal sockets.
For such a socket, LIN6 is used for address resolution,
notification and registration. LIN6 layer acquires
target node's addresses, registers locators to its
Mapping Agents and notifies address change to the
corresponding nodes and also to upper layers.

> whether an address is reachable or not?

These issues are mentioned in LIN6's draft below.
http://www.lin6.net/draft/draft-teraoka-ipng-lin6-01.txt 
Briefly speaking, you can get the MA's address by a kind
of DNS address-to-name translations. By making a query
,where an mobile node is, to the MA, a corresponding node
can get all the addresses the mobile node has even if some
of the addresses aren't reachable from the corresponding
node.

> tell, and it should be addressed.

This is also mentioned in the LIN6's draft above. In LIN6
layer, address information are exchanged and updated in
a secure manner using cookies exchanged through a location
query to the MA.

> to be used when the address that is being used fails? 

Our APIs, mentioned in my draft, are used for this porpose.
By getaddrinfo2(), an application can acquire all the
addresses of the other end node and by setsockopt()
an application specify the kernel which address should
used for destination/source address of outgoing packets.

I hope you understand what our APIs are for and why these
are based on the LIN6.
Any comments are welcome.

-- 
Arifumi Matsumoto ([email-masked])
Kyoto University

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jun 2003 12:46:06 +0900

Hi,

> a secure manner using cookies exchanged through a location

I made a mistake at this point. This issue hasn't yet
mentioned in this draft. But note that this simple
cookie authentication mechanism has already implemented
in LIN6 so that every LIN6 node can notify his addresses to
his correspondent securely.
There is a paper on this cookie authentication mechanism 
submitted by LIN6 developers. But, unfortunately, this is
in japanese only.

I'm not sure whether the LIN6 draft will be updated or not.

--
Arifumi Matsumoto

---

From: marcelo bagnulo <[email-masked]>
Date: 25 Jun 2003 18:32:01 +0200

> cookie authentication mechanism has already implemented

I do not know what do you mean by simple, but i would say that security
issues related to multi-homing are very relevant and i am not sure that
a so simple solution would do the job. Check the mobileip security
issues which are addressing somehow related problems.

> I'm not sure whether the LIN6 draft will be updated or not.
I guess that this would be a problem for your draft, especially if the
solution relies on LIN6 undocumented security features (at least not
documented in English :-) since we will not be capable to understand the
security implications.

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: 25 Jun 2003 18:25:41 +0200

On Tue, 2003-06-24 at 09:47, Arifumi Matsumoto wrote:
[...]

> controls on outgoing packets' address and route.

Ok. i think we a different idea about this. IMHO, addresses and routes
are IP layer issues, above layers should not be aware of the route used
and they should not select it. For above layers, IP addresses are plain
identifiers of nodes.

 This
> model, we think, doesn't benefit from multihoming.
I do not see what you mean. If the ip layer preserves the established
sessions using a mechanism such as LIN6 or whatever, i would say that
the host is benefiting from multi-homing.

> of the addresses aren't reachable from the corresponding
So in the multi-homing scenario, where would those MAs should be?

Thanks, marcelo

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Thu, 26 Jun 2003 14:42:55 +0900

Marcelo;

I'm verry sorry for replying late.

We are now revising this draft, and after that, we will answer this
question.

Regards,

At 23 Jun 2003 18:54:53 +0200,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 30 Jun 2003 15:47:54 +0900

Hi, marcelo.
Sorry for I coundn't reply to you soon.
Now I'm working for the coming Networld+Interop 2003.:)

On 25 Jun 2003 18:25:41 +0200

> and they should not select it. For above layers, IP addresses are plain

First of all, LIN6 originally does not show multiple
addresses to an application layer.

Most of applications do not need such information, but we
believe some kinds of applications need such information.
That's why we extended API of LIN6.

For instance, in the current IPv4 Internet, most of
applications rely a DNS resolving mechanism on a library
provided by a system though, MTAs such as sendmail do
resolve DNS by themselves in order to utilize multiple
destinations.

> the host is benefiting from multi-homing.

I mean LIN6 doesn't fully benefit from multi-homing. In LIN6
IP address addition and deletion is the only information used
for mobility and multi-homing. When a link between the two end-
points gets in trouble each node cannot detect it. The connection
will be lost in a short time even both or either of the two end-
points is multi-homed.
I believe this kind of trouble has to be detected in transport
or upper layer.

> So in the multi-homing scenario, where would those MAs should be?

An MA can co-exist in an MN itself, when the MN does not
move and is multi-homed.

We are also thinking the cases where multiple MAs are
distributed for a sigle MN, each MA is multi-homed, and an
MN moves with being multi-homed. In any case, LIN6 works
pretty well.

Thanks.