North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: OMB: IPv6 by June 2008

  • From: Alexei Roudnev
  • Date: Fri Jul 08 03:53:07 2005

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

----- 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