Re: What's 16 bits between friends?

[Brian Dickson <[e-mail]>]

[e-mail] wrote:
>>  From what I have seen so far as responses, the counter arguments are:
>> - there are these wonky things that maybe a few dozen 
>> research sites are playing with that use 64-bits for MAC
>> - changing the spec would require, like, actual work. Let's 
>> just leave it alone
>>
>> IMHO, those arguments don't hold water.
>>     
>
> If your goal is to enable IPv6 to be deployed in the global Internet,
> then any changes which reserve FEWER bits for interface addresses would
> be counterproductive. Since IPv6 does reserve a full 64 bits for
> interface addresses, that means that there are only 64 bits that can be
> used in network prefixes, i.e. routing table entries. This allows router
> vendors the possibility to optimize their code or their route table
> storage by only allowing 64 bits of data per entry if there are no known
> prefixes longer than 64 bits. Your proposal to reduce the interface bits
> makes it less possible to apply such an optimization which reduces the
> ability of network operators to scale up the IPv6 Internet.
>   
First of all, not all routes are /64.
There are of course aggregates, shorter prefixes.
But, there can be, and are, longer prefixes than /64. They just don't 
work with autoconf.

Many infrastructure routes on large IPv6 transit networks make use of 
the full range, all the way
down to /126's for point-to-point links. Those are often aggregated 
internally, by router, by site,
and by region, e.g. as /120's, /112's, and /104's. And loopbacks with 
/128's.

It isn't IPv6 that reserves 64 bits, it is only those subsets of IPv6 
functionality that use Interface Identifiers,
such as autoconf.

My goal is to keep the *number* of prefixes in the *DFZ* as small as 
possible. /64's or /80's, whichever
is used for LAN networks doing autoconf, should *never* appear in the 
DFZ. Only the top level PI blocks
or fully aggregated PA blocks, with no longer-prefixes, should appear in 
the DFZ.

So, the size of the autoconf prefix is actually irrelevant for what 
you're thinking of. The only places where
deaggregated prefixes should be seen, is where they are an ISPs 
infrastructure prefixes, or an ISP's
PA assignments, both of which need to be carried internally.
> Of course, there is a similar negative factor here at a higher level. By
> making fundamental changes to IPv6 at this late date, we would force
> vendors to change their code, and network operators to update all their
> routers. These things all take time, therefore your proposed changes
> would delay the deployment of IPv6 on the global Internet.
 Actually, if you paid attention to what I was saying - this ONLY 
affects HOSTS doing AUTOCONF.
IT DOES NOT REQUIRE ANY ROUTER CODE CHANGES.

It *does* support the notion of those *using* routers changing the 
assignments they use on subnets
that are doing autoconf, from /64 to /80. Those don't even need to 
change for deployed subnets; this
primarily addresses long-term need for new deployments.

And, it isn't a one-size-fits-all alternative. There are side cases 
where special IPv6 stuff uses, and needs,
and expects to be given, a /64. That's fine. /64's and /80's can live 
together happily. The number of end user
assignments, be they /80 or /64, for autoconf subnets, remains the same. 
The only difference is, how much
space gets chewed up by a bazillion such assignments.

That's why I originally discussed the importance of understanding the 
value of an *extra* 16 bits.

You can fit 64k networks of size /80, in one /64, which means you can 
give loads of room for growth to
each customer, without impacting the overall capacity within, say, a 
/48, which is the smallest current
assignment.

A /48, broken down to /80, is 4.3 BILLION networks. Even giving 8 bits 
of growth room
to each end assignment, that is still 16 MILLION networks. That's a lot.

On the other hand, if you do the /64 thing, a /48 only has room for 64K 
networks, and no room
to grow any of them.

*THAT* is the squeeze play that can, and likely will, blow up the DFZ on 
IPv6 without changing the
current /64-only world of autoconf.

Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------