Re: What's 16 bits between friends?

[Mark Smith <[e-mail]>]

On Tue, 18 Sep 2007 16:09:04 -0400
Brian Dickson <[e-mail]> wrote:

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

Depending on the prefix length, >/64, they can also break other things
e.g. reserved subnet any cast addresses.

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

Excepting the loopback /128, all the other prefix lengths you mention
are really just a sign that people have applied their IPv4 address
conservation mentality to IPv6. The prefix lengths you mention doesn't
justify that it should be done, it just shows that functionaly it can
be done.

The loopback /128 is a special case exception because a loopback
doesn't ever have more than one node on the "link", nor will there be a
router, so fixed and reserved /128 value is a good solution. That being
said, there are examples where loopback interfaces might have more than
one logical node - ntpd's use of 127/8 is an example I can think of.

IPv4 addressing today is an example of a convenience verses
functionality trade off. It was (and is) convenient (i.e. *simple*) to
deal with fixed length addressing allocations - IPv4 was easier and
simpler to operate and understand back in the classful / fixed length
subnet days. If you look into the history of all networking protocols,
possibly excepting only CLNS, they've all had fixed boundaries between
their network and node portions. 

Unfortunately, for IPv4 and the Internet to be able continue to
function and grow, something had to be given up. When it comes to the
crunch, convenience will always trump continued functionality.
So we all accepted variable length IPv4 prefixes because we all still
wanted the Internet to continue to work. The problem is, in particular
for people who weren't around in the classful days or earlier, it seems
to have created a universal mentality that enough addressing to meeting
functional requirements is the only correct and acceptable answer.

With IPv6's much larger address space, we are now back in a position to
have *both* convenience and functionality. Lets not throw the baby
out with the bath water, by unnecessarily giving up addressing
convenience and simplicity, now we have a chance to get it back.

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

There are far far more IPv6 capable end nodes out there already than
there are routers. All versions of Linux in the last 5 or so years, Mac
OS X, 3G(PP) phones, Windows Vista etc.

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

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