Mobile IPv6

As the Internet evolves from IPv4 to IPv6, mobility support in the Internet is also evolving accordingly. In the migration, seamless mobility becomes even more important because mobile users will likely account for a significant portion of the Internet population. Although the underlying principles of the Internet remain the same, IPv6 introduces mechanisms and features that should be considered by supporting protocols as they are designed. To this end, Mobile IP for IPv6 is being developed to efficiently leverage these nuances.

The aim of this section is to give you an idea of how the Mobile IP protocol is maturing. We start with an overview of Mobile IPv6 and then highlight the differences between Mobile IPv6 and Mobile IPv4. The section examines some of the issues that are arising in the design and considers the lessons that are being learned along the way.

Protocol Operation

The Mobile IPv6 base protocol is specified in IETF Request For Comment (RFC) 3775 to support communications of IPv6 hosts traversing IPv6 subnets.[1] It operates in much the same way as Mobile IPv4, with some differences pointed out in the section "Differences Between Mobile IPv4 and Mobile IPv6," later in this chapter.

When an IPv6 subnet boundary is crossed, the Mobile Node detects the network topologic movement and signals its Home Agent. The signal updates the Home Agent, which maintains the location binding of the Mobile Node's home IP address and the Mobile Node's current CoA. The home IP address is an address on the Home Network that identifies the source for the Mobile Node's communications. The CoA is the network access IP address on the Foreign Network that identifies the location of the Mobile Node. When the Home Agent receives the signal, the integrity of the information is checked, and the message source is authenticated before the mobility binding is updated. The binding sets up a forwarding entry to tunnel the Mobile Node's traffic to the CoA. At this point, the IPv6 Mobile Node can enjoy seamless mobility while roaming. You might be saying to yourself, "This sounds just like Mobile IPv4." You are right, but did you notice that there was no mention of a FA? Keep reading.

The location binding remains until the entry's lifetime expires or an explicit deletion notice from the Mobile Node is received. Given an existent binding, the Home Agent intercepts traffic destined for the Mobile Node's Home Address and encapsulates the packet to reach the Mobile Node. The encapsulated packet is destined to the CoA. Upon receiving an encap-sulated packet, the Mobile Node removes the tunnel header to obtain the original packet. Traffic from the Mobile Node is tunneled back to the Home Agent. The payloads in the tunnel can be protected by encryption. The source of the packet is the CoA that is topologically correct. The Home Agent decapsulates the packet and routes the payload containing the inner packet to the CN. The source of this packet is the Mobile Node's Home Address. Communication between the Mobile Node and CN bounces off the Home Agent in a figurative sense. Figure 9-7 shows the signaling and data flow of Mobile IPv6.

Figure 9-7. Mobile IPv6 Signaling and Data Flow

Route Optimization (Return Routability) in Mobile IPv6

The routing path for communication between a Mobile Node and CN can be optimized to allow data traffic to be exchanged directly between them. This is known as route optimization. Route optimization is a standard component in Mobile IPv6. As you would guess, it requires secure control signaling between the Mobile Node and CA. For traffic from the Mobile Node to the CN, the source IP address is the CoA and the destination IP address is the CN's IP address. The source and destination addresses are reversed for traffic from the CN to the Mobile Node.

Sounds great, but how does it work in the Internet? The Mobile IPv6 secret sauce is embedded in the IP header. The sender stores the Mobile Node's Home Address in the IP header of the packet to the recipient. When the packet is received on the CN, the source IP address is replaced by this Home Address so that an application believes that the peer is the Mobile Node (on its Home Network) and is unaware of the routing path taken from the CoA to reach the CN. In the other direction, when the Mobile Node receives a packet, the destination IP address is replaced by this Home Address, although the supplanted CoA ensured arrival through an optimal path.

The main challenge in route optimization is securing the control message for two hosts that do not have a preexisting security relationship. To this end, a clever, though not flawless, mechanism known as the Return Routability procedure was designed to set up the dynamic security credential between the Mobile Node and CN. The concept is based on the reasonable assurance that the Mobile Node is, in fact, reachable at both the CoA and its Home Address.

When the Mobile Node wants to set up an optimal routing, it signals to the CN through both paths: one path through the Home Network and one path directly from the Foreign Network. One message reaches the CN through the Home Agent, whereas another message arrives directly using the CoA as the source IP address. The CN responds by sending two messages, one on each path as well. Here's the first clincher: Only the receiver of both replies can formulate the security credential to signal the CN to set up the Mobile Node's Home Address and CoA association. Here's the second clincher: The solution operates with no security infrastructure or preestablished relationship between the Mobile Node and the CN. Having such a stateless functionality on the CN is a significant benefit.

Remember the previous statement in this chapter that described Return Routability: "a clever though not flawless mechanism." It is not flawless because the bad guy in the middle of both pathsa point in the Home Agent path after the IPSec tunnelcan rudely steal the security credential of the association. Also, the scheme is not efficient for mobility because the key is only for the Home Address and CoA binding. Therefore, the optimized path is maintained only if the Return Routability procedure happens each time the Mobile Node moves to a new CoA. Also, the lifetime of the key requires the procedure to run within 7 minutes. Note that the additional signaling for Return Routability takes time to set up an optimal path. While the procedure is in progress, the Mobile Node communicates with the CN through the Home Agent.

Mobile IPv6 Messaging

Mobile IPv6 introduces new messages to IPv6 and new options to extend existing IPv6 mech-anisms. Numerous enhancements are found in the Mobile IP working groups, which propose more messages and options. This section covers the fundamental messages in the base protocol.

Move Detection

Because you found out that no FAs exist in Mobile IPv6, you might have wondered: "How does the Mobile Node perform move detection because there is no agent signaling?" When the Mobile Node attaches to the network, movement detection automatically happens. The IPv6 Neighbor Discovery (RFC 2461) allows the Mobile Node to learn its current subnet information and determine whether any subnet was traversed. After detecting that it is on a new subnet, the Mobile Node obtains an IP address using either DHCP or autoconfiguration, and registers with its Home Agent and/or CN. However, the RFC was not suited for the mobile environment because it had limited the minimum router advertisement interval to 3 seconds. This value would not be timely enough for a Mobile Node to learn whether the subnet had changed. Mobile IPv6 enhanced the interval to support millisecond granularity to achieve faster move detection using periodic router advertisements.

The Mobile Node does not need to passively await the router advertisements. It can send a router solicitation immediately after the link-layer state becomes active. Unfortunately, no standards exist for detecting network attachment, though Mobile Node implementations typically support this mode of operation. The solicitation/ advertisement exchange method is superior to periodic advertisements because of the asynchronous nature for better performance and reduced wireless bandwidth consumption.

Registration Messages

The premise of basic mobility starts with the following messages. Their purpose is to signal a Mobile Node's network access location to the Home Agent or CN:

  • Binding Update message

  • Binding Acknowledgment message

The Mobile Node sends a Binding Update to inform the Home Agent or CN of its current location when it is not on its Home Network. The location informationthe mapping of the Home Address to the CoAis stored in the binding cache entry, which sets up the routing logic on the Home Agent and CN to deliver traffic targeted for the Mobile Node's Home Address toward the Mobile Node's CoA. The traffic-flow service allows the Mobile Node to maintain communications using its Home Address while changing the network access location identified by the CoA. The Binding Acknowledgment is sent by the Home Agent or CN to confirm the reception of the Binding Update. Both messages are protected by the IPSec protocol, specified in the companion RFC 3776, between the Mobile Node and Home Agent. The binding management key, described in next set of messages, protects the messages between the Mobile Node and CN. If you read too quickly, you might have missed that the same messages are protected differently between pairs of mobility entities. Remember that the Mobile Node and CN cannot have a preexisting security relationship? That's why the binding management key is used instead. See how this dynamic key is derived in the next section. The Binding Update and Binding Acknowledgment messages are analogous to the RRQ and RRP messages in Mobile IPv4. They perform the same roles in IP mobility operation.

An alternative method is available for authenticating the Binding Update and Binding Acknowledgment messages that is similar to Mobile IPv4. The authentication option is covered in the section "Lessons Learned," later in this chapter.

Route Optimization (Return Routability) Messages

The following messages and mobility options enable an optimized routing path for traffic between the Mobile Node and CN through the Return Routability procedure:

  • Home test init (HoTI) message

  • Care of test init (CoTI) message

  • Home test (HoT) message

  • Care of test (CoT) message

  • Binding refresh request

  • Binding error message

  • Home address destination option

  • Type 2 routing header option

  • Binding authorization data option

To achieve an optimal path, the CN needs to set up a binding cache entry for the Mobile Node's Home Address/current CoA. This state requires a Binding Update message from the Mobile Node. The signaling must be authenticated by the CN. But how can this happen if the Mobile Node and CN don't share a key? The key that is known by the CN must somehow be transported to the Mobile Node. The trick lies in the relationship of the key-generation material and the two addresses.

A simplified analogy of the scheme goes like this: Jane wants to tell John something and asks him to provide a secret code. John writes "1+2" on a piece of paper and rips it in half across the plus sign. Each piece is mailed separately to Jane at address A and address B. When Jane receives both of them, she knows that the answer is 3. That value authenticates the message that Jane sends to John: "I live at both address A and address B. The answer is 3."

Specifically, the CN has a master key to use for authentication of all Binding Updates from any Mobile Node. This master key is used only to derive a pair of key-generation tokens, which combine to form the dynamic binding management key used for authentication of the Binding Update. Only one of the tokensthe one that has a relationship with the addressis delivered on each path. Derivation of the binding management key requires possession of both token values. Obtaining the tokens requires the recipient to be reached at both the Home Address and CoA. The following demonstrates how the messages derive the binding management key.

Figure 9-8 illustrates the message exchanges in the Return Routability procedure. The HoTI message is sent by the Mobile Node to request a token from the CN through the Home Agent (as shown in 1A). The purpose of the HoT message is to deliver the token to the Mobile Node on the Home Address path (as shown in 2A). The token value is calculated with the CN's master key, Home Address, and a random number. The Mobile Node sends the CoTI message to request a token from the CN through the direct path (as shown in 1B). The CoT message carries the other token to the Mobile Node on the CoA path (as shown in 2B). The token value is based on the CN's master key, CoA, and a random number. The Mobile Node derives the binding management key from the Home Address and CoA tokens. At this point, the Mobile Node can send the Binding Update with the binding authorization data option that contains a cryptographic value generated from the binding management key. The CN derives the pair of token values that are based on the fields within the Binding Update message to obtain the same binding management key. Thus, the CN can authenticate that the message is from the right Mobile Node. The Binding Acknowledgment is sent to the Mobile Node.

Figure 9-8. Mobile IPv6 Return Routability Procedure

