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

["Kevin Kargel" <[e-mail]>]

I concur wholeheartedly on all points.  If one wants a universally
visable address use PI .  With IPv6 if an organization cannot or refuses
to get their own PI space they can get space from their provider.  When
they choose to change providers they are not renumbering, they are just
re-prefixing..  I don't think it will be that painful.  

Hosts with no need to contact the world can use ULA..  hosts that need
to contact the world directly can use PI.  Simple proposition.

For the folks that really want to use NATv6 I don't see anything
preventing them from doing it.  It doesn't make any sense to me but then
it doesn't have to.  They can do whatever they want within their network
boundaries and they don't have to ask anyone.  I see no reason for a
rule legitimizing a policy that is already within the sysadmin's purvue.

Publicly advertised address and/or defined space should be public
address space and routable.  Unrouted address space does not need to be
publicly advertised or defined.  I see no reason to complicate that.

Kevin

:$s/worry/happy/g 

 

> -----Original Message-----
> From: james woodyatt [mailto:[e-mail]] 
> Sent: Thursday, June 21, 2007 1:42 PM
> 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.
> 
> 
> --
> james woodyatt <[e-mail]>
> member of technical staff, communications engineering
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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