I'd like to drag this back to Dave's points 1-4. There are real
implementation issues with RFC4193. The questions are:
a) do these problems matter?
b) if so, what do we do about them?
Note that true random bits are really hard to come by right now in
current home routers. Sigh... Anyone who knows any chip architects,
please beat them bloody until they provide a hardware RNG....
So long as the addresses don't leak from the home network, and each home
router settles on unique addresses (maybe derived from their MAC
addresses), I'm not sure it matters. But someone who has thought longer
and harder about ULA's should think about the issues Dave's raising.
- Jim
On 03/27/2012 04:21 PM, Dave Taht wrote:
>
>
> On Tue, Mar 27, 2012 at 1:01 PM, Jari Arkko <[email protected]
> <mailto:[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] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> _______________________________________________
> homenet mailing list
> [email protected] <mailto:[email protected]>
> 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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
