Note, while I think it's useful to have an educational discussion about IPv6 addressing policy on the IETF list, it's also a tad frustrating how selective/partial context quoting leads the discussion veering off in all kinds of random directions... I'd encourage folk to read the entire IPv6 policy to get a more complete picture. It's not that long. ARIN's is at: http://www.arin.net/policy/nrpm.html#ipv6. John C Klensin <john-ietf@xxxxxxx> writes: > In other words, to get IPv6 PI space, I must already qualify for > IPv4 PI space. That seems reasonable on the basis of history. > But, as IPv4 space gets very tight (as predicted), it could be > construed as a mechanism by which incumbent ISPs and other > organizations who already have large blocks of legacy IPv4 space > keep new entrants, especially any who have business and/or > network models that are be IPv6-only, from playing. I think > there are technical terms for that sort of strategy. > > > 6.5.8.2. Initial assignment size > > > > Organizations that meet the direct assignment criteria are > > eligible to receive a direct assignment. The minimum size of > > the assignment is /48. Organizations requesting a larger > > assignment must provide documentation justifying the need for > > additional subnets. > This gets us to /48, not /32. It also says that, under some > circumstances, an organization can go to ARIN directly for space > rather than an LIR or getting PA space from an ISP. Having that > allocation size be the same size that (i) IETF considers normal > and (ii) ARIN encourages LIPs to give out to entities who need a > large handful of subnets, rather than one the basis of HD > ratios, seem strange to me given the claims that IPv6 > multihoming does not require PI space and separate routing. That claim/myth seems remarkably difficult to quash. Let me say it clearly: IPv6 has no magic multi-homing solution, and the multihoming approachs that IPv6 offers are essentially equivalent to those available in IPv4. Note that in the RIR community, this has been obvious for some time, and is one of the reasons why the policies being developed there have a lot of similarities to IPv4 policies (but they still do have important differences). > Indeed, such a policy seems to me to be more of a threat to > routing table size than encouraging ISPs to give out /48s (that > they will aggregate into their large, LIP, blocks, for routing > purposes) all the time, but that is probably a separate issue. Yes, and the debate was quite contentious and played out over a number of years. But eventually the "be very scared" arguments were drowned out by the "IPv4 hasn't collapsed yet, and we need parity with IPv4, when it comes to PI addressing". > In addition, again using your example, unless IBM or Microsoft > has deployed IPv6-working and connected hosts on the order of > 80% of a /36 (or at least 80% of a /44 or some intermediate > number), they have justified a /32 (if at all) on the basis of > promises and network designed, not actual use. Sorry, the 80% utilization metric is specific to IPv4. IPv6 doesn't use this same utilization formula to measure the actual "utilization" of a chunk of address space, it uses the HD-ratio metric. And, since this is also very different in IPv6, let me point out that what is counted is subnets, not hosts. Quoting from the ARIN document: 6.2.7. Utilization In IPv6, "utilization" is only measured in terms of the bits to the left of the /56 boundary. In other words, utilization refers to the assignment of /56s to end sites, and not the number of addresses assigned within individual /56s at those end sites. Throughout this document, the term utilization refers to the allocation of /56s to end sites, and not the number of addresses assigned within individual /56s within those end sites. And, for those of you worried about end users being given a /64 (or worse), from a registry perspective, it is 100% acceptable to give every end site a /56. That is what the above wording means, and that is what the RIRs expect LIRs to do. If LIRs/ISPs choose to give end sites less space than that, there really is no significant benefit to them doing so. Indeed, I would expect that if an ISP stingily gave out only /64s, it would find that there are other ISPs that are more than happy to offer /56s. Thus there would be some marketting disadvantages to being stingy and they have some discincentive to being overly stingy. > While their production (?) IPv6 deployment may have gotten very > large when none of us were looking, that would otherwise be a fairly > large chunk for an initial allocations from a body that was trying > to conserve space. The RIRs are not trying to "conserve" in the same sense as for IPv4. The balance has clearly shifted to being less conservative in terms of ultilization and also trying harder to avoid fragmentation of the address space resulting from growth. Quoting again from the ARIN document: 6.3.4. Aggregation Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables. This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing. IPv6 address policies should seek to avoid fragmentation of address ranges. Further, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation. 6.3.5. Conservation Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. > > These assignments shall be made from a distinctly identified > > prefix and shall be made with a reservation for growth of at > > least a /44. 6.5.8.3. Subsequent assignment size > So, if I have a plan about 16 subnets, I get a /48 from my ISP. > If I can justify that much space on the basis of HD ratio, not > just number of subnets, I can go to ARIN, claim multihoming and > whine, plead, or, if I'm large enough, beat my chest, I can get > a PI /48 with a reservation of the rest of the /44 (or larger) > instead. Maybe that is ok, except (i) IPv6 is not supposed to > require PI space on the basis of multihoming and (ii) that > criterion has nothing to do with whether one is an LIR. There is that myth again. :-( > > Additional assignments may be made when the need for > > additional subnets is justified. When possible, assignments > > will be made from an adjacent address block. > But now we are back to a "subnet count" criterion. I don't > know what ARIN intends, but a plausible reading of this is that > I have to justify a PI /48 on the basis of HD ratio (and, of > course, already having IPv4 PI space or being able to get it). > Of course, the other possibility is that this really is about > subnets. I.e., we don't care any more about _host_ density or > efficient use of address space and designing networks to ensure > a maximum number of hosts per subnet. On that model, all I > need to justify a /32 is a nice drawing or two that explains how > many subnets I need on the basis of physical locations, a > cross-product of authorization domains and so on. Of course, > for that story to be believed, I also have to hold an > equivalently large block of IPv4 PI space (no non-incumbents > need apply... see above). But I didn't think that was where we > were headed. Your mixing things a bit here. The first part of the text refers to the PI for end sites policy. The /32 applies to LIRs, a different category of address assignment. Thomas _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf