Freedom to Travel

Imagine that you are working in your home office with your tablet, which is connected to your home’s wireless network. You leave the house for the airport, and while you’re traveling in a taxi, the tablet uses LTE to connect with your provider, so you can check your home portal to see whether the heating was turned off. At the airport, the mobile device automatically connects to the public WiFi hotspot, on which you can check the time of departure and check in to your flight. While all this happened, you were connected all the time to your corporate network via a secure tunnel.

This scenario might sound like science fiction, but it is closer than you think. Mobile IPv6 (MIPv6) makes it possible to maintain accessibility on any network with the same address and to switch networks without interrupting connections. The prerequisite for such a setup is an IPv6 infrastructure.

The Roaming Issue

When a connection is established between two nodes, it is usually based on the IP addresses of the communication partners. If one partner changes networks, it inevitably receives a new IP address. As a consequence, the connection is dropped and must be reestablished. In the future, however, the connection between two communication partners will be maintained as a matter of course, despite a changing network connection. This principle is called roaming (Figure 1).

Figure 1: Roaming maintains connections even when the user moves from one network to another.

Depending on the transmission technology, changing the network link without losing the connection is already possible. This capability, however, relies on the network technologies themselves. It can be done, for example, on wireless networks, where the wireless client can move seamlessly between different access points (APs). If the received power of one AP is too low, the client automatically connects to the nearest AP without losing the connection. This is also possible on mobile networks, where appropriate authentication and account measures ensure cross-network billing.

An IP-based solution, however, allows for complete independence of the connection technology and is only fully supported by MIPv6. Mobile IPv4 is also defined, but that specification entails some disadvantages compared with IPv6. For example, MIPv6 uses flexible extension headers to avoid issues with routing, thereby making roaming easier and more flexible. Additionally, MIPv6 basically abstracts itself from the data link layer through the use of Neighbor Discovery – a network layer technology.

Mobile Nodes

A mobile node is referred to in Mobile IPv6 terminology as, you guessed it, a mobile node (MN). The communication partner is the correspondent node (CN) and can be stationary (i.e., a server) or mobile. The MN has a home network, which is referred to as the home link. Attached to this is a router, which binds the fixed address of the MN as the home agent (HA). This fixed address is known as the home address and is a global unicast address. The home agent means that the MN is accessible everywhere via its home address (Figure 2).

Figure 2: Mobile IPv6 terminology.

The MN may reside on its home link or in a different network. Any other network is referred to as a foreign link. On a foreign link, the MN has a different address from its home address; this is assigned by autoconfiguration or DHCPv6. The current address on the foreign link is known as the care-of address. The MN sends its current care-of address to the HA. This message is known as the binding update; it creates a binding on the HA between the home address and the care-of address.

How Mobile IPv6 Works

As long as the MN is using a normal prefix on its home link, it can be reached by standard routing mechanisms, because the home agent with the home address is locally based. On the road, or traveling outside its home link, the MN receives an additional address (care-of address) on any foreign link; it then sends a binding update message to its home agent. The home agent sends a binding acknowledgment (ack) and – thanks to the binding process – knows the care-of address under which the MN is currently accessible. The correspondent node always uses the MN’s home address to communicate with the MN; this always leads to the home agent.

The MN can communicate in two ways with the correspondent node. In bidirectional tunneling, packets from the CN are sent to the home agent, which forwards them through a tunnel to the MN. The MN sends the responses through a reverse tunnel to the home agent, which forwards the data to the CN. No support for Mobile IPv6 is necessary on the correspondent node.

When route optimization is enabled, any communication after the initial connection through the home agent is handled directly between the MN and the CN, without going through the HA. A type 2 routing header is used for this process. Route optimization enables more efficient communication because routing can be optimized, instead of detouring via the HA. However, this approach requires Mobile IPv6 support on the CN. Route optimization is one of the main advantages of Mobile IPv6 over Mobile IPv4 because the latter does not allow extension headers (and thus does not have routing headers).

