Home
- Introduction
- Background
- Jool (Stateful NAT64)
- Configurability
- Performance and Reliability
- Functionality
- Requirements
- Considerations
- References
- FAQs
The IETF has been working on the deployment of IPv6 to replace the current IPv4 protocol due to lack of IPv4 addresses and high demand for new devices, however until IPv6 completely supplants IPv4, a number of transition mechanisms are needed to enable IPv6-only hosts to reach IPv4 services and to allow isolated IPv6 hosts and networks to reach each other over IPv4-only infrastructure. ITESM and NIC professionals have worked together on the design of a Stateful NAT64 transition mechanism (JOOL v1.0) in order to allow the IPv6-IPv4 communication. This document is intended to provide a general overview of Jool’s core features and specifications.
Each node in a network, such as computers or printers, has assigned a unique IPv4 address that is used to communicate with other nodes on the same network. Normally this address is expressed in dotted decimal format (e.g. 192.168.0.1). Each part of the address or byte must contain a number in the range 0 to 255, so that the limit of possible directions is 4,294,967,296. While the primary reason for IPv4 address exhaustion is insufficient design capacity of the original Internet infrastructure, several additional driving factors have aggravated the shortcomings. Each of them increased the demand on the limited supply of addresses, often in ways unanticipated by the original designers of the network: Mobile devices, Always-on devices, Internet growth, Inefficient address use, etc. Due to these problems temporary solutions arrived: NAT (Network, Address Translator) [2], however work began on a new Internet Protocol, namely IPv6.
Internet Protocol version 6 (IPv6) is the latest revision of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion. IPv6 is intended to replace IPv4, which still carries the vast majority of Internet traffic as of 2013. [1] IPv6 uses a 128-bit address, allowing 2 ex 128, or approximately 3.4×10 ex 38 addresses, or more than 7.9×10 ex 28 times as many as IPv4, which uses 32-bit addresses. IPv4 allows only approximately 4.3 billion addresses. The two protocols are not designed to be interoperable, complicating the transition to IPv6. IPv6 addresses are represented as eight groups of four hexadecimal digits separated by colons, for example 2001:0db8:85a3:0042:1000:8a2e:0370:7334.
Transition mechanisms are needed in order to communicate IPv6 to IPv4 networks. Many of those mechanisms use tunneling to encapsulate IPv6 traffic within IPv4 networks. This is an imperfect solution, which may increase latency and cause problems with Path MTU Discovery.[3] As IPv4 and IPv6 networks are not directly interoperable, these technologies are designed to permit hosts on either network to participate in networking with the opposing network. Transition mechanisms can be generalized into two types: header translation and encapsulation by tunnels. The IETF chose the header translation technique to communicate IPv4 with IPv6 networks. The IETF organism studied four different technologies to become the standard technology to use in this case. The technologies are:
- DS-Lite.
- IVI
- NAT64
- NAT6
NAT means Network Address Translator, the 64 means the direction from IPv6 to IPv4. It is a transition mechanism which allows connectivity between clients IPv6 and servers IPv4. Usually, the communication is initiated from IPv6 client towards IPv4 server, however, if IPv4 client wants to communicate with IPv6 server, manual configuration is required, making this mechanism less attractive to provide IPv6 services towards IPv4 Internet. Very simplistic NAT64 setup can be thought as a network device (a router) with at least two interfaces. One of these interfaces is connected to an IPv4 network, and another is connected to an IPv6 network. The network is configured in a way that packets from the IPv6 network to the IPv4 network get routed through this router. The router itself performs all the necessary translations needed to transfer packets from the IPv6 network into the IPv4 network, and vice versa. The translation isn't symmetric, as IPv6 address space is a lot larger than IPv4 address space (compare: 2128 for IPv6 and 232 for IPv4), so no one-to-one address mapping is possible. Therefore, in order to be able to perform the translation, NAT64 is required to keep the IPv6 to IPv4 address mapping. Such an address mapping is either statically configured by the system administrator (stateless translation), or (more frequently) is created automatically when the first packet from IPv6 network reaches NAT64 to be translated (stateful). After this address binding is created, packets can flow in both directions. Some Nat64 implementations are:
- Ecdysis, a NAT64 gateway, includes DNS64
- TAYGA, a stateless NAT64 implementation for Linux
- OpenBSD brings a packet filter capable of NAT64
- Jool, a RFC6146 implementation for Linux (stateful NAT64)
In (CISCO, 2011), it is found that the big difference with Stateful NAT64 is the elimination of the algorithmic binding between the IPv6 address and the IPv4 address. In exchange, is related to the creation of states, where each state represents connections between n-Clients IPv6 and 1-Server IPv4. There are two tables on a stateful configuration: BIB (Binding Information Base) and Session Tables. Each table has the information of the Source and the Destination, same as an IPv4-only network. Stateless NAT64 is very effective and highly fail safe because more as a single-or multiple translators in parallel can be deployed and work all in parallel without a need to synchronize between the translation devices. The key to the stateless translation is in the fact that the IPv4 address is directly embedded in the IPv6 address. A limitation of stateless NAT64 is that only translates the IPv4 options that has a direct counterpart on the IPv6 protocol and does not translate any IPv6 extension header; however, this limitation is not significant in practice [4]. Different from stateful, the addresses between IPv4 and IPv6 can be algorithmically mapped so that there is no need to keep state for any translation slot between IPv4 and IPv6, and then a one-to-one relationship is built. This mapping algorithm requires the IPv6 hosts be assigned specific IPv6 addresses, using manual configuration or DHCPv6. Summarizing what has been above describe, next there is a table with the description of the features.
Jool is an open source project initially developed by professionals from ITESM and NIC Mexico. It uses the header translation strategy, where only it can initialize the connection from an IPv6 client to an IPv4 server. Jool is developed in Linux kernel space and complies with most of the RFC 6146 standard. The following sections will describe the main features.
Jool is a mechanism that keeps a relation one-to-many, it means that several IPv6 clients have to share the same IPv4 address. NAT64 does not need a special subnet dedicated to represent the IPv4 address space. All the IPv4 addresses are embedded with the special prefix 64::ff9b::/96 so translation can be performed. In order to keep the information about connections, Jool uses two tables for each protocol, the Binding Information Base (BIB) and session table. The session table contains the following information:
- Source IPv6 address (Client IPv6 address) and source port number (ID in the case of ICMP).
- Destination IPv6 address and destination source port (ID in the case of ICMP) containing the prefix and the destination IPv4 address.
- Source IPv4 address and source port number (ID in the case of ICMP). This address is given by the IPv4 address pool.
- Destination IPv4 address and destination port number (ID in the case of ICMP).
- Connection lifetime
The BIB table contains the following transmission address:
- Source IPv6 address (Client IPv6 address) and source port number (ID in the case of ICMP).
- Source IPv4 address and source port number (ID in the case of ICMP). This address is given by the IPv4 address pool.
Jool is founded in this standard. It describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients.
Jool implements de following components (Defined in the RFC6146 standard):
- The translation is done by translating the packet headers according to the IP/ICMP Translation Algorithm defined in [RFC6145].
- The IPv4 addresses of IPv4 hosts are algorithmically translated to and from IPv6 addresses by using the algorithm defined in [RFC6052] and an IPv6 prefix assigned to the stateful NAT64 for this specific purpose
- The IPv6 addresses of IPv6 hosts are translated to and from IPv4 addresses by installing mappings in the normal Network Address Port Translation (NAPT) manner [RFC3022].
- NAT64 is compliant with the recommendations for how NATs should handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508].
- NAT64 MUST offer Endpoint-Independent Mapping, Endpoint-Independent Filtering and Address-Dependent Filtering [RFC4787]. Jool also complies with the following statements:
- Jool is a device with at least one IPv6 interface and at least one IPv4 interface.
- Jool has two pools of addresses: an IPv6 address pool (to represent IPv4 addresses in the IPv6 network) and an IPv4 address pool (to represent IPv6 addresses in the IPv4 network). NAT64 only processes packets that interact with these pools.
- Packets from IPv4 are processed only if a state exists (dynamic or static).
- Connections can be initiated easily from IPv6 side.
- Jool must discard packets in error situations. Jool must send ICMP messages in order to report the error.
- Security from the Jool data base.
Jool is developed considering multiple properties that can be configured manually, some of them are:
- Static binding configuration
- Session timeout
When comparing two transition mechanisms, it has been observed that the performance of both of them is similar in general. On ICMP Protocol, Jool v1.0 performs better than OpenBSD but, in UDP protocol, OpenBSD is clearly better, while in TCP protocol the performance difference is tight. However, we must consider that Jool is inserted into the Operating System. The performance of Jool v1.0 can be improved if, instead of using standard libraries, specific functions are coded in order to solve some needed functionalities. The testing was done in normal performance computers; none of them were prepared in any special way. All the services were running as usual and the Operating System for the Client and Server computers is Linux with Ubuntu 12.04 LTS while the Operating System for the NAT64 is Linux with Ubuntu 12.04 LTS when testing with Jool v1.0 and Unix with OpenBSD 5.2 when testing with OpenBSD. It is important to mention that the MTU (Maximum Transmission Unit) negotiated between the computers is 1,500 bytes. The ping testing was bounded by this specification.
Three computers were needed for the measurement stage: Client IPv6, Server IPv4 and Jool (NAT64); while two network configurations were set up: Client IPv4 – Server IPv4 and Client IPv6 – Jool – Server IPv4. Below both network configurations are shown.
The first network (Client IPv4 – Server IPv4) was set in order to achieve baseline data about the latency and throughput values as well as % memory and % CPU usage when Jool is not on the network. The second network (Client IPv6 – Jool – Server IPv4) was set to get latency and throughput values as well as % memory and % CPU usage when Jool is added on the network. At the end, the performance of the network with Jool is compared with the performance of the network without Jool knowing the overload due to the Jool element.
- ICMP: Ping
- UDP: DNSperf
- TCP: Apache Bench
When the number of multi-users goes from 70 to 100, Jool shows an erratic performance (Figure 3), while OpenBSD having a similar performance seems to react in a smoother way. Considering this erratic performance, Jool has an increment in time of 11,852.17% in comparison with the baseline. Also an increment in time of 25.2% is observed when the number of queries changes (figure 4) and when the packet size changes the increment in time is of 25.5%, respect to the baseline.
When testing UDP protocol, it was observed that both transition mechanisms had problems getting reliable information. When changing the client numbers, OpenBSD shows an increment of 21%, respect to the baseline and Jool v1.0 shows an increment of 104.5% (Figure 6). Also an increment of 156.6% is observed when the number of queries changes. (Figure 7)
When the number of multi-users goes from 70 to 100, Jool shows an increment of 8.02% in the time required to process a petition (Figure 8). Also an increment in time of 21.85% is observed when the number of queries changes (figure 10) and when the packet size changes, it describes a linear relationship with an increase of only 3.8% compared to baseline (Figure 12).
Operative Systems: Ubuntu, Debian, OpenSuse, Centos Kernel version:
- 2.6.38-16 or greater
Also tested in:
- 2.6.38-16 generic
- 3.0.0-32 server
- 3.2.0-45 generic
- 3.8.0-19 generic
The actual software, Jool v1.0, does not have filtering implemented. It is necessary to run again the testing set comparing the performance of Jool v1.0 and Jool v2.0 when standard libraries are replaced for specific functions and filtering is implemented
We're missing the following:
- Fragmentation (Jool mostly drops fragments).
- [Filtering rules] (https://github.com/NICMx/NAT64/issues/41).
- [Simultaneous open of TCP connections] (https://github.com/NICMx/NAT64/issues/58).
- David Frost (20 April 2011). "Ipv6 traffic volumes going backwards". iTWire. Retrieved 19 February 2012.
- Srisuresh, P., & Holdrege, M. (1999, August). IP Network Address Translator (NAT) Terminology and Considerations. Internet Engineering Task Force, Request for Comments 2663.
- "RFC 6343–Advisory Guidelines for 6to4 Deployment". Tools.ietf.org. Retrieved 20 August 2012.
- CISCO. (2011, July). NAT64—Stateless versus Stateful. Retrieved from CISCO: http://www.cisco.com/en/US/hmpgs/index.html
How to get Jool running?
If you already know Jool, here is how to get the software running.
What is NAT64?
NAT64 is a translation mechanism, meant to allow IPv6 and IPv4 networks to coexist and interact with each other. The concept is similar to NAT in that a node hides a network behind a single or few addresses; it is different in that the network being hidden is IPv6.
For further reading please refer to http://en.wikipedia.org/wiki/NAT64 or the RFC itself
Why NAT64?
Because it adds no overhead to the packets, thus improving the performance of the communication, making the router's work easier and faster. Even though you will need a device to act as the NAT64 and the DNS64 (though the latter could be installed in the same device), this transition mechanism doesn't require drivers to be installed on the clients thus making the deployment easier, and the only overhead in the communication is that the packets have to be translated in the device.
Why stateful?
Stateless NAT64 demands that you have an IPv4 address for every IPv6 node you want translated. Though this has some benefits, such as being faster, it sort of defeats the purpose of IPv6. With stateful NAT64 a single IPv4 addresses can be used by several IPv6 nodes.