|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: OMB: IPv6 by June 2008
Who need this complexity? What's wrong with old good _routing rotocol_ approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is for slow routing system). CPU (the same)? What else? If it looked as a problem 10 years ago, it can not be relevant to today's realities. ----- Original Message ----- From: "Joe Abley" <[email protected]> To: "Andre Oppermann" <[email protected]> Cc: "NANOG list" <[email protected]>; "Alexei Roudnev" <[email protected]>; "Iljitsch van Beijnum" <[email protected]> Sent: Thursday, July 07, 2005 8:11 AM Subject: Re: OMB: IPv6 by June 2008 > > 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. > > > Joe
|