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
