Re: draft-ietf-ipv6-ula-central-02.txt use case

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 <jhw@apple.com>
member of technical staff, communications engineering

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------