Agree. I much prefer to stay with the /48. 256 subnets may be too low for some customers, I've seen this situation already, and then it is difficult to go back to the ISP for more, extra cost for everyone. We should go away of the restrictive mind set that we have with IPv4. Indeed, if we want to be more restrictive, I will much prefer to change the HD-ration again in the existing policies. Regards, Jordi > De: Bob Hinden <bob.hinden@xxxxxxxxx> > Responder a: <bob.hinden@xxxxxxxxx> > Fecha: Fri, 24 Aug 2007 17:22:57 -0700 > Para: Thomas Narten <narten@xxxxxxxxxx> > CC: <ietf@xxxxxxxx> > Asunto: Re: IPv6 addresses really are scarce after all > > Thomas, > > A few additions to your description of how we got to where we are now > email. > > RFC3177, where the /48 recommendation was made, used the H ratio > analysis to explain why a /48 was acceptable. However the IETF did > not make any recommendation to the RIRs that the H ratio (current > version is now called HD ratio) should be used by the RIRs in their > allocation process nor what specific HD ratio be used. These choices > were made the RIRs when they developed their IPv6 allocation policies. > > In my view the potential problems you describe have more to do with > the specific HD ratio the RIRs choose to use as opposed to the /48. > It's my understanding the HD-ratio value that the RIRs are now using > is much more conservative than before. This should, as I understand > it, avoid the overall problems you describe (e.g., cable modem, DLS, > etc.). > > While I agree that 64K subnets is a lot of subnets for a home user, > my reluctance to formally change the /48 recommendation is that it > will lead to much more restrictive allocation policies. Just like > the one that started this thread: > >> * /64 - Site needing only a single subnet. >> * /60 - Site with 2-3 subnets initially. >> * /56 - Site with 4-7 subnets initially. >> * /52 - Site with 8-15 subnets initially. >> * /48 - Site with 16+ subnets initially. > > If this is what we would expect to get by changing the RFC3177 /48 > recommendation, then in my view is not a good idea. > > Bob > > > > > On Aug 24, 2007, at 2:34 PM, ext Thomas Narten wrote: > >> Some background and history. >> >> The IETF gave it's view on where the boundary for IPv6 blocks to end >> sites should be (i.e., the /48 recommendation) in RFC 3177 back in the >> 2000-2001 time frame. >> >> At that time, there were plenty of folk in the IETF that thought the >> IETF could/should set address policy, notwithstanding fact that the >> RIRs were doing that for IPv4. >> >> RFC 3177 was a way for the IETF to make a recommendation to the RIRs, >> without stepping on RIR toes (too much). Note that it is only a >> recommendation, and the RFC is informational. >> >> The fact is, the /48 boundary is _NOT_ architectural, and saying it is >> doesn't make it so. I challenge anyone to find a standards track >> document that relies on /48 being part of the architecture. (And you >> might want to have a look at >> http://tools.ietf.org/id/draft-narten-ipv6-3177bis-48boundary-02.txt >> as it does mention a couple of related things.) >> >> What the appropriate size of an assignment for an end site should be >> is really more of an operational issue than architectural one. If a >> site gets too little, and needs to get more later (maybe at the cost >> of renumbering) that is an operational issue. And the idea that we can >> give out "enough" address space to a site so that it doesn't have to >> renumber (ever) is pretty silly. After all, most end sites will need >> to renumber when they switch providers. Surely, we hope/expect a large >> number of such provider switches to take place over a 5 or 10 year >> period anyway? >> >> The RIRs adopted the "/48 to everyone" in its initial stab at IPv6 >> policy back in 2002. Even at that time, there was much screaming and >> gnashing of teeth from the operator community saying "wasteful", >> "excessive", "really stupid", etc. So, even though all the RIRs >> adopted the policy anyway, the unhappiness with /48 (as a general >> recommendation) didn't go away, and was repeated often at subsequent >> RIR meetings... >> >> Then, 2-3 years ago, RIPE made some really really big IPv6 allocations >> to a few ISPs. This raised eyebrows, because it raised the question >> that if so much space could legitimately be given out (and it was much >> much more than the operators would have been given for the same number >> of IPv4 customers), it was conceivable to imagine scenarios in 50-100 >> years where the IPv6 free pool was signficantly used. As one Cable >> Modem operator explained it to me: >> >> If I assign 4M /48's of IPv6 (one to each cable modem on my >> network), according to the HD-ratio I am justified to obtain >> something around a /20 of IPv6 addresses. In other words, I am >> justified in getting 268M /48's even though I am only using >> 4M of >> them. That would be enough for me to assign at least two for >> every household in the US (not just the 19M on my network). >> >> Now if all the cable providers (e.g., Comcast, Cox, Adelphia, >> Cablevision, Time-Warner, etc.) did the same for their networks; >> and each of the DSL companies made a similar move (SBC, Verizon, >> Quest, etc.); perhaps we could easily see the broadband >> market in >> the US alone obtaining some 16 /20's of IPv6 or a total of /16. >> There are only 8192 of those available in the current global >> unicast space of 2001::/3. >> >> Anyhow, you can see where this might lead... >> >> This led to a bunch of discussions and policy proposals in the RIRs, >> culminating with the adoption in ARIN, RIPE & APNIC of recommendations >> that adjusted the HD ratio thresholds and moved away from "/48 for >> everyone", making it an ISP (or LIR in RIR terminology) choice. The >> community feedback was that LIRs were smart enough to make reasonable >> assignments based on actual customer need. >> >> If one does the math, giving every home user a /56 instead of a /48 >> provides almost two orders of magnitude more headroom in terms of >> address usage. And at what cost? Surely, everyone will agree that >> giving a /56 to home sites is more than enough space for the foresable >> future! That's enough for 256 subnets per home site! That's an >> incredible amount of address space! >> >> (I have a really hard time reconciling the previous paragraph with the >> subject of this thread.) >> >> It is worth noting that there are no _firm_ recomendations in the >> current RIR policies (in the sense of saying you must give home users >> a /56) , because in discussions at ARIN and APNIC in particular, there >> was pushback from the operations folk on being to prescriptive. They >> argued that they are in the best position to decide reasonable >> assignment sizes and wouldn't support more rigid guidelines. That >> leads me to doubt that the specific propoasl that was mentioned that >> started this thread will actually get much traction within ARIN, but >> that is not my problem. :-) >> >> Folk should note that a policy proposal submitted to an RIR is not >> unlike an individual submission "submitted" to the IETF. Best to >> treat it as such. YMMV. >> >> I find the fact that RFC 3177 has not been revised to reflect the >> reality of today is a bit disapointing. Even in some of the messages >> of this thread, I sense denial about the proper/actual role the IETF >> plays in setting address policy. I see some of the same people arguing >> here that /48 should not be changed, despite having made the same >> arguments on RIR lists and having lost... There is water under the >> bridge here folk... >> >> The reality is that "/48 for everyone" has been overcome by events. If >> you don't like that, take it to the RIRs. >> >> And, FWIW, I was one of those that pushed for the changes. As one who >> originally supported of the /48 recommendation in RFC 3177, I think it >> was a mistake. Giving a /48 to every home user by default is simply >> not managing the address space prudently. Home users will do more than >> fine with a /56. >> >> Thomas >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf