Top posting: while I agree with Mark's points, I think the shortest path to where we need this draft to go is to accept Curtis' text as is.
Brian On 03/10/2012 20:35, Mark Townsley wrote: > What about taking section 5 (summary) of RFC 6177 as a guide and apply it to > our specific case? I don't think we would conflict with any of the > statements, but we could provide a bit more justification and direction than > what is there for the homenet specifically. For example, the "operational > considerations" for the site can be further refined to mean the automatic > prefix distribution mechanisms running in the homenet router (as there is by > definition no human operator of the network assigning prefixes, but an > algorithm that we have designed). > > Also, RFC 6177 dances around the "cost" issue with this type of language: > > - assigning a longer prefix to an end site, compared with the > existing prefixes the end site already has assigned to it, is > likely to increase operational costs and complexity for the end > site, with insufficient benefit to anyone. > > In the homenet context, we could expound a bit on the "insufficient benefit > to anyone" case, suggesting that /64-only residential service can lead to: > > - IPv6 not reaching all devices in the home, despite IPv6 being provided by > the ISP. (Clearly this should be something that an ISP does not want to > happen, or why else would it even have gone to the trouble to deliver IPv6 in > the first place?) > - CPE employing NAT or other techniques that introduce complexity and > unpredictable behavior into the home network that could lead to service calls > and disruption, even if these mechanisms are not a part of any IETF > recommendation. > > Finally, at the protocol level perhaps we should state that, by default, > DHCPv6 PD in a homenet-capable router always "hint" that it would like a /48 > prefix (as can be done today, but rarely is I believe) - i.e., the CPE by > default "asks" the ISP for the maximum, as clearly that is what any CPE would > like to have to work with if it actually knows how to distribute /64s within > the home network. Protocol-wise, this is only a "hint" of course, the ISP can > provide a /56, /60, or even /64 if it wants. But why not go ahead and nail > down that if you are a router that actually knows how to handle a large > prefix, mention that fact in the initial protocol exchange. > > - Mark > > > On Oct 3, 2012, at 8:48 PM, Jeff Bowden wrote: > >> 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 >> >> >> >> 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 _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
