Iljitsch wrote: > On 29-aug-2007, at 16:23, Thomas Narten wrote: >>> (I suppose it's a bit late in the game to go back to MAC-48 as II?) > >> Yes. The difficulty is figuring out how to move to something different >> in a backwards-compatable way. I.e., we'd need a transition strategy. > > But what would be the point of doing that now?
The point, which I have avoided making until now, is that II has direct impact on the available range of assignments by RIRs to LIRs, for PI blocks, that also allow for very long timescale predictive assignments. Basically, the minimum prefix size * number of assignments * LIRs, when projected over a timeframe of decades, while preserving a global DFZ consisting of one PI block per LIR, has a problem fitting into the number of bits per RIR. Right now, RIRs are reserving only an additional 2 bits per LIR assignment, for "growth". Alternative allocation policies (bisection) don't guarantee the ability to assign arbitrarily large blocks indefinitely - while that is in fact the long-term requirement. Block sizes *should* increase over time, even as the frequency of their assignment decreases. What works best is, a best-fit approach, where any organization gets way more space than they need, sized according to their own best guess as to long-term growth *potential*. Then, reserve even more space for each, in a consistent manner. Take all these requests, and fill them in an optimized space-packing manner. At some point, growth requests get filled via "growing" the assignment for a given LIR into its reserved space. And, long-term periodic reviews of those growth patterns may result in bisecting *some* of those reserved blocks to make more space available for similar assignments. This can be shown to meet the requirements of individual LIRs to within a few orders of magnitude of their long-term projections (pretty good), and at the same time, optimize the packing efficiency, meaning the truly free space will not be fragmented except to the degree absolutely necessary for the existing assignments. This means that new assignments have the largest possible potential prefix size available, compared to other allocation methods. This can even be demonstrated or possibly even proven mathematically, by modeling the problem space. > The fact that we have so many local bits in the IPv6 address is our > insurance policy against address policy screwups because a single /64 > is enough to run a network of arbitrary size if you forego stateless > autoconfig. The same would be true of /80, which is what MAC-48 would result in, for minimum prefix size for autoconf (and thus the standard end-user assignment size). Of the 16 bits reclaimed via this change, I would propose to the RIRs, that 4 bits be added to initial allocations, 4 bits to reservations above the initial allocations (for long-term growth), and the other 8 bits add to the total space available for the RIRs to allocate to LIRs - by adjusting the minimum and initial allocation sizes by 8 bits. The numbers (4 bits and 8 bits) are not accidental - they are one nibble in size, which matches up with the boundaries for reverse address lookups, via ip6.arpa - which uses nibbles. It seems to me, that while it would be an uphill battle, the main two issues are transition and compatibity, and inertia (e.g. deployed code and networks.) The overall benefits to address space assignment, IMHO, outweigh that cost, especially when considering the long-term health of the DFZ and the cost to member organizations when having to do expensive upgrades to their entire infrastructure to support bloat in the DFZ. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
