Re: [v6ops] Operational Consensus on deployment

[Philip Homburg <[e-mail]>]

In your letter dated Tue, 05 Aug 2014 20:33:14 +0200 you wrote:
>The dual stack transition has indeed already failed. If you're located
>in Europe, Asia, or Latin America, chances are that you simply cannot
>obtain the IPv4 addresses you need to run dual stack. North America
>should be in the same situation shortly.

If dual stack implies no NAT anywhere what is then the correct term for
NAT44 or NAT444 along with native IPv6?

Just curious. I would call that dual stack. But you don't appearently.

>As for additional help needed, well, I'm trying to put my money where my
>mouth is and coming up with a solution to these problems - you could
>help by reviewing my drafts. :-) The solution works, there is already
>running open-source code, so rough consensus is all that's missing...

My gut feeling is that translating IPv4 packets to IPv6 or vise versa is
bad idea. Some thing will come up to make your life miserable. In some
sense it is very similar to tunneling.

I think it is safe to say that in your model you have enough public IPv4
address to run your services. What your proposal eliminates is the need
for internal IPv4 addresses.

The question is then, why not simply run on RFC-1918 addresses internally?
Afterall, usually the goal is to provide IPv4 services. 

Maybe our setup is unique, but we have quite a few servers in remote
data centers that need to access internal servers. What we do is have
ACLs in the firewalls to only allow the addresses we know about and keep
the rest of the Internet out.

In your model, any IPv4 address in a remote data center would either have to
translated to an IPv6 address (which of course nobody recognizes) or we
need an IPv4 firewall infront of the SIIT Gateway. Leaving the dual ACL
problem in place.

If I look at our system, if we would just drop IPv4 support for all internal
communication then we would probably see a similar reduction in complexity.
Leaving only the communication between the load balancer and the actual
web front-ends as something that could be moved to IPv6.