Section 11.4. Mobile IPv6 Communication


11.4. Mobile IPv6 Communication

This section discusses Mobile IPv6 terms and goes into more details on the communication processes.

11.4.1. Binding Cache

Every correspondent node and home agent maintains a Binding Cache for each of its global IPv6 addresses. It lists all mobile nodes for which it has a binding. If it wants to send data to a certain destination, it first searches its Binding Cache, and after this, the Destination Cache for an address.

A Binding Cache entry carries the following information:

  • Home address of the mobile node for the entry. This field is the key to determining the destination address when sending a packet.

  • Care-of address for the mobile node indicated by the Home Address field in this binding cache entry.

  • Lifetime value for the binding.

  • A flag indicating whether this entry is a home registration entry. Present only on a node that acts as a home agent.

  • Maximum value of the Sequence Number field of all previous Binding Updates received for this home address.

  • Information on the use of this entry.

11.4.2. Binding Update List

Every mobile node maintains a Binding Update List. The list has an entry for each Binding Update the mobile node has sent to its home agent(s) and to correspondent nodes for which the lifetime has not expired. If it has sent more than one Binding Update, only the last message with the highest Sequence number is listed.

A Binding Update List carries the following information:

  • IPv6 address of the node to which the Binding Update has been sent

  • Home address for which the Binding Update has been sent

  • Care-of address that was indicated in this Binding Update

  • Lifetime that was indicated in the Binding Update

  • Remaining lifetime for the Binding

  • Highest used Sequence number for this Binding

  • Time when Binding Update was sent

  • State of any retransmissions needed

  • A flag indicating whether further Binding Updates have to be sent to this destination

11.4.3. Return Routability Procedure

The Return Routability Procedure is designed to allow a correspondent node to detect whether the mobile node is reachable at its care-of address as well as at its home address. Only when this has been successfully proven can route optimization (i.e., direct communication between correspondent node and mobile node) be used. The fact that the mobile node can be reached at both addresses indicates that it really is on the foreign link and has a valid registration for the home address. This reduces (but does not eliminate) the risk that this Binding Update is a security attack. Only after a successful Return Routability test does the correspondent node accept Binding Updates from the mobile node and send datagrams to the care-of address of the mobile node directly.

The message flow for the Return Routability Procedure consists of the following steps (for MH types, refer to Table 11-1):

  1. MN sends a Home Test Init message (MH type 1) via HA to the CN. This message carries a Home Init Cookie. This way the CN learns the Home Address of the MN.

  2. MN sends a Care-of Test Init message (MH type 2) to the CN. This message carries a Care-of Init Cookie. It is sent to the CN directly (not through HA). This way, the CN learns the care-of address of the MN.

  3. CN replies to the Home Test Init message with a Home Test message (MH type 3) sent via HA. It carries the Home Init Cookie, the Home Keygen Token, and the Home Nonce Index. The MN can now generate a Home Keygen Token.

  4. CN replies to the Care-of Test Init message with a Care-of Test message (MH type 4) sent to the MN's care-of address. It carries the Care-of Init Cookie, the Care-of Keygen Token, and the Care-of Nonce Index. The MN can now generate a Care-of Keygen Token.

Once the mobile node has received the Home Test and the Care-of Test messages, the Return Routability Procedure has been accomplished. The mobile node hashes the two tokens and creates a 20-byte Management Key, which is obviously also known to the correspondent node that generated the two tokens in the first place. This key will be used by the mobile node to secure the Binding Update to the correspondent node. Upon a successful security check, the correspondent node can accept the Binding Update since the mobile node has proven that it is reachable on the home and care-of addresses contained in the Binding Update.

RFC 4225, "Mobile IP Version 6 Route Optimization Security Design Background," outlines the security considerations and choices that were made when the Return Routability Procedure was defined. The goal of this informational document is to help implementors of MIPv6 understand the design choices and to help people who design mobility of multihoming solutions to avoid some common security pitfalls. The security problems and possible countermeasures are discussed in detail.

11.4.4. Home Agent Operation

When the mobile node is away from home, the HA must intercept all packets destined to the mobile node and tunnel them to the care-of address of the mobile node. It uses Proxy Neighbor Discovery to do so.

11.4.4.1. Proxy Neighbor Discovery

