IPv4 to IPv6 Conversion Method

IPv4 to IPv6 Conversion Method

Any IPv4 to IPv6 conversion method is not going to be easy as the changes are being made in the network layer. It is like changing the foundation of the house. However, two methods have been suggested. We will cover those methods shortly.

One option would be to declare a flag day – a given time and date when all internet machines would be turned off and upgraded from IPv4 to IPv6. The last major technology transition (from using NCP to using TCP for reliable transport service) occurred almost 25 years ago. Even back then [RFC 801], when the internet was tiny and still being administered by a small number of “wizards”, it was realized that such a flag day was not possible. A flag day involving hundreds of millions of machines and millions of network administrators and users is even more unthinkable today. RFC 4213 describes two approaches (which can be used either alone or together) for gradually integrating IPv6 hosts and routers into an IPv4 world (with the long-term goa, of course, of having all IPv4 nodes eventually transition to IPv6).

Dual Stack Approach

Probably the most straightforward way to introduce IPv6-capable nodes is a dual stack approach, where IPv6 nodes also have a complete IPv4 implementation.

Such a node, referred to as an IPv6/IPv4 node in RFC 421, has the ability to send and receive both IPv4 and IPv6 datagrams. When interoperating with an IPv4 node, and IPv6/IPv4 node can use IPv4 datagrams; when interoperating with IPv6 node, it can speak IPv6.

IPv6/IPv4 nodes must have both IPv6 and IPv4 addressed. They must therefore be able to determine whether another node is IPv6-capable or IPv4 only. This problem can be solved using the DNS, which can return an IPv6 address if the node name being resolved is IPv6 capable, or otherwise return an IPv4 address. Of course, if the node issuing the DNS request is only IPv4-capable, the DNS returns only an IPv4 address.

In the dual stack approach. If either the sender or the receiver is only IPv4-capable, an IPv4 datagram must be used. As a result, it is possible that two IPv6-capable nodes can end up, in essence, sending IPv4 datagrams to each other. This is illustrated in the figure below.

Suppose Node A is IPv6-capable and wants to send an IP datagram to Node F, which is also IPv6-capable. Nodes A and B can exchange an IPv6 datagram.

However, Node B must create an IPv4 datagram to send to C. Certainly, the data field of the IPv6 datagram can be copied into the data field of the IPv4 datagram and appropriate address mapping be done.

However, in performing the conversion from IPv6 to IPv4, there will be IPv6-specific fields in the IPv6 datagram (for example, the flow identifier field) that have no counterpart in IPv4. The information field will be lost. Thus, even though E and F can exchange IPv6 datagrams, the arriving IPv4 datagram at E and D do not contain all of the fields that were in the original IPv6 datagram sent from A.

Tunneling

An alternative to the dual stack approach, also discussed in RFC 4213, is known as tunneling . Tunneling can solve the problem noted above, allowing, for example, E to receive the IPv6 datagram originated by A.

The basic idea behind tunneling is the following. Suppose two IPv6 nodes (for example, B and E in the figure above) wan to interoperate using IPv6 datagrams but are connected to each other by intervening IPv4 routers. We refer to the intervening set of IPv4 routers between two IPv6 routers as a tunnel, as shown in the figure below (4.26).

With tunneling, the IPv6 node on the sending side of the tunnel (for example, B) takes the entire IPv6 datagram and puts it in the data (payload) field of an IPv4 datagram.  This IPv4 datagram is then addressed to the IPv6 node on the receiving side of the tunnel (for example, E) and sent to the first node in the tunnel (for example C).

The intervening routers in the tunnel route this IPv4 datagram among themselves, just as they would any other datagram, blissfully unaware that the IPv4 datagram itself contains a complete IPv6 datagram.

The IPv6 node on the receiving side of the tunnel eventually receives the IPv4 datagram (it is the destination of the IPv4 datagram), determines that the IPv4 datagram contains an IPv6 datagram, extracts the IPv6 datagram, and then routes the IPv6 datagram exactly as it would if it had received the IPv6 datagram from a directly connected IPv6 neighbour.