[EMAIL PROTECTED] 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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
