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

Sun Sep 30 19:21:06 UTC 2007

On 29-sep-2007, at 2:11, Daniel Senie 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.

> NAT grew out of need. It didn't grow up in the IETF. We did have a  
> NAT WG, to document, define common terminology and guidelines. We  
> took a lot of heat for just documenting what was out there. The  
> marketplace resulted in the success of NAT. Even if there had been  
> limitless address space, it's unlikely NAT would have been avoided.

And how exactly does that relate to the discussion at hand?

For the purpose of this particular discussion, NAT in IPv4 is  
basically a given: coming up with an IPv4-IPv6 transition mechanism  
that only works with if no IPv4 NAT is present both defeats the  
purpose (if we had that kind of address space we wouldn't have a  
problem in the first place) and it's completely unrealistic.

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.

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

> So your fobia over all things NAT is so deep that you would insist  
> on the use of a SOCKS-like mechanism, breaking end-to-end  
> connectivity, to avoid implementing NAT of any sort. Pardon me for  
> thinking this is a stretch.

I don't see the problem with proxying, except that it only works for  
TCP. Yes, you need a box in the middle, but that's true of any  
solution where you have an IPv6-only host talk to an IPv4-only host.  
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.

>> 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

> Add more devices in the path, resulting in a tortured "end-2-end"  
> that has lots of points of failure, and lots of state in the  
> network for those tunnel endpoints, timeouts on same, etc.

Apparently these downsides aren't big enough to stop the use of PPPoE.

The advantage is that you can have an IPv6-only routed network. This  
at the very least avoids having to provision both protocols  
throughout the network, and probably avoids a lot more complexity  
that is necessary in typical IPv4 networks (NAT hole punching etc).

> I fail to see how your proposals preserve the end-to-end nature of  
> the Internet in any meaningful way. You've gone a long way to find  
> something, anything, that can take the place of NAT, but in so  
> doing, you've proposed solutions which do not appreciably differ in  
> effect on the function of the Internet.

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

This can indeed be used to avoid NAT if you use public IPv4  
addresses, but it's also the solution that incurs the least amount of  
NAT issues if you don't, because those issues stay in IPv4 where  
they're well known.

PS. someone told me that work on tunneling IPv4 over IPv6 is under  
way in the IETF under the name "softwires".