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

["Tony Hain" <[e-mail]>]

Lawyers and Sarbanes-Oxley type regulations drive some organizations to want
a registry that they can take to court if there is a future business-loss
due to an address collision. 

ULA has absolutely nothing to do with NAT, and all discussions about
IPv6-IPv6 NAT are a waste of time by those who want to cling to a comfort
source. People use address space in a variety of ways, and it is not
appropriate for the IETF or RIR community to tell them they can't do that.
What is appropriate is to set aside blocks that are recognizable for uses
that might have a detrimental impact on other uses. 

PI is not available to everyone because it has an impact on the global
routing system.

ULA-L is not appropriate for people with lawyers that want absolutes. 

ULA-C is not a real problem to implement, it just takes shutting down those
who want to make sure they retain control through the PI review process. 

Even those who acquire PI may want to use ULA-C to ensure that the multiple
layers of bogon filtering keep a private network private despite the best
efforts of fat-fingered network operators that are prone to typo's.

Tony



> -----Original Message-----
> From: james woodyatt [mailto:[e-mail]]
> Sent: Thursday, June 21, 2007 11:42 AM
> To: IETF IPv6 Mailing List
> Subject: 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.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------