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: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Ray Hunter Sent: Thursday, March 22, 2012 09:29 To: Brian E Carpenter Cc: 6man; Tim Chown; Don Sturek; home...@ietf.org 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" <t...@ecs.soton.ac.uk><mailto:t...@ecs.soton.ac.uk> 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 ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ homenet mailing list home...@ietf.org<mailto:home...@ietf.org> https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list home...@ietf.org<mailto:home...@ietf.org> https://www.ietf.org/mailman/listinfo/homenet -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