The advantage of this mechanism is that the CN is stateless. The CN is the responder and keeps no correlation between the HoT and CoT tokens it sends to the Mobile Node. CN derives the token it had sent to the Mobile Node based on the information that the Mobile Node includes in the Binding Update and then derives the binding management key. The CN responds to exactly one message with each request it receives from the Mobile Node, thus avoiding reflection attacks and packet multiplication attacks. This means that one packet sent to a destination generates multiple packets in response.

The CN sends a binding refresh request to the Mobile Node to extend the lifetime of the binding cache entry. This message requests the Mobile Node to initiate the Return Routability procedure.

After the binding cache entry is established by the exchange of Binding Update and Binding Acknowledgment messages, the traffic can flow directly, as illustrated in Figure 9-9. In Step 1, the Mobile Node sends packets to the CN using the Home Address destination option, which identifies the Mobile Node's Home Address to the recipient in the IP header. The Home Address destination option allows the Mobile Node to communicate directly to the CN using the CoA as the source IP address of packets sent out. The CN would know the IP address of the Mobile Node, regardless of where the packet came from. The Home Address is invariant, while the CoA is transient and depends on the location of the Mobile Node. In Step 2, if the CN receives a data packet with a Home Address destination option from a Mobile Node that had not performed Return Routability, the binding error message is sent to the source address of the offending packet. Otherwise, the source IP address is replaced by the Home Address in the Home Address destination option on the CN. In Step 3, the CN sends packets to the Mobile Node directly using the Type 2 routing header that contains the Home Address. The packet is destined to the CoA. In Step 4, the Mobile Node receives the packet and swaps the Home Address (in the Home Address destination option) and CoA (in the destination IP address field). The applications on the Mobile Node and CN communicate using only the Home Address, unaware that the CoA is the routing address that transports the packets between them.

Figure 9-9. Mobile IPv6 Optimized Routing

ICMP Messages

Mobile IPv6 defines a dynamic Home Agent address discovery (DHAAD) mechanism that allows the Mobile Node to dynamically choose a Home Agent from a subnet. New IPv6 Internet Control Message Protocol (ICMP) messages are introduced to allow for discovering a Home Agent through this process:

  • Home Agent address discovery request

  • Home Agent address discovery reply

If the Mobile Node knows the home subnet prefix but not the specific Home Agent address, the Mobile Node sends a dynamic Home Agent address discovery request message to the Home Agent anycast address. The Home Agent anycast address is constructed from the prefix by appending a well-known Home Agent suffix. The Home Agent that receives the message responds with the list of available Home Agents. This information is sent in the dynamic Home Agent address discovery reply message. Each Home Agent is aware of other Home Agents on the same link based on the router advertisements received. The DHAAD request and reply messages are not protected or authenticated. If these messages are to be protected, the Mobile Node needs to know with which Home Agent to establish IPSec. Initiating IPSec requires the Mobile Node to know which peer is the Home Agent. Because the Mobile Node does not know the Home Agent and, in fact, is attempting to obtain that information, the messages cannot be protected. Unavoidably, the IPv6 addresses of all the Home Agents on the subnet are sent in the clear to the Mobile Node.

For those who are familiar with Mobile IPv4 dynamic Home Agent address resolution, the scheme sends the RRQ to a particular subnet using a subnet-directed broadcast. In this case, all Home Agents on the subnet receive the request and each sends a RRP, informing the Mobile Node of its IP address. In Mobile IPv6, only one Home Agent receives the ICMP request and sends an ICMP reply with the list of Home Agents on the subnet.

Differences Between Mobile IPv4 and Mobile IPv6

The mobility support is fundamentally the same for Mobile IPv4 and Mobile IPv6. The Home Agent and Mobile Node provide the same functional roles. The Mobile Node still selects which interface to use for communications by notifying the Home Agent where to route its traffic. The Home Agent continues to tunnel packets to the Mobile Node. The protocol remains transparent to other nodes, with the exception of route optimization, which also involves the CA.

However, Mobile IPv6 differs from an IPv4-based solution in the following ways:

  • The FA is eliminated.

  • Route optimization (RO) is an integral component. The Mobile Node and CN decide whether they want to enable an optimal path, and the Home Agent decides whether RO should be allowed. Traffic between a Mobile Node and CN uses a new routing header and destination option, instead of a tunnel header.

  • Mobile IPv6 is a part of the IPv6 protocol itself, not a User Datagram Protocol (UDP) message.

  • The control messages are required to be protected by IPSec. Authentication extension is an optional feature, as described in the section "AAA-Based Dynamic Key Generation."

  • The dynamic Home Agent address discovery is based on the anycast address, not the subnet-directed broadcast.

  • IPv6 autoconfiguration simplifies the Mobile Node's CoA assignment.

Some of the differences in the features offered by IPv6 are innate. We consider each of the previous points and look at the merits and tradeoffs involved.

An important difference is that no FAs exist in Mobile IPv6. One reason that Mobile IPv4 needed a FA is because of the lack of IP addresses in IPv4. Because it would be costly if each Mobile Node on the Foreign Network consumed an IP address (CoA), the FA allowed numerous Mobile Nodes to use the same CoA. On the contrary, IPv6 has an abundance of addresses. Therefore, this Foreign Network function was considered unnecessary and, in a sense, in the way for mobility in IPv6.

However, as with most things, it is not that clear cut. The time to obtain an IP address on the foreign subnet depends on the address allocation scheme involving duplicate address detection. Nevertheless, to start the registration process in the FA's case will likely take longer than the agent or router advertisement. The CoA belongs to the FA and therefore does not have the address contention issue.

