> A simple method would be to check the first 48 bits of the IP addresses
> that are suspected of having "local" reachability. But this doesn't
> allow for the merging of two sites, which was presented as a rather
> prominent requirement during the site local wars (or at least the part
> I got to witness).
Good point.
> I don't believe two-faced DNS is a solution, because then the DNS
> server must know all the information the hosts are apparently unaware
> of, and know the exact reachability details of each possible pair of
> hosts to boot. I expect both internal information to leak out and
> internal hosts to be presented with external information only in many
> situations.
>
> A solution could be giving hosts access to local routing information.
> Is this something we want? Or do we drop the site merger without
> renumbering thing and work on renumbering instead?
At least having a mechanism to provide hosts with a list of which local
prefixes are likely to be routable wouldn't be hard.
But how many such prefixes is it reasonable to assume that
the most basic nodes will support? (If I read between the lines
about the claimed security befits of local addresses in the hain/templin
draft it seems like it is the simple small devices that supposedly
benefit most from unique local addresses, but those might also not want
to store a hundered such prefixes.)
Things brings us to the semantics of the "local only" communication when
there are both site mergers (with two or more local prefixes denoting the same
site) as well as having private interconnection of sites; which prefixes
should be included in the "local only" type of filter in each host?
> Note that these problems don't disappear once we sprinkle them with
> magic loc/id separation powder: it's still entirely possible for the
> system to choose a locator that doesn't work. But at least this is a
> problem that can be corrected somewhere lower (below the application)
> in the stack and optimized there, rather than dump the problem on
> applications and hope those will do the right thing after TCP times
> out.
Agreed.
I haven't yet thought about the utility of locator locators with
locatior/identifier separation. Perhaps they would be useful since
they can survive flash cutover renumbering (when DNS can't be updated in time)
but they might not provide benefits for controlled renumbering.
> So my question is: are unique local IPv6 unicast addresses unroutable
> by design yes or no?
I'll let others answer that question.
What I see in the draft is language like:
- Not possible to route Local IPv6 prefixes on the global Internet
with current routing technology. Consequentially, it is
necessary to have the default behavior of site border routers to
filter these addresses.
This sure reads like folks would like them to be globally routable
and that there are just some minor technical issues with the current
routing technology that prevents that (hah!). Sure looks like
a slippery slope to me.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
