[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt
Thus spake "Mark Andrews" <Mark_Andrews@xxxxxxx>
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
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------