Re: [v6ops] Thoughts about wider operational input

[Philip Homburg <[e-mail]>]

>(Dual-stack cannot be the answer anyway - it will have all the issues
>of IPv4, plus the added complications of dual-stack.  Services need to
>be dual-stack, but for all the rest, single-stack IPv6 needs to be
>the end goal - see facebook etc)

Obviously, on an IPv6-only system, there is no IPv4, so the relative
priority of ULA compared to IPv4 does not matter.

I'm curious what IPv4aaS we want to deploy. I consider NAT64 a complete
disaster (even if the form of 464xlat). Given how the internet works, 
we will probably end up with NAT64 everywhere until the end of times.

>This is not what I had in mind.  If "we" decide that ULA is a good
>way forward, IETF can update RFCs, and vendors will eventually
>update their base OS.  It might take 5 years, but so will everything
>else in Big Enterprise land.

The problem with ULA is that we have lots of installations where hosts with
a ULA address don't have access to the IPv6 internet. Often, CPEs announce
a ULA when the CPE doesn't have an IPv6 uplink. 

In contrast, where RFC 1918 was meant for local IPv4 communication, it is 
now on a very large scale the primary method for a host to reach the IPv4
internet.

So to avoid the situation where we say that ULA is local and then use it
to connect to the IPv6 internet, we should just allocate a new space. And
explicitly give it the property to connect to the IPv6 internet through
through some sort of address translation.

There is also a nice tie-in with PI. Obviously, putting millions of PI
prefixes in BGP does not scale.

On the other hand, there is no such limit if the PI space is used behind NAT.