Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

Tue Oct 2 08:43:57 UTC 2007

On 1-okt-2007, at 19:56, Stephen Sprunk wrote:

>> The problem with NAT-PT (translating between IPv6 and IPv4
>> similar to IPv4 NAT) was that it basically introduces all the NAT
>> ugliness that we know in IPv4 into the IPv6 world.

> There is no "IPv6 world".  I've heard reference over and over to  
> how developers shouldn't add "NAT support" into v6 apps, but the  
> reality is that there are no "v6 apps".  There are IPv4 apps and IP  
> apps that are version agnostic.  The NAT code is there and waiting  
> to be used whether the socket underneath happens to be v4 or v6 at  
> any given time.

I could talk about APIs and how IPv6 addresses are embedded in  
protocols, but let me suffice to say that although your applications  
may work over both IPv4 and IPv6, this doesn't mean that the two  
protocols are completely interchangeable. NATs and their ALGs as well  
as applications WILL have to be changed to make protocols that embed  
IP addresses work through NAT-PT (or IPv6 NAT).

> The other thing is NAT is only a small fraction of the problem;  
> most of the same code will be required to work around stateful  
> firewalls even in v6.

There are different approaches possible for this. Opening up holes in  
the firewall is probably better than ALGs.

>> 1. for IPv6-only hosts with modest needs: use an HTTPS proxy
>> to relay TCP connections

>> 2. for hosts that are connected to IPv6-only networks but with
>> needs that can't be met by 1., obtain real IPv6 connectivity
>> tunneled on-demand over IPv6

> Neither solves the problem of v6-only hosts talking to v4-only hosts.

Huh? They both do, that's the point. (Although the former doesn't  
work for everything and the latter removes the "IPv6-only" status  
from the host if not from the network it connects to.)

> The fundamental flaw in the transition plan is that it assumes  
> every host will dual-stack before the first v6-only node appears.

You're right, that doesn't work.

> NAT-PT gives hosts the _appearance_ of being dual-stacked at very  
> little up-front cost.

Again, you're right. The costs will be ongoing in the form of reduced  
transparency (both in the technical/architectural sense and in the  
sense that applications behave unexpectedly) and the continous need  
to accommodate workarounds in applications.

Could you please explain what problems you see with the proxy/tunnel  
approach and why you think NAT-PT doesn't have these problems?

> When v4-only users get sick of going through a NAT-PT because it  
> breaks a few things, that will be their motivation to get real IPv6  
> connectivity and turn the NAT-PT box off -- or switch it around so  
> they can be a v6-only site internally.

Yeah right. Youtube is going to switch to IPv6 because I have trouble  
viewing their stuff through NAT-PT. (Well, they use flash/HTTP so I  
guess I wouldn't.) No, what's going to happen is that users will  
demand IPv4 connectivity from their service providers if IPv6-only  
doesn't work well enough.

On 1-okt-2007, at 20:15, Stephen Sprunk wrote:

>> The issue is that introducing NAT in IPv6, even if it's only in  
>> the context of translating IPv6 to IPv4, for a number of  
>> protocols,  requires ALGs in the middle and/or application  
>> awareness. These  things don't exist in IPv6, but they do exist in  
>> IPv4. So it's a  better engineering choice to have IPv4 NAT than  
>> IPv6 NAT.

> Of course ALGs will exist in IPv6: they'll be needed for stateful  
> firewalls, which aren't going away in even the most optimistic  
> ideas of what an IPv6-only network will look like.

That doesn't mean it's a good idea to embrace something that requires  
them, because every protocol needs an ALG of its own.

>> If both sides use a dual stack proxy, it's even possible to
>> use address-based referrals. E.g., the IPv4 host asks the proxy
>> to set up a session towards 2001:db8:31::1 and voila, the IPv4
>> host can talk to the IPv6 internet. Not possible with a NAT-PT
>> like solution.

> Only one side needs to proxy/translate; if both sides have a device  
> to do it, one of them will not be used.

Today, it's perfectly reasonable to assume that everything's  
reachable over IPv4. At some point in the future, everything will be  
reachable over IPv6. Somewhere in between, there could be a situation  
where some people are running IPv4-only and others IPv6-only, so  
access to a dual stack proxy would be beneficial for both types of  
hosts.

> Better, if both sides support the same version (either v4 or v6),  
> that would be used without any proxying or translating at all.

True. It would be nice if applications or OSes could use direct  
communication if a destination is reachable that way and only use the  
proxy when there is an IP version mismatch.

>> Tunneling IPv4 over IPv6 is a lot cleaner than translating  
>> between  the two. It preserves IPv4 end-to-end.  :-)

> And when we run out of v4 addresses in a few years, what do you  
> propose we do?

Use NAT for the IPv4 connectivity, I'm afraid.

> It makes little sense to tunnel v4 over v6 until v6 packets become  
> the majority on the backbones

No, the way I see it you would have an IPv6-only local network and  
then have a translation box at the edge of a corporate network or in  
an ISP network. So you'd be in the IPv4 world before you hit any  
major backbones.

> -- and the only way that'll happen is if everyone dual-stacks or is  
> v6-only.

There is a difference between the networks and the hosts. Upgrading  
networks to dual stack isn't that hard, because it's built of only a  
limited number of different devices. For the same reason, running  
IPv6-only is pretty close to being feasible. (It already is if you  
don't mind conf t and can skip the fancy management stuff.) On hosts  
you have the trouble that all applications must run over IPv6 before  
you can yank the IPv4 address and while everything still has IPv4  
anyway, there is little value in adding IPv6.