OMB: IPv6 by June 2008

David Meyer dmm at 1-4-5.net
Thu Jul 7 16:21:58 UTC 2005


	Andre,

On Thu, Jul 07, 2005 at 06:04:22PM +0200, Andre Oppermann wrote:
> 
> Joe Abley wrote:
> >
> >On 2005-07-07, at 10:23, Andre Oppermann wrote:
> >
> >>It was about a spot in the global routing table.  No matter if one  gets
> >>PA or PI they get a routing table entry in the DFZ.  There is no  way 
> >>around
> >>it other than to make the routing protocols more scaleable.
> >
> >With the hole-punching/CIDR abuse multihoming that is widely used in  
> >IPv4, a slot in the DFZ gets burned each time an end site adds a  
> >provider, regardless of whether they are using PA or PI addresses.  This 
> >slot represents state information for the multi-homed site which  
> >answers the question "how else can this set of addresses be reached?"
> >
> >The shim6 approach shifts this state from the DFZ to the endpoints  
> >which are exchanging unicast traffic. The endpoints exchange a set of  
> >possible locators through a protocol element within the IP layer and  
> >handle locator migration transparently to the transport layer above.  
> >Hence the question "how else can this particular remote address be  
> >reached" is answered using information on the host, not information  in 
> >the network.
> >
> >With shim6 an end site can multi-home using one PA prefix per  provider, 
> >without taking up additional slots in the DFZ. Hosts within  the site 
> >are given multiple addresses (locators), and the layer-3  shim handles 
> >any change of locator needed for traffic exchanged  between any two hosts.
> >
> >If one (or both) of the hosts exchanging traffic don't support shim6,  
> >then the traffic is exchanged without transport-layer stability  across 
> >re-homing events (and, potentially, without any optimisation  as to the 
> >choice of endpoint addresses for the session).
> >
> >So, the shim6 future of multihoming looks like this:
> >
> >1. ISPs multi-home exactly as people are used to doing today, using  PI 
> >prefixes, and taking up a slot in the DFZ per transit provider.  
> >Everybody is familiar with this already. There is no change for ISPs  in 
> >this picture.
> >
> >2. Multi-homed end sites obtain one PA prefix per upstream ISP, and  
> >hosts within those end-sites are assigned multiple addresses (in some  
> >automated, secure and controllable fashion). There are no additional  
> >slots burned in the DFZ by end site multi-homing. Hosts obtain  
> >transport-layer reliability across re-homing events using shim6,  rather 
> >than relying on the network to take care of it.
> 
> Ok, you don't think this thing will ever fly, do you?

	I'm interested in what aspect(s) of shim6 you think might
	cause it to fail? Is it the technology itself (as much as is
	specified anyway), it's complexity, the underlying
	multihoming model, ...? 

	Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050707/57b035b8/attachment.sig>


More information about the NANOG mailing list