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
