RE: The state of IPv6 multihoming development

["Tony Li" <Tony.Li@procket.com>]

|   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