Networking #1: Backward Compatible with IPv4

IPv6 brings benefits in terms of network address policy, peer-to-peer support and privacy. By reducing IPv4 to backward compatibility we set the tone for a long-overdue transition. The approach given below makes it very attractive too; full IPv6 benefits for those who make the effort to at least install a tunnel, with fully reliable client-server usage patterns for those who stick to IPv4.

This article is part of a series on networking.

IPv4 is a very old protocol, and it has survived surprisingly well. The addition of Network Address Translation (NAT) allows sharing of addresses with a larger group, although at the risk that port numbers may have to be changed while also changing the address. This port change reduces the reliability of peer-to-peer exchanges, and it means that the worst case scenario's require a server to bounce off traffic. When your online conversation is only one-sided (you can hear the other but they cannot hear you, for instance) it is very likely caused by this problem.

Advantages of IPv6 over IPv4

Port changes by NAT are not a real problem with client-server protocols, so as long as we do not need peering, we can continue to use IPv4. In a peer-to-peer protocol, traffic passes directly between the end points. In media traffic, this is usually the goal, both for reasons of privacy and to offload servers. Using IPv4 generally means that "NAT traversal" techniques are needed, and that may involve bouncing traffic through a remote server. A salient example is Skype, which is said to be bounced by the NSA.

The addresses in IPv6 are much larger, so everyone can have their own, and NAT is no longer needed. Firewalls still are used, but they are much easier to pass through when both ends want to connect. This is known as transparent addressing.

In IPv4, virtually all addresses behind a NAT router are so-called internal numbers. There is a range 10.x.y.z, one at 192.168.y.z and another that runs from 172.16.y.z to 172.31.y.z. These offer enough room for in-house networks, but when designing a network with a few bits of information in the address, these quickly fill up. Random numbers of 24 bits run into 50% clashes around 5000 hosts, for example. IPv6 not only offers a broader range of addresses, but it also defines many practical address allocation policies by way of a prefix. This means that most software can behave smartly around these addresses, whereas the IPv4 ranges given above remain open to interpretation because they serve all those purposes at the same time.

As a bonus, there are several prefixes that incorporate an IPv4 address into the much longer space of an IPv6 address. For example, a given /96 prefix before the 32 bits of an IPv4 address may give a routable IPv6 address at 128 bits. In other words, an IPv6 address can express any IPv4 addresses, while the opposite is impossible. This makes that IPv6 is more general.

IPv6-only Internal Networking

These reasons make it interesting to look into IPv6 for internal networking. A common practice is doing both IPv4 and IPv6, but then the addressing problems, peering trouble all end up on the plate of the network designer, and not everything will work well. Plus, firewalls and routing must be setup, tested and maintained twice, which is costly and can be downright confusing.

An internal network can be IPv6-only, as long as it has a way of expressing IPv4 addresses as well. Given that, a generic layer of processing on the perimeter of a network may handle the mapping to the IPv4 world. This is how we will arrange the hosting stack for the InternetWide Architecture.

As a general approach, we consider a public interface iwo0pub that faces the Internet and translate it to a DeMilitarised Zone interface iwo0dmz that has been filtered; this includes the translation.

The translation from iwo0pub to iwo0dmz is almost direct, with just a firewall to stop undesired traffic patterns before they hit the internal services. It is generally transparent, and is most conductive to peer-to-peer protocols.

Mapping IPv4 to IPv6: Incoming Traffic

When a client accesses an IPv4 address, it needs to map to the internal IPv6 addresses. We do this in a number of steps, all targeted towards maximum use of the spares address and port space in IPv4. We do keep that mapping static inasfar as possible, because that reduces the need to keep state and work with timeouts and the resulting network-driven disconnects.

NAT46 is a technique to map IPv4 addresses to IPv6 addresses, and it can be part of a NAT64 technique doing just the opposite; when a mapping is static, this is easy to understand because traffic passes through in both directions.

Basically, every IPv4 address can be explicitly mapped to an IPv6 address,

172.16.0.1 <--> 2001:db8:172:16::1

You would not notice being relayed through IPv6, except when you were to ask the server for your IP address:

myclient$ ssh 172.16.0.1
Welcome on myserver.

myserver$ echo $SSH_CONNECTION
2001:db8:172:30::7012 60447 2001:db8:172:16::1 23

This allows the translation of a targeted address, but what to do with the IPv4 address of the sender? Simple enough, we can add any /96 prefix, but there actually is a standard namely 64:ff9b::/96, that can be used for any public IPv4 addresses. So this means that an arbitrary address is mapped with

w.x.y.z <--> 64:ff9b::w.x.y.z

These internal addresses do not have to be known to our internal network; we may setup firewall rules to further map the 2001:db8:172:16::, along with protocol and port information, as it can be directly reached over IPv6. To the service running on that IPv6 address and protocol port combination, the client now has a funny address, but it can respond to it -- as long as the return traffic passes back into NAT64. That is easily achieved, with routing tables that redirect the 64:ff9b::/96 prefix to NAT64.

It is also possible to treat TLS connections in a special manner; since these start announcing the server name that they are connecting to, it is possible to use that to further split incoming connections and thus multiplex more incoming channels on one external port. This is useful for IPv4 but the slight overhead it brings can be avoided with transparant addressing under IPv6.

Mapping IPv6 to IPv4: Outgoing Traffic

