IPv6 /64 links (was Re: ipv6 book recommendations?)

Mon Jun 25 14:54:32 UTC 2012

On Jun 25, 2012, at 12:06 AM, Masataka Ohta wrote:

> Justin M. Streiner wrote:
> 
>> I see periodic upticks in the growth of the global v6 routing table (a 
>> little over 9k prefixes at the moment - the v4 global view is about 415k 
>> prefixes right now), which I would reasonably attribute an upswing in 
>> networks getting initial assignments.
> 
> As I already wrote:
> 
> : That's not the point. The problem is that SRAMs scale well but
> : CAMs do not.
> 
> it is a lot more difficult to quickly look up 1M routes
> with /48 than 2M routes with /24.
> 

It is incrementally more difficult, but not a lot at this point.

Further, 2M routes in IPv4 at the current prefix:ASN ratios
would only map to about 100,000 routes in IPv6.

(IPv6 prefix:AS ratio is currently about 3:1 while IPv4 is around 14:1,
so if all 35,000 active AS were advertising 3 IPv6 routes, we would
be at about 100,000. Most of the growth in the IPv4 routing table
represents increases in the prefix:ASN ratio whereas most of the
growth in the IPv6 routing table represents additional ASNs coming
online with IPv6.)

>> If anything, I see more of a 
>> chance for the v4 routing table to grow more out of control, as v4 
>> blocks get chopped up into smaller and smaller pieces in an ultimately 
>> vain effort to squeeze a little more mileage out of IPv4.
> 
> The routing table grows mostly because of multihoming,
> regardless of whether it is v4 or v6.
> 

Assertion proved false by actual data.

The majority of the growth in the IPv4 routing table is actually due to
disaggregation and slow start. A smaller proportion is due to traffic
engineering and multihoming.

(See Geoff Huston's various presentations and white papers on this).

> The only solution is, IMO, to let multihomed sites have
> multiple prefixes inherited from their upper ISPs, still
> keeping the sites' ability to control loads between incoming
> multiple links.

This is not a solution. This is an administrative nightmare for the
multihomed sites which has very poor failure survival characteristics.

1.	Established flows do not survive a failover.
2.	Every end host has to have knowledge of reachability which
	is not readily available in order to make a proper source
	address selection.

The solution, in fact, is to move IDR to being locator based while
intra-domain routing is done on prefix. This would allow the
global table to only contain locator information and not care about
prefixes.

Currently, in order to do that, we unfortunately have to wrap the
entire datagram up inside another datagram.

If we were to create a version of the IPv6 header that had a field
for destination ASN, we could do this without encapsulation.

Unfortunately, encapsulation brings all the MTU baggage of
tunneling. More unfortunately, changing the header comes
with the need to touch the IP stack on every end host. Neither
is an attractive option.

It would have been better if IETF had actually solved this instead
of punting on it when developing IPv6.

Owen