Thomas and Jordi, I of course share the worry that the operators will start charging differently different size end-user allocations. However, I feel there is little we can do about the in the IETF and therefore I would see that we should not use too much time on this.
I think the only practical thing we can do is to advice that the end-user network will have enough addresses to satisfy its communication needs to avoid the introduction of e.g. NAT into IPv6 networks. Cheers, Jonne. On Thu, 2005-07-14 at 11:11, ext Thomas Narten wrote: > Hi Jordi. > > > I've read yesterday this document, and I'm basically ok with it, but with > > two considerations that I think must be worked out it parallel somehow: > > 1) HD-Ratio modification, as it seems to be an integral part of the > > discussion. > > IMO, changing the HD-ratio is a no-brainer, and I suspect that many > people feel the same way. It's an easy change to make and has minimal > impact. Indeed, there is already an ARIN proposal to do this: > > http://www.arin.net/policy/proposals/2005_5.html > > So yes, I expect this will be done and will personally push to see > this happen. > > > 2) I've the feeling that if we suggest the ISPs to move to a /56, they will > > then charge the customers (SOHO, end-users) or create to them a lot of > > troubles to get a bigger prefix when this is needed. > > We should be careful NOT to assume that just because something is done > one way in IPv4, it will be similar in IPv6. > > Indeed, I think one of the big cultural changes w.r.t. IPv6 is the > notion that end sites get subnets (emphasis on plural) where this is > clearly NOT the norm for IPv4 today. My sense is (from talking to folk > in the RIR community) is that they all believe this, and that ISPs > working with IPv6 also get this. So I think we've already changed the > starting point here. > > Also, in IPv4, the existing practice is to give out a single > address. There are multiple reasons for this, some cultural (i.e., > status quo). But another point that I think people sometimes forget is > that the existing protocols and busines practices have been built > around giving out a single address (rather than a subnet) and such, > getting a subnet is, in fact, an exception to the norm. As we know, > exceptions can cost more, i.e., in terms of help desk support, etc. > > So even though ISPs in IPv4 do tend to charge more for "more than one > address", the reasons for that are a bit subtle, and when they say its > because "more address just cost more", that is really just FUD. In no > case can the case be made that it is because the extra addresses > actually "cost more", i.e., in terms of RIR policies. > > Again, my sense in the RIR regions is that folk want the RIR policies > to be very clear that addresses should be available to end sites at > very low cost (i.e., essentially free), and that the cost of a /48 > should be the same as a /56 or /64. And with DHCPv6 prefix delegation > (as the protocol/operational mechanism for achieving this) I think we > are on track to see the right thing happen. > > To ensure that happens, the RIR policies will need to be sure that > when LIRs need more space from RIRs, the justification should be > based entirely on whether the existing space is sufficiently utilized > (based on the HD-ratio) with the metric being completely neutral as to > whether end sites are getting /48s or /56s. > > > My feeling is that today we believe that 8 bits for subnetting is > > enough, but I think will not be the case soon and this barrier will > > then be again a stopper for enabling innovation. > > I think there is a general feeling in the RIR community that folks > that ask for more than a /56 should generally get it more-or-less by > asking. I'd welcome help in how to word this. What we don't want is > folk automatically asking for a /48 "just because they can". In > practice, a /56 will really be enough for a large percentage of end > sites, for a long while. Hence, the current "justification" for space > is probably best expressed in terms of size of a site in terms of > subnets. That is something objectively measurable and captures the > sense of whether additional space is really needed. > > > I know this one is somehow not an IETF business, but we must be > > worried about that and may be collectively work for the appropriate > > solution in the appropriate fora. > > We simply need to pay attention to what is going on in the RIR > community, and followup as appropriate. The good news is that my own > sense (from going to ARIN meetings for 3 years or so, and attending > the last RIPE meeting) is that the community there largely shares the > same goals as I'm hearing here. They do understand that IPv6 is > different than IPv4 and that we need to focus less on conservation > than IPv4. I think that most of the community is actually quite happy > about this. > > > The cost of managing addresses is not a recurrent cost. I mean, it will be > > ok to charge for a reasonable setup fee if somebody ask for a /48 instead of > > a /56, but charging 12Euros (or even more) per month per address as some > > telcos do in EU is a crime. > > No. I think there is no justification (in increased $$) for a /48 > vs. a /56. The RIR policies should be clear about that. That won't > prevent ISPs from (perhaps) doing this, but they will use weaker > arguments like "a /48 implies more traffic and therefore more $$". But > then again maybe not. In practice, with a /56, end sites can generate > plenty of traffic and ISP charges may end up having to switch to > something based on actual traffice being carried. > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
