> Brian D, > > You seem to be assuming that PI will be the dominant mode.
Not at all. I am assuming that prefixes in the DFZ won't be deaggregated to any significant degree. All PA are aggregated, in theory at least, under PI prefixes. I am in fact only assuming PI prefixes as numerous as ASNs. And that more multihoming for true "end-users" will be enabled by the ability to have duplicative PA blocks big enough to cover end sites N times over. I am assuming that the *vast* majority of networks will have PA native, or ULA-* native and 1:1 NAT onto PA, or "unannounced" PI internally with 1:1 NAT facing multiple upstream PA blocks. > This seems very unlikely, since the vast majority of users > (i.e. SOHO) have no interest in what their IP address is and > no motivation to pay extra for PI. (I don't disagree on the latter, making this moot. And you mis-speak for me on what I assume.) > We have no possible > difficulty in supporting a few million PI prefixes in the > /48 or /56 world currently planned (apart from BGP4 blowing > up, of course, but that's being discussed elsewhere). I disagree strongly. Yes, I'm aware, and I'm participating in those discussions. The size of the autoconf prefix is out of scope for *those* venues. However, it *directly* impacts assignments in those areas. Which is why I raised the question, here. Whether autoconf uses /64 or /68 or /80, has direct implications on the minimum prefix assignable to an end-user should be, and what the typical minimum minimum PI block size should be. A "few million" PI prefixes is not actually something we should plan for, even if it fits into the range of space between /3 and /32 (as in, 2000::/3, and /32 LIR PI assignments.) Here's why: On the biggest iron currently deployed in most networks, the size of the DFZ in IPv6 that can *reasonably* supported has an upper bound dictated by deployed TCAM size and per-prefix TCAM allocation needed. These days, for example, on an IPv6-*only* Cisco 7600 with 3BXL, will only hold a theoretical maximum of 119,000 prefixes. Bigger iron may support double that, but again, only as IPv6-ONLY. When you add IPv4 onto the same platform, the huge IPv4 DFZ eats most of the capacity for IPv6 prefixes. Most providers will need to have dual-stack for a considerable period of time (3-5 years minimum, IMHO.) And on that basis, how many end-user assignments fit into PI prefixes which are sized sufficiently to grow vertically inside reserved space, rather than multiply and bloat the DFZ, is very important. Too big an end assignment, and it results in a squeeze play, where either too few PI blocks can be reserved to go around (fairly), or too many small PI blocks end up being used. Adding 16 more bits to the range between PI block size and end-user assignment prefix length, and the squeeze effect is relaxed considerably. Making really big assignments (say /20 to /42) to handle end-assignments of /80, gives a much longer life span to each PI block, and keeps the PI per ASN down to a nice low value of "1". Brian Dickson > Regards > Brian Carpenter > > On 2007-08-30 03:17, [EMAIL PROTECTED] wrote: >> 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 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
