North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Iljitsch van Beijnum
  • Date: Mon Oct 01 04:40:04 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".