Light at the end of the tunnel: Transitioning to IPv6 with ISATAP

A few years ago, doomsday predictors sent a warning to the entire world that IPv4 addresses would be gone and everyone had to upgrade to IPv6 to ensure continued Internet connectivity. They even argued that this would lead to skyrocketing demand for IP addresses and the Internet would crash!

But here we are and the Internet is going much stronger than before, thanks to the Internet of Things, BYOD, smartphones, wearables, and the ever-growing user base.

So, did the crisis really happen or did we just get lucky?

Well, there is no luck here because this problem took no one by surprise except these predictors who thrive on creating panic among tech novices.

Twenty years back, the Internet Engineering Task Force (IETF) foresaw this global growth of Internet IP addresses and this is why they drafted a new version of the Internet protocol to address this challenge.

And that protocol is IPv6. The earlier protocol, IPv4, had only a 32-bit scheme that greatly limited the number of IP addresses. But IPv6 is a 128-bit schema, which means you’ll have more IP addresses than there are grains of sand on Earth!

That said, has everyone switched over to IPv6? No, because IPv6 requires an end-to-end implementation that is costly. It requires heavy upfront investment that not many operators are willing to spend. This means most organizations will be using a dual stack of IPv4 and IPv6 for some more years to come.

Moving from IPv4 to IPv6

Migration from IPv4 to IPv6 doesn’t always mean replacing your 32-bit schema with the 128-bit schema. Rather it means that you can enable IPv6 in addition to IPv4, so the network benefits from the advantages of the new protocol without having to discard the old one.

This is easier said than done because IPv4 and IPv6 are not compatible with each other, so they can’t communicate directly. Also, IPv6 has to be enabled by network hardware vendors, access providers, content providers, and hardware manufacturers. This requires substantial investment and not many are willing to come forward and invest proactively.

These are some reasons why IPv6 adoption is slower than expected, and the transition between the two protocols is challenging.

Currently, the nodes on your network will be one of the following:

  • IPv4 only node.
  • IPv6 only node.
  • IPv6/IPv4 node.

In the first two types, there is only one node, either IPv4 or IPv6, whereas in the last one, there are both IPv4 and IPv6 stacks.

Given these nodes, there are three transition mechanisms possible.

  • Dual stack that runs both IPv4 and IPv6 simultaneously.
  • Tunneling that happens with IPv4 over IPv6 and IPv6 over IPv4.
  • Translation that happens from IPv4 to IPv6 and IPv6 to IPv4.

You can choose any of these three methods for transition.

Out of these, dual stack is probably the easiest as your devices run on two different stacks (IPv4 and IPv6) simultaneously. This way, your device can communicate with either of the two protocols.

Though it sounds simple, there are many security loopholes that come with it. This is why a better option is to use enable interoperability.

Interoperability

A better way to transition between the two protocols is to create a mechanism for interoperability. In other words, you need a mechanism to code the 32-bit address of IPv4 into the 128-bit address of IPv6. This will ensure tunneling and translation between the two protocols. This mechanism is generically called tunnels.

Broadly speaking, every tunnel has two endpoints, namely the ingress and egress endpoints. The ingress endpoint encapsulates a packet with IPv4 header, and the network handles it like a normal IPv4 packet. When it reaches the egress point, the IPv4 header is stripped and it is processed as an IPv6 packet.

[tg_youtube video_id=”AfFG5jA2S_w”]

Now, one thing with tunnels is that each endpoint should be known before sending a packet. So, you preconfigure the endpoint with the IPv4 address of other endpoints in the same tunnel. Doing this job manually is a nothing short of a nightmare. It also presents scalability problems.

To overcome these problems, automatic tunnels were developed in which an endpoint’s IPv4 address is calculated from the IPv6 destination address. This means you don’t have to keep an explicit configuration at the tunnel’s endpoints.

One such automatic tunnel is ISATAP.

What is ISATAP?

