Can this be generalized for anytime a prefix offered is not large enough
to cover the number of interfaces?


On 11/8/12 3:40 PM, "Robert Cragie" <[email protected]> wrote:

>Just to be clear - using a /64 will not necessarily break a home network
>with a LLN. It's just that some kludge will be needed  and the least
>preferable IMHO for LLNs is bridging.
>
>So I would suggest something like:
>
>"The home network needs to be adaptable to such ISP policies, and thus
>make no assumptions about the stability of the prefix received from an
>ISP, or the length of the prefix that may be offered. However, if only a
>/64 is offered by the ISP, the homenet may be severely constrained.
>Attempting to use subnet prefixes longer than /64 would break SLAAC, and
>is thus not recommended. Using ULA prefixes internally with NPTv6 at the
>boundary would be possible, but is not recommended for reasons given
>elsewhere. Another solution would be for the internal routers to revert
>to bridging mode, even though this would destroy the benefits of
>subnetting and has serious limitations with regard to heterogeneous link
>layer technologies and LLNs."
>
>Robert
>
>On 08/11/2012 4:15 PM, Mattia Rossi wrote:
>>>>> I don't think bridging should be considered for homenet. Don't forget
>>>>> the following in the charter:
>>>>>
>>>>> "Also, link layer networking technology is poised to become more
>>>>> heterogeneous, as networks begin to employ both traditional Ethernet
>>>>> technology and link layers designed for low-powered sensor networks."
>>>>>
>>>>> In a lot of these conversations, the "lightswitch guys" (as someone
>>>>> called the LLN proponents) seem to get forgotten.
>>>>>
>>>> So what happens if the "lightswitch guys" want to plug-in a router,
>>>> which they have to, as they can't bridge, but there's only one exit
>>>> router from one ISP which is managed and gets a /64 only?
>>>> SLAAC relay? I think in this case a /64 is simply not acceptable.
>>> OK, so there are failure cases and that too needs to be stated in the
>>> architecture. Send text.
>>>
>> So your text:
>>
>>   The home network needs to be adaptable to such ISP policies, and thus
>>   make no assumptions about the stability of the prefix received from
>>   an ISP, or the length of the prefix that may be offered. However, if
>>   only a /64 is offered by the ISP, the homenet may be severely
>>   constrained. Attempting to use subnet prefixes longer than /64
>>   would break SLAAC, and is thus not recommended. Using ULA prefixes
>>   internally with NPTv6 at the boundary would be possible, but is not
>>   recommended for reasons given elsewhere. The least damaging solution
>>   would be for the internal routers to revert to bridging mode,
>>   even though this would destroy the benefits of subnetting.
>>
>> might become:
>>
>>   The home network needs to be adaptable to such ISP policies, and thus
>>   make no assumptions about the stability of the prefix received from
>>   an ISP, or the length of the prefix that may be offered. However, if
>>   only a /64 is offered by the ISP, the homenet may be severely
>>   constrained. Attempting to use subnet prefixes longer than /64
>>   would break SLAAC, and is thus not recommended. Using ULA prefixes
>>   internally with NPTv6 at the boundary would be possible, but is not
>>   recommended for reasons given elsewhere. The least damaging solution
>>   would be for the internal routers to revert to bridging mode,
>>   even though this would destroy the benefits of subnetting.
>>   There are cases where neither bridging mode nor NPTv6, nor DHCPv6
>>   are feasible, e.g. if there are LLN subnets within the homenet
>>   which require remote access. In such cases a /64 assignment from
>>   an ISP will break the home network, and should therefore be avoided.
>>
>>
>> Feel free to rewrite it.
>>
>> Mat
>>
>> _______________________________________________
>> homenet mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>
>

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to