Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

[Paul Timmins <paul () telcodata us>]

David Conrad wrote:
> Paul,
>
> On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote:
>   
> > If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old 
> > address.
> >     
>
> Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address 
> returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are 
> specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network 
> management systems, etc.?  See sections 5 and 7 of 
> http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt
>
> The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy 
> technologies such as NATv6 to reduce that cost.  Some folks have made the argument that for sites large enough for the cost 
> of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the 
> administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now 
> will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing 
> system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said 
> they won't do).
>   
Put your recursors, network management systems, fileservers, etc on ULA 
addresses like I was talking about earlier. Then you don't have to 
renumber those.

So the only change you should have to make is a firewall change.

Imagine a world with RFC-1918 and public ip space safely overlayed. For 
anything you hardcode somewhere, unless it has to be publically 
reachable, use ULA addresses and don't ever change them.

You could even choose to not have public IP space on your servers by 
removing autoconf, though you could have public space on them so they 
can apply updates, and simply block any inbound access to those 
statefully with a firewall to prevent any outside risk.

-Paul