IETF working on making IPv6 and IPv4 talk to each other

An unlikely combination of IPv6 and NAT experts from the IETF met in Montr?al …


The problem that the IETF is facing is that, despite the family resemblance, there is a very fundamental difference between IPv4 and IPv6: IPv4 uses 32-bit addresses, while IPv6 uses 128-bit addresses. So how do you make a system that only has an IPv4 address talk to a system with only an IPv6 address? Simple enough: you translate the packet. The IETF standardized a way to do this years ago under the name SIIT (Stateless IP and ICMP Translation). However, SIIT has a big problem: the translation is one-to-one.

This creates problems in both directions: in the future, there won't be enough IPv4 addresses to give every system its very own address (why we need IPv6 in the first place!), so in the IPv6-to-IPv4 direction, it's necessary to have multiple systems share a single IPv4 address. This is relatively straightforward: just use SIIT and then regular IPv4 NAT. The NAT-PT (Network Address Translation-Protocol Translation) specification uses this technique, along with a system that intercepts DNS requests and generates responses with fake IPv6 addresses that have the 32 bits of the IPv4 destination encoded in the bottom 32 bits of the IPv6 address. Packets sent towards these addresses are routed to a translator, which then uses SIIT and NAT to create an IPv4 packet that is sent to the original IPv4 destination. Return packets are translated in the opposite direction.

The beauty of the NAT-PT system is that you can simply drop a box between the IPv6 and IPv4 parts of a network and everything will work—for the most part. Protocols like FTP, VoIP, or peer-to-peer applications will get confused because when an IPv6 system tells an IPv4 server or peer its IPv6 address, the server or peer won't understand and/or won't be able to use the IPv6 address. Ultimately, the DNS trickery drew much criticism within the IETF, so eventually NAT-PT was declared "historic" and no longer recommended for general use.

A better alternative 

NAT64, the proposal that I've been involved with, and others like it such as NAT6 and SNAT-PT, all address the shortcomings of NAT-PT to various degrees. For instance, if a host implements the DNSSEC secure DNS protocol, it obviously won't accept the fake DNS records with synthetic IPv6 addresses in them. But hosts could be modified to create those addresses themselves after performing the DNSSEC validation.

Since SIIT and NAT-PT were specified at the beginning of the decade, the IETF has done a lot of work on NAT, specifying best practices for NAT devices and ways for peer-to-peer applications to work though them using techniques with names like ICE, STUN and TURN. Most of these can also be applied to IPv6-to-IPv4 NATs and IPv6 peer-to-peer applications (which must be able to bypass firewalls where appropriate, if not NAT). So it looks like it will be possible to hammer out a reasonable specification for this part of the problem, even if it requires some changes on IPv6 hosts to make some more advanced functions work.

There's also the question of IPv4 clients talking to IPv6 servers, however. Although the translation can happen in much the same way, there is one big problem here: it's not possible to encode the IPv6 destination in the bottom 128 bits of a 32-bit IPv4 address in a fake DNS reply. There was considerable discussion in Montréal about whether it's necessary to solve the IPv4 client-to-IPv6 server issue as well as the other way around. After all, we know that there are many IPv4-only servers on the Internet; so far, everyone who runs a server on IPv6 also makes the server available over IPv4. But large users such as the US military have said they'll need the ability to solve the IPv4 client-to-IPv6 server issue in the future, so that settles that.

The question we're left with is whether to make an integrated solution for both directions, or get the v6-to-v4 direction out the door as soon as possible and take a bit more time to solve the harder v4-to-v6 direction.

Another interesting approach is Dual Stack Lite (not a misspelling; that's the actual name). This is based on the idea that if you provide NATed IPv4 connectivity tunneled over an IPv6 network, both (otherwise) IPv6-only hosts and hosts that only run IPv4 can connect to IPv4 destinations. The trick with DS-Lite is that although regular IPv4 packets are transmitted by the IPv6 host or a home router that serves the IPv4-only hosts through the tunnel, the big NAT box in the ISP network only has to look at the IPv6 address the packets come from, so it's not a problem if all of these hosts use address Interestingly, this makes what happens in this NAT box—the "carrier grade NAT" in DS-Lite parlance—almost identical to what a NAT64 translator does. The IETF has already decided that a solution like DS-Lite will be standardized.

Finally, there is a solution named IVI (IV and VI, get it?) which updates NAT-PT but also creates a direct, SIIT-like mapping between certain IPv4 and IPv6 addresses. Unfortunately, this requires some un-IPv6 like configuration on the IPv6 side, so it's not obvious to me how this is useful. But apparently, IVI has been in use in China for two years.

All in all it looks like those who'll have to do without IPv4 and run only IPv6 in some years will still be able to use most services that are only available on the IPv4 internet. But some years after that, the IPv4 holdouts that want to connect to IPv6-only services will probably have a harder time.

Expand full story

This article does not have a comment thread.

Need to register for a new account?

If you don't have an account yet it's free and easy.