The Protocol

IPv6 is particularly flexible thanks to extension headers. A separate extension header, the Mobility Header (MH) was developed for MIPv6. It is used by all the parties (i.e., the mobile node, correspondent node, and home agent) in messages that have to do with the management and updating of bindings. Figure 3 shows the configuration of the mobility header.

Figure 3: The mobility header.

The mobility header is indicated by the Next Header value of 135 in the previous header. Its own Next Header field (which goes by the name of the “Payload Proto”) currently has a value of 59, to indicate that no more data follows. This field is reserved for future developments, if more information is appended some time later.

The header length field contains the length of the mobility header in 8-byte units – the first 8 bytes are not counted. Thus, the MH must always be a multiple of 8 bytes. The MH type field contains the type of mobility message. Currently, 16 mobility message types are defined, including binding update and binding ack. A checksum field computes a checksum based on a pseudo-header and follows the rules established in RFC 2460 (IPv6).

Mobility messages can include options that are specified in TLV (Type-Length-Value) format. In particular, the home address option is relevant because the mobile node uses it here to send the correspondent node a message containing the mobile node’s home address. Thus, the correspondent node can reach the mobile node at any time. However, this is also a special case, because this option is sent in a destination header rather than in the mobility header. A destination header is an extension header that is only evaluated by the target.

A new routing header was also defined for MIPv6, which allows the mobile node and correspondent node to exchange data directly without going through the home agent. This extension header bears the name of type 2 and designates special rules that can be configured on firewalls for MIPv6 packets. Because MIPv6 communication basically first uses the home agent and the home address, the home address is inserted in the type 2 routing header, whereas the destination address in the IPv6 header is the care-of address for the mobile node. The receiving mobile node removes the routing header and replaces the care-of address with the home address to trick the upper layer protocols in the OSI layers into believing that communication has come through the home address.

Check Your Bindings

Bindings and binding management are key parts of MIPv6. Normally, binding takes place between the mobile node and the home agent. However, it is also possible to set up bindings between the mobile node and the correspondent node to enable routing-optimized communication. When a mobile node leaves its home link and receives a care-of address from a foreign link, it sends a binding update message to its home agent. The message contains the IPv6 header and a destination option header, in which the home address option is set (Figure 4). The message is used to tell the home agent which home address to use, because it could theoretically use several.

Figure 4: The binding update header.

The message is transmitted using IPsec in an encapsulating security payload (ESP) header and also contains another mobility header with a type 5 message (binding update) and a home registration flag set that asks the recipient to assume the home agent role. Additionally, the acknowledge flag is set to request the home agent to respond. The mobility header also states a lifetime in four-second units, to determine the validity of the binding. Binding update messages are sent to refresh the existing bindings or to provide information on a new care-of address (Figure 5).

Figure 5: The binding update process.

The response from the home agent, in the form of a binding ack, contains a type 2 routing header with the home address of the mobile node instead of the destination header. The binding ack is a type 6 message confirming the details of the mobile node and containing some other administrative information, such as whether IPsec supports a network change, which should be the exception.

The status field of the binding ack indicates the state of the binding: 1 to 127 stand for a successful update, whereas status values of 128 and above indicate some defined problems. Binding acks are sent only to confirm binding updates. The home agent can send a binding refresh request message to request an update of the information in the form of a binding update from the mobile node.

A binding update can also be sent directly to the correspondent node, if it supports MIPv6. However, special security precautions are needed here to prevent redirection attacks. This safeguarding process is called the return routability procedure and lets the correspondent node test whether the mobile node really is reachable via both its care-of and its home address. Only then are binding updates accepted by the CN. Because the bindings are cryptographically secured by IPsec, authorization information is exchanged in the form of cryptographic tokens in this context. The binding management key ultimately secures the information.

New ICMPv6 Functions

