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

[Anders Brandt <[e-mail]>]

Ray,

> So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements,
> rather than on ULA in and of itself.

I agree that we must concentrate on the architecture requirements first.
It would however be unfortunate if these requirements ruled out the case of routing between homenet subnets based on stable addresses when
we have a couple of use cases for LLNs that call such functionality.
Maybe I should provide some use cases to Bing's draft to outline why this matters to us LLN guys.

I think I need some education on ULA routing - starting new thread...

- Anders

From: [e-mail] [mailto:[e-mail]] On Behalf Of Ray Hunter
Sent: Thursday, March 22, 2012 09:29
To: Brian E Carpenter
Cc: 6man; Tim Chown; Don Sturek; [e-mail] Group
Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

+1

Firstly, I have been lurking on the 3484-revise discussion in 6man for a long time. I agree with Brian's proposal:
[source & destination of a /48 ULA prefix match => prefer over 2000:/3 space. Otherwise don't (by default).]



Secondly, I think Homenet still has a lot of work to do, especially due to the autoconfig requirements.
Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + invariant addresses is likely going to be tough, if not downright impossible.

So why do we think we really need concurrent ULA+PA in Homenet as a base requirement? I'm not entirely convinced yet.

One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks." I don't see how "complete time-invariance of addressing"  is achievable together with autoconfig, even if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywhere. We've been down that rathole before. Site-local has been deprecated in RFC3879. And realistically speaking, any time someone replaces or adds or re-plugs any router hardware, the LAN's /64 prefix will change when using autoconfig.

I think it would be useful for the Homenet WG to propose a scheme for sensor networks to be able to maintain simple peerings despite the presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it would seem to me that a peering solution should use something that is long-term invariant as an identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invariant identifier could be automatically registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to the current IPv6 address and then verify the peering using their own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would trigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specific (and has to be solved anyway even with fixed addresses). I have an asterisk hardware phone that does something similar to this, so it can't require much code.


A reason concurrent ULA+PA seems to be required was that "intra-homenet communication should survive a long term ISP outage, and must be able to be established without any ISP connection present."

The first linkage would appear to be when ISP PA-derived prefixes within Homenet timeout via DHCPv6 PD meaning that a long-running session based on this address would drop. That has nothing directly to do with ULA, and may have other solutions.

Question: How long are ISP's setting their DHCPv6 PD timers in practice? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix might be a practical solution. How often has your ISP connection been down for say 10 days?

Another solution might be for the application to reconnect using another PA-derived address (if the user has two providers).


The second linkage may also have other solutions, such as only configuring a ULA prefix when no PA-derived prefixes are present.

That would mean at any one time the Homenet could potentially be running either ULA or multiple PA, but not both, which completely avoids any address selection conflicts and having to redistribute new RFC3484 address selection rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems."

So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements, rather than on ULA in and of itself.

regards,
RayH


Brian E Carpenter wrote:

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" <[e-mail]><mailto:[e-mail]> 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

[e-mail]<mailto:[e-mail]>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------



_______________________________________________

homenet mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/homenet



_______________________________________________

homenet mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/homenet





--------------------------------------------------------------------

IETF IPv6 working group mailing list

[e-mail]<mailto:[e-mail]>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------



--------------------------------------------------------------------

IETF IPv6 working group mailing list

[e-mail]<mailto:[e-mail]>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------





--------------------------------------------------------------------

IETF IPv6 working group mailing list

[e-mail]<mailto:[e-mail]>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------