An important benefit of having a FA is that only the original packet travels over the valuable air link. Without FAs, Mobile IPv6 now requires traffic to the Mobile Node to also carry a tunnel header from the Home Agent or a new IPv6 routing header from the CN. If you look closer, the number of tunnel endpoints on the Home Agent increases because no aggregation point exists on Foreign Networks; this impacts the processing and memory on the Home Agent. Furthermore, the lack of a FA means that no mobility signaling is available to enforce Foreign Network policy. Not to cry over spilled milk, but having a FA would have also helped the route optimization scenario, where the Mobile Node moves between subnets on the same FA. Specifically, the CNs need not be signaled, and traffic in transit need not be lost. It's almost like this: "Be careful what you ask for; you might just get it!"

In addition, as with most things, another solution usually exists. In this case, having a Mobility Anchor Point (MAP) in the foreign domain [described in the section "Hierarchical Mobile IPv6 (HMIPv6)," later in this chapter] provides some of the benefits of having a FA function.

Debate continues on the practical benefits of route optimization. Academically speaking, there's no doubt that reaching from one point to another in a logical straight line is better than traveling through a triangulation point. But, when you consider that routing directs packets based on various factors such as load, cost, administrative reasons, and so on, it is no longer certain. In fact, the path from the CN to the CoA can have longer transit latency than the path from the CN to Home Agent to CoA. Regardless, route optimization is commonly believed to be a "good thing." But good things don't come free.

Bypassing the Home Network means a lack of centralized policy enforcement and accounting for billing on the Mobile Node's traffic, and new dependency on the Foreign Network to provide these critical functions.

Additional signaling is incurred between the Mobile Node and the CN to set up the optimal path. Signaling introduces more processing on both ends and more consumption of air-link bandwidth. Also, a trust relationship is required between peers to update the routing entry. Mobile IPv6 route optimization uses the Return Routability procedure to set up the keys to protect the signaling between the Mobile Node and the CN. If the CN can exchange signaling with the Mobile Node using both addresses, one can assume that the Mobile Node is legitimate, especially because the request is to bind the addresses. As discussed previously, one known weakness in the Return Routability scheme is interception by a bad guy in the middle, when messages from both addresses are in the clear.

Location privacy is an issue when route optimization is used. Even though the Mobile Node's CoA does not provide adequate physical location, nevertheless the network access location is known to the CN. This can be enough detail to warrant reasons for nondisclosure.

Some Mobile IPv4 deployments support Voice over IP without a noticeable quality issues. VoIP traffic is highly susceptible to loss, latency, and jitter. Loss is when a packet is dropped in the network. Latency is the one-way trip time from one end to the other side. Jitter is the variance in time interval between the incoming packets. Various techniques are used, such as buffering and repeating on the receiving node, to improve the perception of the voice quality. Although the traffic in this network is always routed through the Home Agent, users could not detect that their conversations were Mobile IPenabled VoIP.

Another common IPv4 application is the enterprise virtual private network (VPN), a secure pipeline between the users and their corporate network. This virtual link is set up to allow employees to access their services at work through a VPN gateway. At this point, it's unclear how this model will be adopted in IPv6. If a similar technique is used, the VPN gateway becomes the triangulation point between the Mobile Node and CN. Thus, the route optimization cannot be applied because the traffic is secured by the VPN gateway where it is routed through.

Despite the cost of additional states for the peers, some additional messaging, and roundtrip delays, proponents of route optimization argue that the benefits include the following:

  • Reduction of traffic load on the Home Network

  • Less network load on the entire Internet

  • Less jitter and latency in communications

  • Robustness against network problems because of fewer routing path traversals

  • Avoidance of tunneling overhead

Traffic from the CN to the Mobile Node uses a new routing header instead of a tunnel header.

Tunneling places a new IP header in front of a packet, allowing traffic to be directed to another location. The cost is that the packet "grows" by the size of the additional IP header(s). One side effect of an increased packet size is that fragmentation might be needed, as discussed for Mobile IPv4. Regardless of whether fragmentation occurs before or after encapsulation, the packet requires reassembly, which adds latency to the traffic. Another side effect of encapsulation is that the increased-size packet is sent over the air link to reach the Mobile Node, reducing the effective bandwidth of the air link.

With route optimization in Mobile IPv6, a new IPv6 routing header trims the overhead by replacing the tunneling method. Instead of an entire IPv6 header being added to a packet from a CN, only the Mobile Node's Home Address information is added through the routing header, and the packet is destined to the CoA instead. As a comparison point, an IPv6 header using the Advanced Encryption Standard (AES) for encryption is 52 bytes while the Home Address option is 18 bytes. The typical Mobile IPv4 tunnel header is 20 bytes.

The routing header allows the packet to traverse a path leading to the CoA, and thus, enables the CN to send directly to the Mobile Node.

The signaling used in Mobile IPv6 is a part of the IPv6 protocol itself. In Mobile IPv4, UDP messages perform the registration. In addition, the control messages are protected differently.

The IPSec Authentication Header (AH) or Encapsulating Security Payload (ESP) protects the signaling between the Mobile Node and Home Agent, as specified in RFC 3776. The integrity of the message can be confirmed by authentication. In Mobile IPv4, IPSec might not be supported on the Mobile Node and Home Agent and, thus, could not be used as the standard security mechanism.