Mobile IPv6 includes some enhancements to ICMPv6 to provide for additional features. Home agent address discovery gives the mobile node the ability to determine its home agent’s address. For this, a home agent address discovery request is sent to the home agent anycast address on the home link. This is a special anycast address to which all home agents respond. A home agent responds to the request with a home agent address discovery reply. The replay contains a list of home agent addresses, sorted by their preferences.

In the case of temporary IPv6 addresses, changes to the prefix of a mobile node’s home network can occur. The mobile node can determine this change by means of a mobile prefix solicitation message. This message is sent to the home agent, which responds with a mobile prefix advertisement. These advertisements can also be sent to the current care-of address of the MN without a prior request, if needed.

Each mobile node must be able to create a list of home agents on its home link. To do this, the node not only needs the link-local addresses of its home agent routers in the router advertisements, but also the global unicast addresses. The router advertisement was modified to support this setup. It contains an R flag (router address); the prefix option does not contain a prefix but instead contains a complete global unicast address of the router.

Further changes in neighbor discovery relate to indicating the preferred home agent addresses and a reduced minimum interval for router advertisements so that mobile nodes on foreign links can be informed as soon as possible about their new care-of addresses. This interval has been reduced from the original three seconds to 0.03 seconds. This value can be meaningful on wireless routers that are configured solely to support mobile devices.

Where Am I?

The mobile node must detect as quickly as possible that it is no longer on its own network in order to initiate a new link. A process called neighbor unreachability detection supports this operation, known as movement detection. This process also exists in the normal IPv6 standard in the scope of neighbor discovery. It involves having the mobile node check the accessibility of its default gateway. If the default is no longer accessible, the mobile node tries to discover a new default router, which is communicated to it by router advertisement. In this context, the prefix, and thus the current care-of address, are set.

When the mobile node reaches its home link again, home registration takes place. Among other things, this involves setting the H bit (home registration) and setting the lifetime to 0. The home agent then knows that it no longer needs to send the packets through the tunnel.

What About Security?

Communication between the mobile node and the correspondent node is vulnerable to various attacks, such as man-in-the-middle, session hijacking, denial of service, and so on. An essential safety measure is to protect the connection between the MN and the HA through an IPsec tunnel with ESP. This ensures that all messages between the mobile node and home agent are protected, including binding updates and acks, home test messages, and ICMPv6 messages. The binding updates between the mobile node and correspondent node are not protected by IPsec, but by the return routability process. However, certain extensions exist here, such as the binding authorization data option, to protect communication.

Because slightly different rules apply to Mobile IPv6, different RFCs describe modifications to IPsec for use with MIPv6. They include RFCs 4555 and 4621, which deal with the use of IKEv2 in these scenarios, and RFC 3776, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents.” Safeguards also exist for special networks in the form of RFCs. However, a complete discussion of all these security areas is beyond the scope of this article.

Conclusions

Mobile IPv6 is a forward-looking technology that could become part of everyday life in the IT networking world. Providers will offer various service packages to customers to ensure smooth connections across various networks – roaming without even temporary drops on the network connection. Because of a general trend toward mobile devices – amplified by the tablet boom – the use of such technologies is a logical development.

Support for MIPv6 has been limited thus far. Microsoft’s operating systems, including Windows 8 and Windows Server 2012, do not provide full support. Linux can be extended to accommodate MIPv6 with the UMIP daemon, and Android systems currently rely on hacks to support MIPv6. Additionally, Apple’s iOS does not support MIPv6.

At the end of the day, IPv6 will need to be widely available to enable use of Mobile IPv6 without migration technologies such as 6to4 tunnels. The Mobile IPv6 standard will continue to develop and will probably include even more interesting extensions in the future. In fact, many additions and enhancements to Mobile IPv6 already exist, including Network Mobility (NEMO) and Hierarchical Mobile IPv6.

The Author

Eric Amberg has many years of project experience in IT infrastructure and freelances as a trainer and consultant. His main focus is on networking topics. In his seminars and video courses, he emphasizes hands-on training.