In order to intercept packets destined to the mobile node on the home link, the HA must pretend to be the mobile node. The HA sends Neighbor Advertisements to the All-nodes Multicast address, providing its own link-layer address as link-layer address for the home address of the mobile node. The ND message has the following information:

  • The Source address in the IPv6 header of the Neighbor Advertisement is the address of the HA.

  • The Target Address field in the ND message carries the IPv6 address of the mobile node.

  • The ND Advertisement contains a Target Link-layer Address option carrying the link-layer address of the HA.

  • The Router Flag (R-flag) must be set to 0.

  • The Override Flag (O-flag) must be set. All nodes on the link will update their Neighbor Caches and store the link-layer address.

Now the HA receives all packets on this link that are destined to the IPv6 address of the mobile node. The HA acts as a proxy for the mobile node. It must inspect all Neighbor Solicitations it receives and verify whether the Target Address field corresponds to a Home Registration entry in its Binding Cache. If so, it replies with a Neighbor Advertisement indicating its own link-layer address as the link-layer address for the mobile node. This procedure also defends the mobile node's home address from other home link nodes trying to configure that same address (i.e., Duplicate Address Detection, as explained in Chapter 4).

11.4.4.2. Bidirectional Tunneling

To forward packets destined to the home address of the mobile node, the HA uses an IPv6 tunnel. It inserts an additional IPv6 header called the Tunnel header. The Source address in the Tunnel header is the IPv6 address of the HA. The destination address is the primary care-of address of the mobile node. The mobile node processes the Tunnel header and forwards the decapsulated packet internally to the upper-layer protocols and applications.

In order to receive multicast packets when away from home, the mobile node must register for these group memberships. There are two ways to accomplish this:

  • The mobile node can register with local routers on the Home Link using its care-of address. In this case, it can receive multicast packets directly. These memberships will not survive if the mobile node moves to another foreign network.

  • The mobile node can register for multicast group memberships on its Home Link by sending MLD registrations to its HA, which in turn will forward multicast packets to the mobile node using the tunnel. This will always work no matter how many times the mobile node changes the network.

The following packets are not forwarded to the mobile node:

  • Packets sent to the link-layer address of the mobile node. These packets are answered with an ICMPv6 Destination Unreachable message.

  • Packets sent to the site-local address of the mobile node. (Site-local addresses have been deprecated after the publication of the Mobile IPv6 specification; this will be changed in a future version of this RFC.)

  • Multicast packets sent to a link-local, site-local, or organization-local scope.

Packets sent through the Reverse Tunnel from the mobile node to the HA are decapsulated by the HA and forwarded to their destinations through regular routing mechanisms.

When the HA itself sends data to the mobile node, it behaves like a regular correspondent node, which means it does not use the tunnel, but inserts a Routing Header type 2, which carries the Home Address of the mobile node.

11.4.5. Mobile Node Operation

As long as the MN is at home, no Mobile IPv6 mechanisms are necessary. If the MN is away from home, it uses its home address as well as its care-of address. For each communication, it must choose which address to use. Applications and processes above the IP layer usually communicate using the home address of the MN.

If a communication has to survive a move of the MN to another network, the home address must be used. As soon as the MN has a communication with a correspondent node for which there is a Binding, the communication can be routed directly. If there is no Binding, all data will be tunneled through the home agent. For certain communications, the MN can also choose to use its care-of address without Mobile IPv6 functionality, just as a regular unicast address. When the MN communicates with local nodes in a foreign networke.g., for Neighbor Discoveryit should communicate directly and not use the Home Address Destination option.

The choice of the best communication path and the corresponding address depends on the requirements of the application, and that is where the choice has to be made. This definition is not part of the Mobile IPv6 specification.

11.4.5.1. Route Optimization in detail

When a mobile node away from home communicates with a correspondent node for which it has a Binding, it uses the process called Route Optimization.

The MN goes through the following steps: it checks its Binding Update List for an entry of its home address for this correspondent node. This verifies whether the correspondent node can process the Home Address Destination Option. Then, it checks the Binding Update List for the following:

  • Whether the Source Address it wants to use corresponds to the Home Address in the entry.

  • Whether the Destination address it wants to use corresponds to the address of the correspondent node in the entry.

  • Whether its current care-of address is listed as care-of address in this entry.

  • Whether the Binding is valid and the lifetime greater than zero.

If all these requirements are met, the mobile node knows that the correspondent node has a valid Binding Cache entry. A packet sent from the MN to this correspondent node contains the following information:

  • The Source address field in the IPv6 header contains the care-of address.

  • The packet carries a Destination Options header with a Home Address option containing the Home Address of the mobile node.

