JSBiff's Journal: A NAT, DHCP & DNS Based approach to IPv6 transition

I came across an interesting article by D. J. Bernstein about the IPv6 Mess. In the article, Bernstein raises several interoperability challenges for organizations who would be interested in migrating to IPv6, which potentially make it expensive and difficult to begin deploying IPv6 on the Internet alongside of IPv4.

Read More for a discussion of how I think some of these problems might be resolved.

The basic problem is that hosts configured with only IPv4 cannot talk to other hosts using only IPv6, and hosts running only IPv6 cannot talk to hosts running only IPv4. Because of this, all servers continue to need to use IPv4 in addition to IPv6, and so do all end-users. If you are using IPv4 anyhow, there never comes a point where you can transition to IPv6-only. In order for a transition to be possible at all, we need the ability for interoperability between the two protocols.

I have been wondering, is there any reason why a router/gateway device at the 'border' between an end-user, corporate, or ISP network could not act as a bi-directional 'bridge' between IPv4 and IPv6? That is, a device which accomplishes 2 basic functions: it maps IPv6 public addresses to IPv4 addresses (either public or private addresses, as appropriate), and it supports DNS queries which treat IPv6 numeric addresses as DNS domain names (maybe something where you replace colons with periods, replace the double-colon shorthand-notation with a special placeholder, like .xx., and perhaps put a special tld at the end, e.g. 2002:abcd:efgh:0001::1 becomes 2002.abcd.ef01.0001.xx.1.ip6 [are there currently any RFCs for a representation of an IPv6 address as a DNS name?]).

This system would be based on a sort of NAT, and a cooperating IPv4 DNS and DHCP server.

In typical usage, currently, NAT devices have a one-to-many relationship with the hosts inside the NAT. That is, typically, the NAT router has 1 public IP address, and multiple internal addresses. Is there any reason why a NAT server couldn't do many-to-many mapping?

When an IPv4 device connects to the network and makes a DHCP request, it would be given a version 4 address, IPv4 default gateway address, and IPv4 DNS Server address(es) as in normal DHCP usage currently. The DHCP server would register the newly leased IPv4 address with the NAT gateway, which would create an IPv6 corresponding address. The IPv6 address would serve as the main address for the IPv4 device behind the NAT, for any hosts on the Internet which use IPv6. So, now, the IPv4 'legacy' device can receive in-bound IPv6 connections, with the necessary translation between IPv6 and IPv4 being done by the gateway, so that the IPv4 device doesn't even know it's talking to an IPv6 peer, and vice-versa.

The cool trick here, for outbound connections, is that the NAT device could, I think, create mappings in the other direction too:

Consider some scenarios:

1) You have legacy devices (like a Tivo, Cell phone w/ Wifi, XBox/Playstation/Wii, etc) or applications (and so you need to configure your PC with IPv4 for the legacy app) which are not IPv6 compatible, but your network/ISP and the Internet at large has migrated to IPv6. The device or application uses DNS to resolve a name to an IP address (that is, in this scenario, no literal IPv4 address is trying to be resolved, but just a 'normal' dns entry like slashdot.org, or possibly one of the .ip6 entries as described above). Is there a way to allow the legacy devices or applications to still function?

      In this situation, my idea is that the following would occur: The IPv4 request is made to the DNS Server, but the DNS Server only is able to get an AAAA record for the server (which is for IPv6 addresses), but no A record (for IPv4 address). The DNS Server then makes a request to the the NAT to map the IPv6 external address to an IPv4 address internally. The NAT that sets up such a mapping using private network addresses which are not reserved by local policy for internal hosts (that is, maybe for your internal hosts, you are using 192.168.*.*, which leaves 10.*.*.* unused, and so available for this 'mapping'), so for example, the NAT adds an entry in the NAT tables that 10.0.1.14 maps to the IPv6 address 1234:abcd:ef01:1111::5 (NOTE that the IPv6 address might be for an external host *or* an internal host which is using IPv6 inside the LAN).

      The NAT then replies back to the DNS Server to use 10.0.1.14 for that IPv6 entry, which replies back to the legacy device with the mapped internal address of 10.0.1.14, and the DNS Server caches the IPv4 address for future lookups (temporarily; such caching should expire after some time if that DNS entry has not been referenced, and the NAT should also expire the mapping after the same amount of time, so that a different IPv6 host can be mapped to that private IP address).

      So, now the legacy device(s) attempts to open a connection to the server using the IP address it got back from DNS, which is the 10.0.1.14 address. The gateway device sees that the connection is for one of the 'mapped' addresses, and does the necessary NAT and routing to move the traffic back-and-forth between the IPv4 device, and the IPv6 device. This all happens *completely transparently* to the IPv6 host and the internal IPv4 host.

2) Similar to the above scenario, except no DNS query is performed; the app or device instead tries to connect to a hard-coded IPv4 address:

      In this scenario, if the hard-coded IPv4 address is for another IPv4 device which isn't on the local network, then perhaps the gateway could map the IPv4 address (as long as it isn't one of the non-routable address blocks) to an IPv6 address which embeds the IPv4 address.

      I've heard of something called 6to4 which is a way of carrying IPv6 traffic over the IPv4 Internet without using an explicit tunnel, which used a similar concept of embedding an IPv4 address into an IPv6 address. I don't see why a similar approach couldn't be used for allowing IPv6 hosts and gateways to connect to IPv4 hosts across the backbone. The packets would be carried as far as necessary as IPv6 packets, then translated back into IPv4 packets by a gateway server somewhere, when it transitions from the 6Bone to an IPv4 network.

3) You have legacy devices inside your network (maybe servers), which need to receive in-bound connections from an external IPv6 host.

      Since the legacy device's internal IPv4 address was mapped to a public IPv6 address when it received a DHCP lease, external hosts can make a connection to the public IPv6 address, and the gateway does the necessary NAT to pass the traffic to the internal IPv4 address, transparently to both the external and internal host.

      In conclusion, it seems to me that a strategy like what I've described should, I think, make it possible to allow the 'core' of the Internet (backbones and ISPs) to begin upgrading to IPv6 without breaking IPv4 devices. Then, you can begin upgrading 'edge' networks. Is there any reason why this wouldn't work, or wouldn't work well? Are people already doing this, and I'm just not aware of it (I tried googling information for IPv4 to IPv6 transition, and didn't see anything like this, though my research was only brief, and definitely not exhaustive)?

        Note: This all might sound pretty complicated, but I think that something like this could be included in 'home broadband' gateway devices from companies like linksys/cicso, d-link, netgear, etc, already configured for users so that it 'just works'. I think such routers could take care of this automatically. It might not even be necessary for users to install such a device at home - this 'bridging', it seems to me, could probably be done by ISPs.

    The only limitation I can think of at the moment, is that the ISPs would need to make sure they didn't try to service too many users with one gateway - because of the fact that you would be mapping IPv6 addresses to private addresses like 10.x.x.x, you are limited to how many mappings can be maintained by any given gateway at any given time, but I think that as long as you don't have a large number of users, there's enough normally unused addresses in 10.x.x.x and 192.168.*.* to allow for mapping a large number of IPv6 to IPv4 addresses. Even though the Internet needs Billions of addresses, I think it likely that a small set of users will only ever be connecting to a few thousand or tens of thousands of those hosts at any given time, so the approx 16.7 million private addresses in the 10.*.*.* network should, in most cases, be sufficient, I think.