On Jun 21, 2007, at 11:03, Paul Vixie wrote:
mark andrews has [observed] that there is no need for the
resolution perimeter of a PTR to differ from the routing perimeter
of the IP address described by that PTR. yet here we have a large
set of folks who [are] telling us that yes we do need to be able to
resolve a PTR from places where the addresses won't be routable
[...]
what's wrong with this picture?
My heretical opinion follows.
We successfully deprecated site-local unicast addressing by painting
it with the stink of IPv4 network address translation. However, we
retained the technical consensus that unreachable nodes still need to
be uniquely addressable, and what's more: these unreachable global
scope unicast addresses must be assigned from a registry with a
single global root.
My heretical opinion is that the second technical consensus is
wrong. We should deprecate the 'L' bit in the ULA address type and
make all ULA into locally allocated addresses. That way, we will
have carved off a well-known prefix (like all the other non-routable
prefixes) where nodes are neither uniquely addressable nor reachable
on the public Internet. I contend the 'L' bit was never a good idea;
it was a placeholder for those wishing to retain network address
translation in IPv6. There, I said it.
I view all these attempts to establish a global registry for
allocating unreachable, yet uniquely addressable (from the public
Internet) unicast addresses with suspicion. Arguments about the
unacceptability of the birthday paradox risk in an prefix designator
space with 2^40 possible birthdays seem to be driven either by 1) a
frightening level of innumeracy, or 2) an ulterior motive that
proponents cannot admit publicly. I fail to see any other alternatives.
It boggles my mind that so many smart people seem to believe that ULA-
C is absolutely necessary to the operability of the IPv6 Internet. I
keep asking to see an explanation for why the risk of collision is
unacceptable, and nobody seems to be able to point me toward it. If
what you really want is to have IPv6 NAT, then let's see the real
arguments for why you want that. If any of them aren't properly
addressed in RFC 4864 and draft-ietf-v6ops-scanning-
implications-03.txt, then let's figure out what to do about it.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
