Re: OMB: IPv6 by June 2008

["Alexei Roudnev" <alex () relcom net>]

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" <jabley () isc org>
To: "Andre Oppermann" <nanog-list () nrg4u com>
Cc: "NANOG list" <nanog () merit edu>; "Alexei Roudnev" <alex () relcom net>;
"Iljitsch van Beijnum" <iljitsch () muada com>
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