On Tue, Mar 27, 2012 at 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. > > While I agree that having a ULA at the getgo is a goodness, following RFC4193 to the letter is very difficult. 1) You need time. If you do not have a battery backed up clock in the device (set to an appropriate value), you need to get time from the internet, which you can't do until you are on the internet. Or you could mandate time come from a gps. If you are getting time from the internet, you need sntp, ntp, or equivalent. From gps, something like chronyd. Without this, generating the ULA is generally going to come from 'time since the epoch or build date', and other sorts of randomness would be useful. 2) The infrastructure mandated by that RFC requires a sha-1 digest. Many devices (at least at present) do not come with a SSL based infrastructure from which that is a single function thereof. 3) It is my hope that hardware based RNGs start showing up soon in many more devices. But thus far, no luck, so finding an essential source of randomness would be good. 4) Lastly, without a solid means of getting the ULA and a human usable name out to the users's dns system (be that mdns, normal dns, etc), there is no way to map the idea of that number to a presentation that a user can 'just use'. I could be humorous about this (As april 1st is coming up) - flashing the blinking lights on a switch or router in baudot code might suffice for some, but... > 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<https://www.ietf.org/mailman/listinfo/homenet> >> >> > > ______________________________**_________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet> > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
