- In practice, applications may treat these address like global scoped addresses.
I don't see how this can be true in general.
Here is an example using referrals; the three nodes involved are A, B, C. Node A and B are in the same site, have both local and global addresses, and C is in a different site.
Node A and B are communicating using these local addresses.
In particular, B contacted A using FQDN(A) and the naming system somehow so that they ended up communcating with local addresses. (My understanding is that part of the benefit of these local addresses is that local communication prefer using local addresses over global addresses.)
Yes, but how???
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).
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?
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.
The fundamental difference between unique local addresses and global
addresses is that the former are permentently unreachable by design
(except from the local domain) whereas the latter might be temporarily
unreachable due to some failure.
I believe this means that applications need to be aware of the difference between the two types.
Hence not ready for proposed standard IMHO.
There is another problem: the global routability of these addresses is completely ambiguous. First the draft says "the scope is global". Then "don't expect them to be routable" and finally "filter them".
This is no good. Today, there is no difference between addresses that are unroutable by design, and addresses that are unroutable because of limitations in the routing system. But as the routing system evolves, this is subject to change. Suppose we build a locator/identifier separation mechanism, and some people start using these addresses as stable identifiers, while others use them as local-only addresses. This is going to create a huge mess as part of this address space must now (still) be filtered, while another part must be allowed through _everywhere_ in the world.
So my question is: are unique local IPv6 unicast addresses unroutable by design yes or no?
Iljitsch van Beijnum
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
