In message <506c889b.4070...@centurylink.net> Jeff Bowden writes: > Curtis, > > I agree with your addition of that paragraph with the one exception of > removing the "at no additional cost" phrase. I agree it should be that > way but it is up to the individual ISP and not the IETF as to what > should and should not be charged for. > > Yes, lets move on. > > Best regards, > Jeff Bowden
The "at no additional cost" phrase is consistent with RFC6177. See first paragraph in section 2 "2. On /48 Assignments to End Sites". Looking back at some of the original motivations behind the /48 recommendation [RFC3177], there were three main concerns. The first motivation was to ensure that end sites could easily obtain sufficient address space without having to "jump through hoops" to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification. As a comparison point, in IPv4, typical home users are given a single public IP address (though even this is not always assured), but getting any more than one address is often difficult or even impossible -- unless one is willing to pay a (significantly) increased fee for what is often considered to be a "higher grade" of service. (It should be noted that increased ISP charges to obtain a small number of additional addresses cannot usually be justified by the real per-address cost levied by RIRs, but additional addresses are frequently only available to end users as part of a different type or "higher grade" of service, for which an additional charge is levied. The point here is that the additional cost is not due to the RIR fee structures, but to business choices ISPs make.) An important goal in IPv6 is to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks" and to ensure that end sites can easily obtain address space. The phrase "SHOULD provide these shorter prefixes at no additional cost" is much shorter, more direct, and after all is only a "SHOULD". There is no justification to charge more for a shorter prefix than /64 other than providers tendency to charge for anything they can charge for even if there is no incremental cost to them. I think that phrase should stay. btw- At some prefix length (maybe shorter than /56 or /48) it is not unreasonable to expect some form of justification. After all, a /56 provides 256 subnets and a /48 provides 64K subnets and that is a lot of subnets for a home or soho or small business. Curtis > On 10/3/2012 12:36 PM, Curtis Villamizar wrote: > > In message <506be6ae.5070...@globis.net> > > Ray Hunter writes: > > > >> Why not just add RFC 6177 BCP 157 > >> http://www.rfc-editor.org/bcp/bcp157.txt as a normative reference in > >> draft-ietf-homenet-arch? > >> > >> That's a lot shorter than re-hashing the whole discussion within Homenet. > > Clearly some providers aren't getting it so repitition may help, but > > not repitition of the entire argument made in RFC6177. > > > > For example: > > > > This document obsoletes RFC 3177, updating its recommendations in the > > following ways: > > > > 1) It is no longer recommended that /128s be given out. While > > there may be some cases where assigning only a single address > > may be justified, a site, by definition, implies multiple > > subnets and multiple devices. > > > > One provider is doing a trial allocating /128 addresses and alegedly > > targeting this at *business service*. /64 later (no date). shorter > > prefixes still later (also no date). So either they are not reading > > RFC6177 or they are not getting it. > > > > Wording which refers to RFC6177 would help. Adding the one sentence > > below to that would also help. How about: > > > > If home networks are to avoid having to subdivide /64s, then > > consumer oriented service providers MUST allow customers to easily > > request and get prefixes shorter than /64 and SHOULD provide these > > shorter prefixes at no additional cost. Allocation of shorter > > prefixes than /64 is recommended in RFC 6177 BCP 157 [RFC6177]. > > > > If there is no objections we can end this part of the thread and move > > on to the rest of the suggested changes to the draft. > > > >> Curtis Villamizar wrote: > >>> Now that we beat summary item #12 to death, can we please turn our > >>> attention to the remaining 18 summary items listed below and the diffs > >>> to the draft? > >>> > >>> btw- I think the concensus on summary item #12 is that maybe we can > >>> add the following points to the framework. Subnets longer than /64 > >>> are bad. Some devices don't support DHCPv6, therefore SLAAC is > >>> essential. Consumer oriented service providers of must allow > >>> customers to easily request and get prefixes shorter than /64 and > >>> preferably at no additional cost if we are to avoid having to > >>> subdivide /64s. > >>> > >>> Curtis > > [ ... trim ... ] > > > > I think your reply was just concerning the above paragraph so I > > trimmed the rest. > > > > Curtis > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
