Don,
On 2012-03-22 01:24, Don Sturek wrote:
> Hi Tim,
>
> One more consideration:
> In the home, it is possible that multiple independent subnets could be
> combined, each with their own ULA prefix. This would happen in cases
> where the homeowner buys multiple silo'ed solutions (like a home
> automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a
> cross connect device that integrates these solutions.
Yes, anything could happen and probably will. So while a single ULA per
site is the simple and obvious case (and I don't have any argument for
Anders except KISS), there *will* be cases where several ULAs pop
up, and I think resolving routing issues in that situation is likely
to be troublesome. We can't resolve it as we do for enterprise networks
by saying that the network's manager will manually configure appropriate
routes.
Brian
> Don
>
>
>
>
>
> On 3/21/12 4:55 AM, "Tim Chown" <[email protected]> wrote:
>
>> On 20 Mar 2012, at 21:25, Brian E Carpenter wrote:
>>
>>> On 2012-03-20 21:51, Anders Brandt wrote:
>>>> It is a surprise to me that ULA addresses are not by default routable
>>>> within the site.
>>>> I can easily imagine a number of LLN border routers which autonomously
>>>> allocate
>>>> different ULA prefixes for use within their individual LLN subnets.
>>> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they
>>> cover an entire enterprise or home network, but not if they cover a
>>> subset.
>>>
>>>> Meeting a ULA address outside the local prefix will cause the LLN node
>>>> to forward
>>>> its IP packets to the default gateway (border router) of the LLN
>>>> subnet. This way
>>>> packets can travel between LLN subnets using normal routing with
>>>> long-term stable
>>>> ULA addresses. We need the stable addresses for control-style
>>>> applications in LLNs.
>>>>
>>>> Obviously it requires a routing protocol in the (homenet) LAN but are
>>>> there other issues?
>>> It doesn't just require a routing protocol; it also requires a routing
>>> policy
>>> that knows which routers have to block the ULAs (plural). That seems a
>>> lot
>>> more complex that a rule that says only a border router originates and
>>> delegates
>>> a ULA prefix, because that border router would also know to block the
>>> prefix across the border.
>> So we need to determine what the homenet arch text will say on this.
>>
>> I think the assumption so far has been that, as per PD8 in
>> draft-ietf-homenet-arch-02,
>> one router would be elected the "master" to delegate /64 ULA prefixes
>> within the
>> homenet, both to ULA-only LLNs and to links that also have a GUA prefix.
>> If there's
>> an assumption an LLN router will not support that, and instead generate
>> its own /48
>> ULA, we need to talk about that, or any other scenario that will lead to
>> multiple /48 ULAs
>> in a single homenet site.
>>
>> The arch text currently says that ULAs should be used (CN1) and that ULAs
>> should be
>> preferred for internal communications to GUAs (section 2.4). It doesn't
>> say how connections
>>from outside the homenet can be made to internal ULA-only devices.
>> The 3484-bis text has changed the default ULA preference to protect
>> against ULA leakage,
>> so if you now want ULAs preferred you need to somehow inject the specific
>> site /48 ULA
>> being used with high precedence into the policy table (and as also
>> pointed out here if your
>> site is using less than a /48, you should also have some way to learn
>> what the site prefix
>> length is). In the homenet case is that injection achieved on receipt of
>> an RA, or would it
>> require the proposed DHCPv6 option to be used (which may not be widely
>> implemented
>> for some time, and the DHCPv6 server still needs to learn the ULA to put
>> in the option)?
>>
>> On the one hand homenet is saying "we'd prefer to use ULAs by default
>> without needing
>> some magic to achieve it" while 6man is saying "we need to protect
>> against ULA leakage,
>> so if you want to prefer ULA for internal connection stability figure out
>> the magic".
>>
>> This needs to be mapped to words for the homenet arch text.
>>
>> Tim
>>
>>> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
>>> and discuss it over on v6ops.
>>>
>>> Brian
>>>
>>>> Thanks,
>>>> Anders
>>>>>> You'll find the above logic in the current 3484bis draft.
>>>>>>
>>>>>> -Dave
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [email protected]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> homenet mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>> _______________________________________________
>>>> homenet mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [email protected]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email protected]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