In contrast, all IPv6 nodes are required to support IPSec. As you have seen before, theory is not always reality. Thus, the nodes might not always support IPSec. Moreover, many protocols, including IPSec, were designed and implemented without mobility in mind, and thus do not lend themselves seamlessly to integration with mobility.

Is there a need then to support IPv6 nodes without IPSec or with only static IPSec functionality? The section "Authentication Option," later in this chapter, covers this topic.

The dynamic Home Agent resolution method in Mobile IPv6 allows the Mobile Node to choose the Home Agent on a particular subnet. If the Mobile Node knows the home subnet prefix but not the specific Home Agent, the Mobile Node can send an ICMP message destined to the anycast address on the home subnet. Normal routing takes the message to the nearest Home Agent, which responds with the list of available Home Agents. The Home Agent updates the list based on reception of router advertisements on the subnet.

In Mobile IPv4, the Mobile Node sends the RRQ to the subnet-directed broadcast address. This is a special address that is routed normally to a particular subnet. The router on that subnet broadcasts this message on the targeted subnet. All the Home Agents on the subnet receive the RRQ and send a RRP, informing the Mobile Node of their IP addresses.

In IPv6, a device can autoconfigure its IP address after receiving the router advertisement. This is possible because the Mobile Node can learn the subnet prefix and append its message authentication code (MAC) address, which is typically unique, to obtain a routable IP address on the subnet. Of course, duplicate address detection must be used to avoid collision with other nodes. This mechanism is simple and quick, allowing the Mobile Node to get the CoA for home registration. In IPv4, a common procedure is using DHCP, which takes four message exchanges between the client and the DHCP server.

In IPv4, Address Resolution Protocol (ARP) finds the MAC address for a particular IP address. The IP addresstoMAC address association is stored in the ARP entry so that the sender knows which MAC address to use to send a packet destined to that IP address. For Mobile IPv4, the Home Agent sends gratuitous ARP messages on the home subnet after the Mobile Node registers to update devices that already have an ARP entry for the Mobile Node. In addition, the Home Agent performs proxy ARP by responding to an ARP request on the home subnet. Both methods ensure that packets destined for the Mobile Node are received by the Home Agent, which tunnels them to the Mobile Node.

In Mobile IPv6, these Home Agent functions are provided by the IPv6 neighbor discovery mechanism. ARP is an Ethernet-based protocol, whereas neighbor discovery is an IP-based protocol. Both mechanisms provide the same end functionality.

Transition to Mobile IPv6

Mobile IPv4 deployments are not switching over to Mobile IPv6 overnight. Is there a need to leverage existing Mobile IPv4 infrastructure to support IPv6 clients? Or would it be better to build a future-proof Mobile IPv6 infrastructure for IPv6 clients and legacy IPv4 clients? Should there be coexisting Mobile IPv4 and Mobile IPv6 infrastructures?

As a reference point, cdma2000 is expected to support both Mobile IPv4 and Mobile IPv6. IETF has proposals that support each of these cases. The answer will depend on the network that is used for IPv6 services. If an existing Mobile IPv4 network is already in place, an overlay of the IPv6 data traffic would suffice. Most likely, we will see new Mobile IPv6 networks built for these new services. The following section explains how the Mobile IPv4 clients can upgrade to Mobile IPv6 to reap the benefits.

Lessons Learned

Mobile IPv6 has a clear advantage in that it is the successor to Mobile IPv4. This might be stating the obvious, but because Mobile IPv4 has been deployed and tested in the field, much can be learn from the experience. So, what was learned from Mobile IPv4 that can be applied to Mobile IPv6?

A major eyeopener was that service-provider deployments use the AAA infrastructure. Although the Mobile IPv6 protocol defined in RFC 3775 is designed using a security association between a Mobile Node and a Home Agent, the relationship between the Mobile Node and AAA is mandatory in these deployments. And, the NAI is the common identifier for the AAA infrastructure. Thus, it seems that using an authentication mechanism for the NAI is prudent, because the standard IPSec is between the IP endpoints. Another point to consider is that the network would like to use the same security key with the Mobile Node, regardless of whether it is using Mobile IPv4 or Mobile IPv6.

Deployment of Mobile IPv4 struggled because of the configuration needed on the client. It was then easy to realize that Mobile IPv6 needed a method to bootstrap the Mobile Node configurations, such as the Home Agent address, security association with the Home Agent, and so on, using the AAA infrastructure.

Not all lessons learned need to stem from deployment experience. Just analyzing the situation and behavior that would ensue gives rise to clever solutions. To this end, Hierarchical Mobile IP and Fast Mobile IP (described in the sections that follow) are enhancements to Mobile IPv6 that make the protocol more efficient.

Network Access Identifier

In Mobile IP deploymentswhether IPv4 or IPv6a Mobile Node is typically identified by an NAI for authentication purposes. Recall that a Mobile Node using an NAI can be dynamically assigned a Home Address, and even its Home Agent. Although the Mobile Node is identified by the NAI, the Home Address remains the routing identifier, and the Home Agent serves as the Home Address routing anchor.[2]

The authentication identifier (NAI) and routing identifier (Home Address) provide different functions but are linked in the control message processing. The control message is authenticated based on the NAI and then updates the routing for the Mobile Node. Identifying a Mobile Node by an NAI allows integration with the AAA infrastructure.

Because many Mobile IPv4 deployments already use NAI to authenticate the Mobile Nodes, this sets precedence for Mobile IPv6. Thus, a service provider can use the same AAA infrastructure, regardless of the IP version used by the Mobile Nodes.

Authentication Option

