Brian E Carpenter wrote:
We're arguing past each other.
I am never going to agree that we have a shortage of bits
in ::/64. If we waste those bits due to inserting an
unnecessary hierarchy in the prefix assignment process,
shame on us. If the current registry practices are having that
effect, then we need to work with the registries to change
their practices.
It isn't the registries that are the problem, nor is it the problem of
anyone in any particular hierarchy.
It is merely that hierarchies exist.
And it isn't necessarily a "today" problem, like we have in IPv4.
It's a "2-3 years from now" problem, which exists *only* during a window
where the core Internet
infrastructure consists of lots of routers doing both IPv4 and IPv6,
without lots of players
having to do massive core-wide infrastructure upgrades.
Here's the problem I forsee, in a nutshell:
If, or when, significant numbers of ASNs start having to get additional
IPv6 allocations from their RIRs,
allocations which are typically PA (for reassignment to their
customers), at a time when most ASNs have
migrated to dual-stack IPv6, the total number of IPv6 prefixes *in the
DFZ* becomes a problem.
The underlying problem is that any recipient of a single direct IPv6
allocation, has the ability to use it all up,
without being irresponsible in the allocations given out, in a time
frame that hits this window.
And the worst thing about this is, if *any* recipient can do this, there
is a strong likelihood that *many* will do this.
If an ISP gets a /32, and gives out /48's, which they can do without
requiring supporting documentation,
and reserves space for each allocation (say a nibble), that leaves only
12 bits of "range", or 4096 customers.
I dare say that there are a fair whack of ISPs with that many customers,
who are most likely to get only
a /32.
Even *if* RIRs are reserving space for them adjacent to those original
assignments, there is nothing that
would stop anyone from announcing two adjacent /32's instead of a /31.
Think of the addition of each single extra prefix from each ASN, as
something akin to an allergen.
It doesn't take very many to cause an allergic reaction in the core. The
goal is to be *extremely* conservative
about allocation schemes, so as to avoid for as long as possible, the
need for *any* recipient of directly
allocated space (from their RIR) to get a second allocation.
What I'm attempting to do, is ensure this doesn't happen in the "window"
timeframe, by having much more
space given out relative to the minimum allocations - something that can
only happen if there are more bits.
(After some point in time, I would expect the dominant infrastructure to
be IPv6, with islands of IPv4 hold-outs
whose needs might be adequately served by IPv4-to-IPv6 proxies.)
If we get another 16 bits, with /80 as the minimum, then end assignments
of /64, from ISP blocks sized
at /40, for example, even when allowing for 8 bits above the /64 and 8
bits above the /40, gives lots more
space for growth at each level, 16 times as many potential customers,
and a much lower likelihood that anyone,
let alone lots of folks, will need to ask for more space inside of 10 years.
Choosing EUI-64 format was a strategic decision taken from
a very long term (many decades) viewpoint. I see no case
for changing that choice.
I'm not arguing for changing *all* of IPv6 away from EUI-64.
I'm arguing *for* *allowing* choices of II format of EUI-64 *or* any
other suitable unique II specific to the layer 2 medium.
For Ethernet, one such choice would be EUI-48 (which is what MAC-48 is
supposed to now be called, per IEEE).
And, for those situations where RA prefix size + II size < 128, padding.
(Possibly special-cased so that when RA prefix size is /64, for
compatibility reasons, it uses EUI-64 format for the II.)
Any place where advanced IPv6 features are necessary, whatever those may
be, that *require* /64, can trivially be supported by use of /64 by
network administrators.
Anywhere those aren't needed, I am advocating use of /80 instead, so as
to preserve both address space, *and* ability to do autoconf. I *do* see
autoconf as an important feature.
I fully realize that *there are* in use today, numerous technologies
whose MAC is EUI-64. Those obviously *need* /64.
But, there is a vastly huge deployed IPv4 infrastructure that neither
wants, nor needs, any IPv6 features beyond IP connectivity, where IPv6
is treated as "IPv4 with more bits" (plus autoconf instead of dhcp).
*IF* I'm able to convince you that the situation warrants more bits,
would you agree that what I propose is a reasonable compromise towards
that end?
(You don't yet have to agree that the situation warrants more bits.)
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
