moving to IPv6

Karl Denninger karl at Mcs.Net
Fri Nov 7 17:43:01 UTC 1997

On Fri, Nov 07, 1997 at 09:51:30AM -0600, John A. Tamplin wrote:
> On Fri, 7 Nov 1997, Karl Denninger wrote:
> > Of course, then what happens is that you have to revoke the multiple ASNs
> > that some providers have - which IMHO should NOT have been issued.
> > 
> > "Administrative convenience" isn't a valid reason to be issuing ASNs all
> > over the place.  There is no *need* to do so - there may be a *want* to do
> > so, primarily because people don't want to carry their own customer's
> > traffic for the majority of the trip in even one direction (which IMHO is
> > baloney, but heh, that's just my point of view).
> The legitimate reason for multiple ASs is when separate parts of the 
> network have very different routing.  For example, let's say a big 
> company on a single continent has one prefix for their whole network.  
> They then expand to another continent.  If they use address space under
> that same prefix, they wind up either having the transcontinental link
> large enough to support all of the transcontinental traffic for that
> prefix, or they wind up routing traffic across a transcontinental link
> and back when it didn't have to.  Now, if they get a different prefix for
> the new continent, traffic will take the optimal path.
> This is no different than inefficiencies caused by the current 
> implementation.  Generally, traffic gets to the destination AS as quickly 
> as possible and then finds its way to the destination host from there.  
> However, there may be a shorter path involving a different entry point 
> into the destination AS.
> With the larger address space of IPv6, there is the capacity for an arbitrary
> number of levels in the hierarchy.  Obviously, making use of those levels
> to improve on the inefficiency noted above will require more routes to be
> propagated, so there is a tradeoff.  I don't think we want either a routing
> table contaning one route per AS nor do we want one containing every subnet
> with each AS.  Ideally, we would choose some level of detail between those
> extremes, using multiple routes per AS only where they actually improve
> routing.
> John Tamplin					Traveller Information Services
> jat at Traveller.COM				2104 West Ferry Way
> 205/883-4233x7007				Huntsville, AL 35801

This I agree with.  

We could, for example, define a "country code" set of bits in the high-order
field of the "provider" area.  For example, from the LEFT side of the
IPv6 address (128 bits wide):

0 - 8 		- Reserved for when interplanetary travel and subspace
		communication become functional (to define "Galaxies" - 
		this appeases Jim Fleming and Star Trek types :-) :-)

9 - 17		- Country code (1024 countries; there's only so much land
		on the planet, and we're well under that now I believe :-)

18 - 47		- Reserved for future use

48 - 63		- Provider's AS Number

========================	Boundary of externally-visible address space
				from a provider (ie: you route to a /64 level)
				Everything below this point "belongs" to the 

64 - 95		- Reserved for internal assignment once IPv4 direct backward
		mapping is no longer relavent (or desired).

96 - 127	- Existing IPv4 mapping, 32 bits, provider dependant and

Now, think what this does:

1)	Any address for a level beyond where you are only needs to seek
	the closest exit point (ie: if you're in "galaxy" 0, and you get
	a packet for "galaxy 1", you don't need to look at or care about
	the rest - find the closest "galaxy 1 exit".

2)	Routing at the *country interconnect level* only requires a lookup
	of 1024 possible destinations - easily done with a direct index
	table (which is a *ONE INSTRUCTION* decision in core routers).
	Multinational providers use bits 9 - 63 to make routing decisions 
	while single-nation providers only use bits 48-63 and have a 
	1024-entry "forward to the best exit table" for bits 9-17.  This 
	also permits implementation of TOS and QOS restrictions based on 
	destination or source country, which is something we're going to 
	have to face sooner or later.

3)	Routing between ASNs is a 16-bit issue (ie: 65,536 ASNs within a
	country, which is the MAXIMUM number of entities in one country -
	and if this isn't enough, encroach on the "reserved" areas).  The
	initialization sequence for the Son-of-BGP4 communicates the size 
	of this field so that as it grows its seamless to implement.

4)	IPv4 space maps *directly* onto this at a low level, preserving
	the option of FULL backward compatibility.

5)	Once we don't *CARE* about backward IPv4 mapping every doorbell,
	toaster, car, and wristwatch within a PROVIDER can be accomodated 
	in 64 bits!

This solves all of the allocation problems, GREATLY simplifies routing to
the point that a $2,000 router now can effectively be a multi-homed device
(since the "thinking" part just got incredibly simple) and makes convergence
a non-issue.

A gateway device to map between this layout as a backbone level transport 
and existing IPv4 is trivial.

Confederations of providers can decide to cooperate on the bit 96 - 127
address range; if they DO cooperate then you have inter-provider portability.
If not, then you still *might* have it, depending on whether the numbers you
were using have been assigned to someone else on the new provider you're
moving to or not.

Karl Denninger (karl at MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin     | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal

More information about the NANOG mailing list