"Fully stable" would be static and I don't think anyone is suggesting static. While devices must be able to survive address changes, they should not have to change addresses frequently.
Using ULA's and the availability of Global addressing are orthogonal issues. ULA's are the new Link Local's in a routed home. tom On 3/27/12 1:01 PM, "Jari Arkko" <[email protected]> wrote: >I fully agree with these comments from Ray. Basically, when hardware >changes on some router it is pretty much given that some address will >change somewhere. And I don't think fully stable addressing is a good >goal to begin with. Make the devices survive addressing changes, and >we'll be fine. > >Initial ULA generation before any connectivity with the Internet can be >reached is fine, however. > >Jari > >On 22.03.2012 14:49, Ray Hunter wrote: >> As requested by Tim: My comments on ULA use in Homenet posted in >>consolidated manner to the issue tracker. >> >> 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. >> >> >> Issue 1: One reason ULA seems to be mentioned is "time-invariance of >>addressing for use by sensor networks." >> >> Using the example of an electrician setting up a sensor network in a >>home before an ISP is present, and expecting time-invariant ULA >>addresses. Firstly, the electrician would have to generate a Global ID >>for ULA when the lights are installed. The electrician can generate a >>unique Global ID (and hence the /48 prefix of ULA) using the procedure >>in RFC4193. >> >> Problems with this are: >> 1) The /48 ULA prefix is tied to a time (when the electrician pressed >>the "generate ULA" button) >> If a user regenerates the ULA prefix later, the algorithm will generate >>a different /48 prefix: all addresses in the house will change >> >> 2) The /48 ULA prefix is tied to a MAC address (of the router or device >>used to seed the ULA prefix generation algorithm) >> If a user changes router hardware, the /48 prefix will change. Or else >>the seed stored in non-volatile memory will be lost when hardware is >>replaced. Again all addresses in the house will change >> >> 3) The Global ID portion of the ULA has to be manually assigned to each >>of the routers (if there's more than one) as there's no mechanism to >>distribute Global IDs today. >> Homenet needs autoconfiguration. >> >> 4) Even if the /48 prefix is made invariant, the /64 LAN prefix >>generated from it probably won't be invariant as hardware is added, >>replugged or removed. >> Again, OK for manual configuration like an enterprise network, but >>Homenet wants autoconfig. >> >> 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. >> >> >> >> >> Issue 2: Use of multiple ULA Global ID's in Homenet may also cause >>problems with source address selection (3484-revise). There is no way to >>know which ULA's are connected to the local Homenet, and which are >>distributed on remote Homenets spread over the Internet. This causes >>problems with potential ULA leakage, and in determining priority between >>PA-derived addresses and ULA addresses when both are available and the >>default 3484 or 3484-revise rules are followed. >> >> A workaround might be to be redistribute a non-default RFC3484-revise >>policy table to all end nodes via draft-fujisaki-dhc-addr-select-opt-07, >>but its not clear that all end nodes will support this mechanism, nor >>how the contents of the policy table would be managed in a distributed >>and automated manner. >> >> >> Issue 3: 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." >> >> >> regards, >> RayH >> >> >> homenet issue tracker wrote: >>> #4: Use of ULAs >>> >>> CN1 in the -02 text says ULAs should be provisioned by default. Do >>>we >>> agree? And if so, should they be preferred over globals? The new >>> 3484-bis has changed so they are not *unless* a specific /48 for the >>>site >>> is added to the 3484 policy table with higher precedence than >>>globals. We >>> should design something that works when disconnected from the >>>Internet. >>> Also, we currently say nothing about ULA-only devices and their >>> reachability from outside the homenet; do we want to? >>> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet >> > > >_______________________________________________ >homenet mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
