Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

[Tim Chown <[e-mail]>]

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
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>> _______________________________________________
>>> homenet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/homenet
>> _______________________________________________
>> homenet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------