The Mobile IPv6 control messages require integrity, authentication, and antireplay protection. No doubt, IPSec in conjunction with IKE surely provides these functions. However, as pointed out previously, IPSec might not always be a viable and practical method. For example, consider the following:

  • IKE and IPSec are general-purpose protocols that can be heavyweight for simple fast authentication in a mobility environment.

  • No standard method exists for integrating IKE/IPSec with the AAA infrastructure.

  • Mobile IPv4 deployment migration to Mobile IPv6 requires the same security infrastructure.

One key proponent for an alternative authentication method is the 3GPP2 standards organization, which is chartered to develop the specifications for cdma2000 wireless communications systems. Cdma2000 operators have deployed some of the largest Mobile IPv4 customer base.

In IETF, this issue has been heatedly debated. A majority, although not an overwhelming percentage, of participants in the Mobile IPv6 Working Group favors the introduction of a new destination option to provide authentication between the Mobile Node and Home Agent. Here are the practical rationales behind IPSec-less authentication:[3]

  • IPSec might not be required or feasible in all cases in which Mobile IPv6 can be used. For small price-sensitive devices, the use of IPSec can consume too much battery life and too many processing cycles. Although this type of Mobile Node is not IPv6 compliant because IPSec is a mandatory component, it is still a reality.

  • The Common Enterprise VPN solution has another IPSec to encrypt traffic between the Mobile Node and the VPN gateway. Mobile IPv6 needs encryption between the Mobile Node and Home Agent for the Return Routability procedure used for route optimization. Two layers of encryption are redundant and reduce the throughput rate.

  • The multiple round trips needed to perform IKE to establish the IPSec security association increase the delay during initial setup and handoffs.

  • No standard mechanism currently exists for IKE/IPSec to use the AAA infrastructure to authenticate a Mobile Node. Support for this method in existing implementations is vendor specific. AAA-based authentication is a common practice in Mobile IPv4 service provider networks. It would make sense to use the same AAA mechanism, or specifically the Mobile Node-AAA key, to authenticate Mobile IPv6 or dual-stack clients.

  • Some IPSec implementations can require significant modifications to support Mobile IPv6.

  • The change needed to support Mobile IPv6 in IPSec hardware accelerators is problematic because the development cycle is expensive and occurs over a period of time.

  • IPSec is security critical. In some systems, it might have been through a formal security evaluation. Changes to IPSec risk potential breakage that can compromise security.

  • Some implementations support AH and ESP, but not IKE. Even if the implementation supports IKE, major changes to IKE might be needed to support Mobile IPv6.

  • The use of a manual IPSec security association in service-provider deployment suffers from scalability issues and creates a provisioning nightmare. In addition, this method lacks replay protection.

  • Because the IPSec security association is linked to the Home Address, manual IPSec would prohibit the flexibility of a dynamic Home Address or home prefix assignment.

  • Configuration of IPSec by users is challenging. How are users supposed to configure the security policy database? If IPSec is being used for other purposes at the same time (for example, corporate VPN access), how can you make sure that no conflict exists with Mobile IPv6?

  • Some user feedback suggests the need to make IPSec easier to configure or to have an alternative for Mobile IPv6 authentication.

    Opponents to the alternative authentication option[4] offer the following arguments:

  • IPSec is part of a standards-based IPv6 node. Why should Mobile IPv6 be modified to satisfy deviants? The authentication option might be promoting IPv6 noncompliance in regard to IPSec.

  • Having multiple authentication methods complicates implementation and deployment.

  • Why not keep IPSec but use the AAA infrastructure to set up a security association between the Mobile Node and Home Agent?

  • A better solution is to use IKEv2 with EAP for addressing the problem of a standardized integration with AAA-based credentials. This means that EAP is carried in the IKEv2 messages and authenticates the Mobile Node with the AAA server. Then IKEv2 dynamically sets up the IPSec security association between the Mobile Node and Home Agent. Note that IKEv2 is a work in progress in IETF, and it will be some time before standards-based commercial implementations are available.

  • Route optimization is not supported in the alternative authentication method.

    Technical merits can be found on both sides. Having the option of a built-in Mobile IPv6 authentication method allows the real world to decide what works. And deployments will likely use the timely solution that provides the most benefit.


In Mobile IPv6, the IPSec security association protects the Binding Update between the Mobile Node's Home Address and the Home Agent's IP address. The Mobile Node must know its Home Address, its Home Agent address, and the IPSec security association with that Home Agent. In deployment scenarios, the Mobile Node can be dynamically assigned a Home Address by the Home Agent or AAA server, and moreover, the Home Agent can be dynamically assigned by the AAA server. These deployment issues challenge the simple security relationship between the Home Address and Home Agent.

The question is then "How do you seed the Mobile Node with the Home Address, Home Agent address, and IPSec security association when the addresses are dynamic in nature?" Commonly, a AAA server authenticates users of the network and grants access and service authorization, as well as providing accounting. The Mobile Node and AAA server have a security relationship in this type of network infrastructure. Thus, logically, the Mobile Node can be bootstrapped with the required Mobile IPv6 information by integrating with the AAA server.[5]

The benefit of integrating with a AAA infrastructure is that it allows the Home Address and Home Agent to be dynamically assigned. Besides not having to be preconfigured with these parameters, dynamic assignment has several other benefits. On the dynamic Home Address assignment front, benefits include DHCP-based address management, duplicate address collision recovery, randomly generated addresses for privacy, and address autoconfiguration. Dynamic Home Agent assignment is desirable for the following reasons:

  • The Home Agent discovery mechanism on a subnet

  • Load balancing among multiple Home Agents

  • Locating the nearest Home Agent to the Mobile Node

