If ISC was to publish in the DNS
www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists today www.isc.org. 10M IN AAAA FC01:4f8:0:2::d
and you happened to have a machine with local addresses FC01:4f8:0:2::d.
You would be unable to reach www.isc.org from any machine receiving your ULA prefix as a consequence of the address selection rules.
I can't ping that same host with "ping fc01:4f8:0:2::d" either; whether the hostname is in DNS or not doesn't materially reduce the impact of a LA ULA collision.
This is the harm that can be caused when you publish a LA ULA.
That is certainly a possible outcome if you happen to collide with someone, that someone happens to be mixing PI/PA and LA ULA addresses for a given hostname, and you happen to try to contact a host via that hostname. Care to calculate the odds that your scenario will happen?
However, there do exist cases where the behavior is well-defined and correct even in the face of ambiguity. Suppose you have:
www-dev.isc.org. 10M IN AAAA fc01:4f8:0:2::d ;no PI/PA addys
which is (hypothetically) a development server only intended to be used by ISC's business partners, and ISC's LA ULA prefix is reachable over private links within the closed set of parties that need to use the dev server.
ISC's business partners can reach the dev server at the above name with no changes to their local nameservers (if they even have control of such), removing an opportunity for human error to intrude. OTOH, anyone else trying to contact the dev server will either reach a different host (due to a collision) or nothing at all -- either is acceptable to ISC. The hostname and IP are intended to be useless to any party not privately connected, whether colliding or not, and a LA ULA is no worse as a public response than, say, an address assigned to a competitor: neither is valid data yet neither is a protocol or logic violation.
If you don't have MUST NOT you don't have a way to point blame when things go wrong. With MUST NOT you can say please remove the address you are in violation of RFC XXXX.
from RFC 2119: "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label."
That sums up exactly how putting LA ULAs into the global DNS should be viewed: there exist circumstances when doing so is useful, but they require careful thought to prevemt unintended interactions. The LA ULA draft could certainly be enhanced with a list of what to consider and example scenarios where they do and don't work, but a MUST NOT isn't appropriate as long as there is _any_ legitimate use.
Removing the LA ULA from DNS will not solve the ambiguity problem anyway, nor does it mask the interaction with address selection rules. The problem still exists at the IP layer, and any application that supports IPv6 address literals (i.e. nearly all of them) would see the exact same behavior if users were to type in an ambiguous ULA literal instead of a hostname that resolved to that ULA. Should we also ban users from distributing LA ULAs via smoke signals or avian carriers to keep from trying to use addresses where they're not valid?
Finally, the verbage may give you something to point at when another admin does something you don't like, but that's the _only_ effect it will have. If he's going to ignore a MUST NOT in an RFC, what are the odds he'll make non-trivial changes to his configuration merely because _you_ had the misfortune to collide with his prefix? Of course, the only serious risk of collisions will be from intentional failure by both parties to follow the MUSTs in the draft...
2001:4f8:0:2::d is assigned by forcing the LL address then using auto assignment to get the other prefixes. It is done this way so it won't change with hardware changes.
I expect other sites will do similar things to provide stable addressing to their external machines. Collisions in addresses get much more probable when you start assigning the local parts by hand.
It reduces the collision space from 2^128 to 2^64, which is significant, but LA ULA prefixes are sufficiently unique that the rest of the address doesn't need to be. With 40 bits, we'll need over a million sites fully interconnected using LA ULAs before there's a 50/50 chance of prefix collision... Of course, since ULAs' scope is expected to be from one to a few thousand sites, making the odds of collision on the order of 2^-15 to 2^-40 for each ULA prefix. It is safe for us to act as if LA ULAs were unambiguous and let layer 8 detect and correct collisions if they ever occur.
Now consider the odds of a human error at a registry that results in a duplicate assignment; since it's nonzero (provable, since it's happened to me) should we also start treating PI/PA space as ambiguous just in case? No, we act as if PI/PA space were unambiguous and let layer 8 detect and correct duplicates when they occur. Notice the symmetry there?
In the end, the entire DNS paragraph is totally unenforceable thus the choice of SHOULD NOT or MUST NOT is not going to change a darn thing in real deployments. Consensus was achieved on this point long ago, and there is no indication that has changed or that it would make a meaningful difference even if it had. This effort would be better spent on other parts of this draft or on building support for CA ULAs and/or end-user PI space.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