The correspondent node receiving this packet copies the home address from the Destinations Options header into the Source address field of the IPv6 header before processing the packet to upper layer protocols and applications. To the upper layers and the application, it looks as though the packet was sent from the home address of the mobile node. When the correspondent node wants to send data to a MN, it checks its Binding Cache for an entry for the destination. If there is such an entry, it inserts a Routing Header type 2.

When the correspondent node replies, address management looks as follows:

  • The Destination address in the IPv6 header contains the care-of address of the mobile node.

  • The packet contains a Routing Header type 2. The address field in the Routing Header contains the home address of the mobile node.

  • The mobile node exchanges the address in the Destination address field of the IPv6 header with the home address copied from the Routing Header, reduces the Segments Left field in the Routing Header by one to zero, and processes the packet internally to upper-layer protocols and applications. Again, to the upper layers, it looks as though the packet had been sent to the home address of the mobile node.

Figure 11-5 shows the communication between MN and the correspondent node, as well as the specific headers associated with Route Optimization.

Figure 11-5. Header information with Route Optimization


This figure illustrates the processes described previously. The main goal of Mobile IPv6 is for an MN to keep connectivity to services and applications while moving from one network to another. The goal of Route Optimization is to allow for direct routing between MN and the correspondent node. With the use of Destination options and Routing type 2 header, both nodes can process the packets internally as though they were in direct communication with the MN on its home link. So to the application, it looks as though the mobile node is on its home link.

This explains why Mobility with IPv6 is much more scalable and well-suited for widespread mobility. The Extension header architecture allows for Route Optimization. Imagine millions of mobile nodes communicating through their home agents to reach their correspondent nodes. The home agent would be a bottleneck, a single point of failure, and the home link unnecessarily overloaded. In many cases, the route from the mobile node to the correspondent node is much shorter than the route going through the home agent.

11.4.5.2. Communication with Bidirectional Tunneling

If the MN wants to communicate with a correspondent node for which it does not have a Binding, it uses the Reverse Tunneling mechanism. In this case, the packet is sent through the tunnel via the home agent. The Source address in the original packet carries the home address of the MN and the correspondent node's address as a destination address. This packet is encapsulated in another IPv6 header carrying the care-of address of the MN in the Source address field and the IPv6 address of the home agent in the Destination address field. The home agent processes the first header and forwards the original packet to the correspondent node. Figure 11-6 illustrates the header information.

Figure 11-6. Header information with Bidirectional Tunneling


11.4.5.3. Movement Detection

How does the MN detect that it has moved to another network? Movement Detection is based on the process of Neighbor Unreachability Detection (NUD; for details, see Chapter 4). Using NUD, the MN detects when its default router is no longer available. In this case, the MN tries to find a new default router. It performs Duplicate Address Detection (DAD) for its link-local addresses, chooses a new default router based on the Router Advertisements, and builds new care-of addresses based on the Router prefixes advertised. When the new addresses are initialized, it performs a Binding Update with its home agent first and then with all correspondent nodes for which it has Bindings.

The fact that new routers advertise new prefixes is not necessarily a sign that the MN is in a new network. There may be a new router or a prefix change in the current network. Procedures have to be defined to prevent an MN from unnecessarily updating all Bindings when it has not moved to another network. The following procedures have been defined so far:

  • If the MN receives RAs from new routers with new prefixes but its default router is still reachable, it will not perform any Binding Updates. It uses NUD to detect whether its default router is still available.

  • RAs can carry an Advertisement Interval Option. This allows the MN to detect whether this router is still available based on the comparison of the interval in different RAs.

  • If the default router does not reply to a Neighbor Solicitation, the MN should perform a Multicast Router Solicitation.

11.4.5.4. Returning home

When the MN detects that it is back on its home link, it sends a Binding Update to the home agent to inform it that it is back home and that the HA no longer needs to forward packets through the tunnel.

This Home Registration looks as follows:

  • The A-bit (Acknowledge) and the H-bit (Home Registration) must be set.

  • The Lifetime field is set to 0.

  • The care-of address must be the same as the home address.

  • The Source address in the IPv6 header must be the home address of the MN.



IPv6 Essentials
IPv6 Essentials
ISBN: 0596100582
EAN: 2147483647
Year: 2004
Pages: 156
Authors: Silvia Hagen

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net