The question now rises how an IPv6-only service may connect to an IPv4-address. The answer is simply to use the same stateless NAT64 service, so we should use the 64:ff9b::/96 prefix for any such remote addresses.

Again, this can be solved in a generic manner, using DNS64. This is an extension that name servers can have, and that may be applied directly after any DNSSEC validation. The effect of DNS64 is to lookup IPv6 addresses with an AAAA query but, failing to find any, lookup IPv4 addresses with an A query and add a prefix to map the output into IPv6 addresses.

DNS64 is the perfect companion for NAT64, and allows your internal network to make client connections to any IPv4 address from an IPv6-only network.

Such connections however, are made from a local address and protocol/port which also needs to be mapped to IPv4. If the local address/port matches a published service this is trivial, but otherwise we need to resort to NAT to squeeze many IPv6-only clients into a small external IPv4 space.

This can be done in an IPv6 firewall by using NAT in that realm, and directing the output into NAT64 by using the prefix 64:ff9b::/96. This would be a dynamic translation, for the same reasons as in a home router for IPv4: to be able to squeeze many possible internal addresses into a few external addresses. The same disadvantages apply as with those NAT boxes, of course.

The NAT approach would be applied for any outward IPv6 traffic that is sent to NAT64, and only when no static mapping for published services can be used. This is very much like any NAT setup with port mapping for explicitly configured service forwarding rules. It just happens to be easier to do in IPv6 space. The result is an address that maps into the NAT64 statically mapped address space, so the local address too can be mapped to IPv4, even if this was originally not possible.

Given that we have NAT available, we may even use the privacy-friendly private IPv6 addresses that can be automatically generated under a routable /64 prefix. These addresses rotate regularly, and make it difficult for attackers to guess them; the NAT setup with port mapping would end up spreading the allocated external address/port combination too.

Full-Strength IPv6 for IPv4 users

The use of a NAT mapping will not be problematic in all cases, but it certainly devestates the reliability of peer-to-peer connections. Users who continue to put up with STUN guesses about NAT behaviour, or who are unconcerned about bouncing all media through external parties on a data-hungry Internet may continue to use this.

The NAT64 solution with DNS64 and IPv6 NAT will keep the Internet usable for IPv4 users, though with some added processing for their backward compatibility. Future patterns of peering may however be out of reach, simply because IPv4 with NAT is an incomplete solution to those goals.

For IPv4 users who cannot obtain their own IPv6 range, there is an option to run IPv6 locally and run it over a tunnel. We shall use the 6bed4 tunnel for this purpose, and set it up on a server in such a manner that it works directly. Only when two IPv4 users connect through 6bed4 and their networks cannot support it, would the traffic pass through a bouncing proxy -- but that would be the proxy selected by one of the participants, which can be held under own control, as part of a domain name solution.

The principle of 6bed4 is simply to wrap IPv6 packets into UDP/IPv4 packets. The IPv6 address is constructed from the IPv4 address and UDP port on each end point. There is a routing mechanism, and most importantly, active trying of direct connections between peers, and switching to that mode whenever possible.

Though it is possible to implement 6bed4 as a generic uplink to IPv6, it depends on the IPv6 routing policies of the network around the 6bed4 server whether this is possible. When this surrounding network is not setup to manage the specially formed addresses for 6bed4 then it cannot do this. This, however, is an extension that is not required for direct use of a service on a hosting platform that supports 6bed4 for local use.

Knowing your Priorities

The three schemes of reachability are, in slightly declining order of efficiency and user experience:

• Native IPv6 traffic is the best option;
• Tunneling over 6bed4 is the second option, but only available where a tunnel is installed;
• Mappings to IPv4 addresses are the last resort because they provide incomplete functionality and may block peer-to-peer applications, or make them less reliable.

Services that use records with priorities, such as SRV or MX records, should probably takes this order into account, yet specify all these addresses to reach the best connectivity that can be achieved.

Though it is possible to improve the peering behaviour of IPv4 with STUN or TURN, this still leaves the disadvantages of a more problematic internal stack. Choose wisely, and plan for the future; with a single IPv6 stack you should not have the overhead that dual-stack solutions brought you. If you still have IPv4-only devices however, you may need to patch around them; you know, things like 6bed4proxy for SIP/RTP crossover; these tools are mildly obtuse, but actually drive the message that your network can still be improved. Peering is getting more and more important in a centrally-tapped World, which trumps such local networking inconveniences. Furthermore, these transitions can be yet another way to centralise IPv4 users into a tapping point. We should choose wisely, and roll out IPv6 everywhere.

Conclusion

It is certainly possible to design network internals as simple IPv6-only applications, and it enhances the freedom and possibilities of such applications.

The translation of IPv4 traffic to IPv6 is then taken care of by generic components, and IPv4 users get the user experience that they get elsewhere too, just with a bit more processing to make it possible.

The limitations of IPv4 with NAT do show, especially for peer-to-peer applications. This is always the case in such setups, and it is important enough to communicate that the fault lies with NAT, and so with IPv4.

Anyone interested in full-blown IPv6 access but unable to do this on their own end can lift up their service level explicitly by adding 6bed4peer software.

The approach sketched here should make it painless to be up to date, and guide evermore IPv6 into your network, and to be supportive of peer-to-peer protocols and their ongoing development, while retaining IPv4 functionality for classic client-server use cases.