By having the ability to bootstrap the Mobile Node through the AAA server, all of these benefits can be gained.

The solution for integration with the AAA infrastructure is in the standardization process. One approach is using EAP,[6] which has the following steps:


The Mobile Node boots up and initiates network access authentication using EAP.


Optionally, a protected channel [for example, a Transport Layer Security (TLS) tunnel] is set up for delivery of subsequent EAP signaling. This step is necessary when sensitive information is exchanged between the Mobile Node and the AAA server.


Authentication between the Mobile Node and the AAA server happens. The procedure and its security properties depend on the selected EAP method.


After authentication, the AAA server authorizes Mobile IPv6 service and downloads host configuration information within EAP payloads to the Mobile Node. At this point, the Mobile Node knows its Home Address, the assigned Home Agent address, the peer authentication method (that is, certificates or a preshared key), and the cryptographic material (for example, a preshared key) needed to set up an IPSec security association with IKE. The IKE preshared key can be either constructed by the AAA server and then delivered to the Mobile Node or independently derived by each side.


After successful authentication and Mobile IPv6 service authorization, the EAP session is terminated.


The bootstrap has completed, which allows the Mobile Node to register with the assigned Home Agent using the IKE security association obtained in Step 4.

As with most proposals in the IETF, technical debates will continue on the various aspects of the design.

In cdma2000 deployments, a Mobile NodeHome Agent authentication option protects the Mobile IP signaling. Specifically, the Mobile NodeHome Agent key is dynamically generated by the Mobile Node and AAA server at the beginning of a mobility session. The AAA then delivers the shared key to the Home Agent so that the Home Agent can use the key to protect the Mobile IP messages between itself and the Mobile Node. Cdma2000 networks have the PDSN that participates in the bootstrapping scheme.

In the 3GPP2 specification, the PDSN is the network access server that authenticates the Mobile Node during PPP session setup. During the authentication phase, the PDSN downloads the Home Agent address and Home Address/home subnet prefix information from the home AAA server. Note that the NAI identifies the Mobile Node for authentication purposes and the Home Address is only a routing identifier. This means that any IP address can be assigned to the Mobile Node, regardless of whether it was provisioned statically or dynamically generated by the network, or derived by the Mobile Node, as in the case of IPv6 autoconfiguration using the home subnet prefix.

After the PPP session comes up, the Mobile Node learns about its Home Address and the assigned Home Agent from the PDSN during DHCPv6. Then the Mobile Node sends a Binding Update to the Home Agent. The message contains the NAI option and is protected by the Mobile NodeAAA server authentication option. The Home Agent processes the Binding Update by sending a AAA request with the extracted authentication credentials (for example, NAI, authentication option fields) to the home AAA server. The home AAA server authenticates the Mobile Node and generates the Mobile NodeHome Agent key by executing a defined formula with the Mobile NodeAAA server key, random number, Home Agent address, and Home Address. The Mobile NodeHome Agent key is included in the AAA reply that is sent to the Home Agent, which stores the key to authenticate the Mobile NodeHome Agent authentication option.

The Home Agent performs duplicate address detection on the Home Address in the Binding Update before sending the Binding Acknowledgment to the Mobile Node. The message contains the NAI option and the Mobile NodeHome Agent authentication option. When the Mobile Node receives the Binding Acknowledgment, it generates the same Mobile NodeHome Agent key derived from the same formula to validate the message. Further reregistrations use NAI to identify the Mobile Node and Mobile NodeHome Agent authentication option to protect the message exchanges.

The proposed solution provides a bootstrapping mechanism, dynamic Home Address and Home Agent assignment, and a method for Mobile NodeHome Agent key generation.

Hierarchical Mobile IPv6 (HMIPv6)

When the Mobile Node moves to a new location, control messages are exchanged between the Mobile Node and Home Agent to update routing for the Mobile Node's traffic. Until the update is processed, a period exists when traffic to the Mobile Node is forwarded by the Home Agent to the previous location. The number of packets lost during this time directly depends on the latency of the update. Adding some fuel to the fire, if route optimization is being used, the Mobile Node must send updates to all the CNs after a move. The latency between the Mobile Node and CN is another factor that contributes to packet loss. Looking from a different angle, it is not hard to see that the number of update messages required increases with the number of CNs involved. Thus, a move by the Mobile Node consumes precious air-link bandwidth because of the update signaling.

The solution that addresses this issue is to confine the signaling locally and hide the movements from CNs. The MAP is introduced to anchor the CoA of the Mobile Node in the region of the visited network.[7] The MAP operates as a Home Agent serving the regional CoA. The Home Agent and CNs send traffic to the regional CoA to reach the Mobile Node. When the Mobile Node moves inside the region, only the MAP is aware. The movements are hidden from the Home Agent and CN because the MAP directs traffic to the location of the Mobile Node. The result is signaling with reduced latency because the MAP is topologically proximate to the Mobile Node. In addition, air-link usage for updates to CNs is eliminated. Another benefit is location privacy, because the exact visited subnet is unknown for the CN and Home Agent. One disadvantage is that the MAP encapsulates traffic to the Mobile Node, increasing the size of packets over the air. Figure 9-10 illustrates handovers within the region of an MAP.

Figure 9-10. Hierarchical Mobile IPv6

