Subject: RE: The state of IPv6 multihoming development

From: "Tony Li" <[email-masked]>
Date: Sun, 27 Oct 2002 01:06:24 -0800

|   On Sat, 26 Oct 2002, Tony Li wrote:
|   
|   > Unless I'm the one that's mistaken, the original 
|   complaint was that
|   > changing bits (and specifically -- the locator) at the 
|   border router
|   > would break applications that carry full addresses around in them.
|   
|   How can this be a problem if the bits are changed back later?

Why would they get changed back?

|   > Ok, if apps (or the underlying transport) can use more 
|   than one address,
|   > then that implies that the host has to make a decision 
|   about WHICH address
|   > to use, which is what Craig was objecting to in the first 
|   place.  If the
|   > host has to decide, then it's making a routing decision 
|   and it certainly
|   > shouldn't have enough information to make that decision.
|   
|   That's why it would be good if this functionality can be 
|   moved outside
|   the end host to a place where this information is available.
|   
|   If this is done on the host, this host must select two 
|   addresses: the
|   source address and the destination address. If we assume the source
|   address must match the outgoing ISP, there are two ways to 
|   handle this:
|   
|   1. The host selects a source address, and the routers 
|   choose the right
|      ISP to match the source address.
|   2. The host selects a source address, and the routers don't care and
|      route as per the destination address so the packet is 
|   filtered if the
|      host selected the "wrong" source address.

The host should select the identifier, both for itself and for the
destination.  The border router selects the locators for both the
source and the destination.  This allows the border router to implement
policy in a reasonable way.  

|   > Thus, the suggestion is to push the decision to the 
|   border router and
|   > move the policy information there.  The host still 
|   specifies the end
|   > system identifier, but the border router then determines 
|   the locator.
|   
|   That would be one way to do it. The (border) router could also
|   communicate its preferences back to the host. Either by 
|   dropping enough
|   packets to force a rehoming event, or by sending back a message or
|   some such. The host could set the router alert option for 
|   the negotation
|   packets and the router could inspect these and let its 
|   preferences be
|   known.

Agreed.  One thing that we can do to speed the conversation is to
first have the discussion at the architectural level.  Then we can
worry about the mechanisms.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Oct 2002 13:05:40 +0100 (CET)

On Sun, 27 Oct 2002, Tony Li wrote:

> |   > complaint was that
> |   > border router

> Why would they get changed back?

To avoid the above problem.  :-)

If the multihoming processing is done outside the host, then packets all
packets must be presented to the host with the identifiers as the source
and destinations addresses. If this is done inside the host then this
isn't strictly required, but it is likely the transport layer will want
to see just the identifiers so the IP layer will have to reconstitute
those.

> policy in a reasonable way.

Agree. However, do we want to involve a border router in the locator
discovery process?

> One thing that we can do to speed the conversation is to

Ok, that should work as long as we don't run into any "that can't work"
"yes it can" arguments.

The basic idea is simple: the IP addresses the transport layer uses
become the identifiers of a session. In transit, these identifiers
may/must be replaced by locators, but they identifiers are restored
before the packet reaches the transport layer at the other end.

The idea is that identifiers are also valid "regular" IP addresses that
can be used whenever multi-address multihoming isn't supported by both
ends or otherwise not desired.

I think there is some rough consensus that this should be done at the IP
layer, but it's probably advantagious to include some way for transport
protocols to provide hints that a rehoming might be in order.

Making this functionality "portable" so it can be located either inside
the host, or at a border router or some intermediate device would
greatly help in easy deployment and makes it possible to better address
the needs to implement multihoming or traffic engineering policies and
address management in large networks.

Then there is the issue of locator discovery or negotion. Negotiation is
much simpler to do, but has the disadvantage the it can't occur a priori
so it doesn't protect against an unreachable identifier. However, this
could be solved by having several potential identifiers located at
different places in the topology. This does NOT imply the alternative
identifiers are also alternative locators. It may be necessary to have
some mechanism for IP to learn from the transport protocol whether the
negotiation data pertains to a valid session if negotiation is done at
the network layer.

Discovery is hard to do, but if we can solve the associated problems it
provides a much stronger mechanism because then a host can have a
single, portable identifier. It would be good if we could provide an
upgrade path from negotiation to discovery.

An interesting consequence of all this multi-address stuff is that a
range of addresses becoming unreachable is no longer a huge problem that
must be fixed immediately, but rather an inconvience that can be
tolerated for some time. This means routing protocols can become much
less dynamic. For instance, the mapping from address prefixes to AS
numbers can become very static. It could even be done out of band, and
the mapping could be stored on semi-permanent storage. This makes it
possible to include much stronger security mechanisms. Changes in
inter-AS connectivity can then be propagated throughout the network much
faster than they are now, and there is room to exchange much more
information that can be used to optimize inter-AS routing,
such as link-state mechanisms.

Iljitsch

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 27 Oct 2002 15:47:34 +0300

> ends or otherwise not desired.

Why does this so much sound like Mobile IPv6 to me?

> ...

And why does this statement make me think that the lessons
we learned during the Mobile IPv6 security process might
be good to remember here?

I am probably biased here, but IMHO once you start to really
ponder the security consequences, you pretty much come to the
idea that maybe, after all, it might be better to introduce
a new cryptographic name space instead of once more overloading
the IP name space with some IP addresses that are end-point
identifiers (and locators) and some that are (just) locators.
The resulting aliasing problems are nasty, security wise.
The NSRG report still makes a good reading.

If you are going to require changes to the end-host and the
introduction of a mudem box anyway, the HIP design might
be a good place to start with.  The more recent variants of
HIP already support end-host multi-homing, and they contain
a "mudem" which is able to perform prefix translation, function
as a mobility home agent, and as a mobility anchor point.

Probably the LIN6/LINA design can do most of what HIP does as well,
but I haven't followed their recent changes, and I don't know if
they have already solved the scalability problems in their
security design.

--Pekka Nikander