Brian E Carpenter wrote:
On 2007-09-18 19:24, [EMAIL PROTECTED] wrote:
...
This becomes important when we consider non-trivial hierarchies of
allocations, such as RIR->LIR->ISP, where internally further allocations
are made for internal aggregation purposes.
Having that many layers of allocation hierarchy is an artificial
choice, and the aggregation argument only applies *within* a
single ISP's allocation. If we had flat allocation from IANA
to ISPs, your argument would go away. So assuming we keep the
artificial choice of allocation via RIRs and LIRs, that simply has
to work in a way that emulates flat allocation.
Okay, bad choice of terminology (not mine, theirs, really).
To make it clearer, let's use a reasonable example:
RIR -> Big (Tier-1/2) ISP -> small ISP -> big enterprise -> enterprise
site -> enterprise LAN
The first allocation is a direct allocation, and all subsequent ones are
PA sub-assignments.
No matter who does the assignment of the PA "master" block, everything
underneath is hierarchical.
And rather than just considering the initial allocation for each,
consider the growth *of each entity*.
If you don't reserve enough room, at some point, new allocations need to
happen. And if that happens
at the top, it's a new DFZ slot that gets eaten.
How often that happens, is a function of growth, and of the range
between PA block sizes and autoconf size.
And, it has nothing at all to do with where the ISP gets its space. It
has only to do with the size an ISP gets,
the number of ISPs of each given size of block, and whether they need
subsequent allocations.
And all of that is fundamentally driven by the size of the minimum
end-user allocation.
Which is why I am advocating a small change, affecting only host
autoconf functionality, to support ranges of
II construction that vary from /80 to /64 (or even larger). The
flexibility would support arbitrary LAN numbering
and LAN technology, be it MAC-64, MAC-60, or MAC-68, or whatever.
Other than the changes to the autoconf RFC, and coding, I don't see an
obvious downside to what I suggest.
Brian D
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