Intra-site automatic tunnel addressing protocol, or ISATAP for short, is an interface that hosts can use to pass IPv6 traffic over IPv4 networks. Defined in RFC 5214, this interface takes an IPv6 frame and applies the headers of this frame to the IPv4 address.

For example, let’s say the IPv4 address is 192.0.0.1 and this has to be converted to IPv6 address. You have to use the ISATAP interface to convert this IPv4 address into an IPv6 one.

Let’s say, you use 2002:9efe:1:2:1:5efe: as the ISATAP interface, then the entire address would look like 2002:9efe:1:2:1:5efe:192.0.0.1. And this is a typical IPv6 address.

Such an address gives you some important information.

  • Firstly, it is clear that this is a valid IPv6 address that can be used for any IPv6 communication.
  • The presence of an IPv4 address indicates that IPv4 information will be used to shuttle the IPv6 packets over an IPv4 network.

Effectively, you have solved your problem here. You have used IPv4 network to communicate an IPv6 packet!

Practical scenario

Let’s look at a practical scenario where ISATAP can be used.

Say, you have an IPv4 network with many hosts and applications running on it. This is typical of most organizations.

If you want to do an overhaul to IPv6, it is expensive and time-consuming. Though you can do it as a long-term project, you also need a stopgap solution to ensure that services are not affected by your migration.

Now, let’s say, you add new hosts and devices. You’ll obviously want them to be IPv6 to gear for the future. At the same time, these new devices should communicate with the legacy portions of the network that are running on IPv4.

This is where ISATAP comes in. When you use an ISATAP router and enable ISATAP on the hosts in an IPv4 network, native IPv6 can be deployed. Over time, you can slowly decommission the devices running on IPv4 and upgrade to IPv6 devices.

Simple, right?

This simplicity and ease of use are some reasons for the popularity of ISATAP. It is implemented in many operating systems such as Cisco IOS, Linux, Windows Mobile, Windows Server 2012, Windows XP, Windows 7, Windows 8, Windows Vista, and Windows 10.

IPv6 is the future of Internet protocol. However, it is expensive and time-consuming to convert all IPv4 networks into IPv6, so a better option is to use an interface like ISATAP that will enable IPv6 communication over an existing IPv4 network. This way, your organization has the option to migrate to an IPv6 network over a period of time.

About The Author

3 thoughts on “Light at the end of the tunnel: Transitioning to IPv6 with ISATAP”

  1. IPv4 Address Pool Has Been Expanded Significantly

    Maybe we should turn around to see the light at the other end of the tunnel? This may sound crazy. But, please be patient with the below information.

    The main reason that IPv6 has not been rolling out smoothly is because it ignored the first rule of engineering in upgrading a working product / system, i.e., the backward compatibility to IPv4. Had it done so, the transition would have been completed a long time ago without even being notices. Marketing type of persuasion has its limits, especially after nearly ten years if we do not count that IPv6 work actually started two decades ago. At the current pace of electronic products, it has been nearly half dozen of so life-cycles already!

    Our background in telephony enabled us to approach this Internet challenge from the knowledge of the PSTN (Public Switched Telephone Network) that developed practices to expand the assignable telephone numbers through the PABX (Private Automatic Branch eXchange) and the lesser known CENTREX (CENTRal office EXchange) technologies.

    Instead of digging into the telephony details, we have submitted to IETF a proposal called EzIP (phonetic for Easy IPv4) about the solution from the networking perspectives:

    https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

    Essentially, EzIP utilizes the very original IPv4 standard RFC791 and the long-reserved yet hardly-used 240/4 address block to expand each IPv4 public address by 255M (Million) fold. This is capable of serving an area with population up to about 39M which is larger than the largest city (Tokyo metro) and 75% of countries on earth. This capability not only enables governments, but also individuals to offer local sub-Internet services parallel to the current global version. There are other benefits such as mitigating largely the root cause to cyber security issues. These render IPv6 unnecessary.

    Thoughts and comments would be much appreciated.

    Abe (2018-08-28 20:29)

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top