The Mobile Node learns whether the visited network supports HMIPv6 and activates local mobility management with the MAP accordingly. If it is using HMIPv6, the Mobile Node communicates with the Home Agent and CN using the MAP's CoA. The Home Agent and CN perform normal operation using the CoA provided by Mobile Node.

The goal of Hierarchical Mobile IP is to localize the signaling when the Mobile Node moves within a region. Achieving this goal makes practical sense. Generally, micromobility is essential within the access network to provide fast handoffs with minimal packet loss. However, such a function is usually "home-brewed" by each access technology. For example, the Cisco SWAN and Lightweight WLAN Access Point Protocol (LWAAP) support this type of function for WLAN, and cdma2000 has the A.10/A.11 (also known as the RP interface). An MAP might not be necessary depending on the topologic coverage of the Layer 2 micromobility scheme. If the footprint is relatively small, having an MAP would be effective in reducing signaling latency, eliminating Return Routability messages, and reducing the number of packets in transit that can end up being dropped.

Fast Mobile IP

Latency in a network arises from both the network layer and link layer. Network layer hand-over latency is the total time for network prefix detection and location update signaling. Link-layer latency includes scanning for base stations or access points; obtaining signal information such as strength and quality for handover determination, attachment, or association; and network access authentication and authorization.

While Mobile IPv6 can control network layer latency, each link-layer technology addresses its own handover latency. To this end, a fast handover mechanism is introduced for Mobile IPv6.

We now look into some details of the latency issue. After link-layer indication that a Mobile Node has a new network attachment, the Mobile Node must figure out whether it has changed subnets. If it has not, the foreign subnet remains the same and no location update signaling is needed. On the other hand, if the Mobile Node learns about a new subnet, it must first use the duplicate address-detection mechanism before it can use the new CoA on the foreign subnet. Also, the Mobile Node needs to announce itself on the subnet through neighbor discovery message exchange. Then the Mobile Node can signal its Home Agent and optionally any CN(s) to direct traffic to the new CoA. Each of these steps increases the latency for the handover. Real-time applications such as Voice over IP are sensitive to packet loss, latency, and jitter. Therefore, it would be beneficial to reduce these types of problems in the network layer.

The goal is to accomplish as many of the steps a priori to the handover because the purpose of each operation cannot be eliminated. The solution offered in the Fast Handovers for Mobile IPv6 draft[8] tackles the problem in the following three ways:

  • The Mobile Node learns about the new Foreign Network while still at its current location.

  • The Mobile Node signals to set up tunneling from the previous access router to the new access router.

  • The Mobile Node then immediately uses the new CoA to update the Home Agent and CN(s).

The solution has two flavors: predictive and reactive. The predictive fast handover is the scenario when the Mobile Node signals the current access router (AR) to set up for handover to the new foreign subnet. The reactive fast handover is when the Mobile Node signals to the new AR after the handover.

How does the Mobile Node know whether the current AR can provide predictive fast handover? The Mobile Node can signal to the current AR on a direct link whenever "anticipation" of a handover is feasible. When anticipation is not feasible or if the Mobile Node has not received a signal acknowledgment, the Mobile Node can signal immediately after attaching to the new AR's link. Note the assumption that the round-trip time from the Mobile Node to the previous AR is typically much faster than to the Home Agent.

For predictive fast handover, the Mobile Node notifies the current access router, before it moves, which new access router is to be used. How does the Mobile Node know about other Foreign Networks? When the Mobile Node hears a new base station or access point at the link layer, the Mobile Node requests the network prefix mapping from the current access router. The routers are expected know the AP-to-subnet mappings of neighboring routers, though the method is not specified. After the Mobile Node knows the new subnet, it signals the current access router to notify the new access router and tunnel traffic to the new location.

The Mobile Node announces itself on the new subnet and starts using the new CoA immediately to update the Home Agent. In the slight chance that a duplicate address exists, a recovery scheme is in place to select a new CoA for the Mobile Node to use. Figure 9-11 shows the signaling flow of predictive fast handover.

Figure 9-11. Predictive Fast Handover

For reactive fast handover, when the Mobile Node moves to a new AR, it already knows that the new location is a different subnet. Thus, it immediately signals to the new AR to notify the previous AR. The previous AR then tunnels the Mobile Node's traffic to the new AR. In the meantime, the Mobile Node notifies its Home Agent and any CN(s) of its new location. The previous AR's binding of Home Address to new CoA is removed by signaling from the Mobile Node after the location update to the Home Agent and the CN has completed. Figure 9-12 shows the signaling flow of reactive fast handover.

Figure 9-12. Reactive Fast Handover

Note that the fast handover schemes operate independently from normal signaling between the Mobile Node and Home Agent or CN. The signaling is between the Mobile Node and the latest two ARs to reduce packet loss until the location update to the Home Agent and CN completes. If you are waiting to hear how the security relationship between the Mobile Node and current AR, or even between ARs, is established, it is not specified in the draft. One can assume, however, that AR-to-AR communication is secured within the network.

Another point is that some link-layer handover takes a significant amount of time. The signaling needed to improve performance requires intersubnet capability. How much integration between link layer and network layer is needed for fast handover is still under debate. Seemingly, more interaction and cohesiveness between the layers would produce better performance. However, the gain in latency reduction comes at the cost of layer independence.

    Mobile IP Technology and Applications
    Mobile IP Technology and Applications
    ISBN: 158705132X
    EAN: 2147483647
    Year: 2005
    Pages: 124

    Similar book on Amazon © 2008-2017.
    If you may any questions please contact us: