Ready to go IPv6? Think again!

The last years there has been a lot of discussion around IPv6 and the migration to it from IPv4. Since 1994, when IETF gave a clear direction for IPv6, we have been pushed to upgrade to the next generation Internet Protocol. Why is IPv6 promoted so much? The main reason is that IPv6, by changing the address length from 32-bits to 128-bits, is bringing the solution to the inevitable address space exhaustion that we are going to face in the next few years. But except from offering some quadrillion IP addresses, IPv6 is also considered to have some advantages over IPv4, such as better security with IPSec, more efficient routing due to fixed header size , auto-configuration using the Neighbor Discovery Protocol instead of DHCP when a system connects to a network, support for mobility by assigning several addresses to one network interface and support for multicast by allowing multicast addresses.

Although IPv6 gained a lot of publicity, the Internet users do not seem to be convinced that they have to migrate. The reason for this is the existence several disadvantages that come along with IPv6. First of all, there is no migration plan, nor an easy transition mechanism to follow or adequate support for someone that chooses to make the transit. IPv6 is incompatible with IPv4 because of the change in the IP address length, which could have been avoided if  IPv6 supported variable address length. Practically this means that during the transition process, which will likely last some years, an IPv6 site won’t be able to reach all the remaining IPv4 sites without using extra configurations, such us dual IP stacks, NATs and tunneling. Moreover, IPv6 solves the address space exhaustion problem temporarily (for sure we will face the same problem some years later), but what will happen with the routing size tables that will have to perform calculations with 128-bit addresses? Seems like we will require more CPU cycles and memory. Lastly, IPv6 removes the private address space and replaces it with the so called Unique Local Addresses, which unfortunately have global scope.

Having a look to the numerous restrains and hassles that follow IPv6 adoption, asking whether we could have done something better  is a viable question. The real question should be what got us to this point. The address space exhaustion and the difficulty in supporting mobility of applications, multi-homing and multicast are all indications that something went wrong with the Internet’s initial design.

Very early, in 1982, Jerry Saltzer in his work “On the Naming and Binding of network destinations” (RFC 1498) described the entities and the relationships that make a complete naming and addressing schema in networks.

Saltzer's view for naming and addressing in networks

According to Saltzer four are the elements that need to be identified: applications, nodes, points of attachment to the network (PoAs) and paths. A service can run to one or more nodes  and should be able to move from one node to another without losing its identity in the network. A node can be connected to a pair of PoAs and should be able to move between them without losing its identity in the network. As illustrated in the figure above, directory maps an application name to a node address, routes are sequences of nodes addresses and paths result from mapping the node addresses to PoAs. In this way, routing is a two-step process: First, calculate the route, which is a sequence of node addresses and then, for each hop choose the appropriate PoA to select the specific path to be traversed. Moreover, Saltzer underlines the importance of choosing the right properties for the names of the elements of a network. Application names should be location-independent, allowing this way the application to move inside the network. Node names should be location-dependent, reducing the complexity of the routing process.

What do we have in the current Internet’s naming and addressing schema? IP addresses, which are PoAs names and of course are location-dependent. There are no names defined for applications or nodes.  Application names are URLs containing a PoA name, which excludes the possibility of supporting mobility. Node names are PoAs names, which is the reason why multi-homing is not supported. Naming interfaces origins from ARPANETʼs design, where nodes were named after the IMPʼs number followed by the port number (interface) that connected the node to the network. In addition, current Internet does not have any form of directory that maps applications to nodes. This is why application names have to carry the PoA name of the node they belong to and therefore the reason why IP addresses have to be exposed. This choice makes mobility difficult, as part of the application name is also the PoA name and compromises security by exposing the IP addresses to everyone.

Except from Saltzer’s findings, there are three more properties for naming network elements that could provide us with a better naming and addressing schema. The first two properties facilitate locating applications and nodes in a network. Choosing hierarchical names for applications and nodes would result in a more efficient way of searching a directory. Making node names topological would allow more efficient routing. The third property would give us the answer to the address space exhaustion.  By defining carefully the scope of a name-space, it would become apparent that not all the names have to be globally unambiguous.

Having a better understanding of what are the elements and the properties that make up a complete naming and addressing schema, it seems that IPv6 is not likely to offer solutions in Internet’s important problems such as multi-homing, mobility, multicast, efficient routing, as it doesn’t get to the root of the problem. In fact, with some of the  choices, along with the current transition strategy, it might cause even more problems than the ones we already have. For a network architecture proposal that adopts the previously discussed properties and provides answers to all the urgent networking issues inherently,  you can have a look at RINA (Recursive Internetwork Architecture).

This entry was posted in Research, Uncategorized and tagged , , , . Bookmark the permalink.