+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> 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
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
homenet mailing list
home...@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
home...@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--------------------------------------------------------------------
IETF IPv6 working group mailing list
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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
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
--------------------------------------------------------------------
