Section 11.2. The Mobile IPv6 Protocol
11.2. The Mobile IPv6 ProtocolThis section describes the components, messages, and options for Mobile IPv6. 11.2.1. Mobility Header and Mobility MessagesThe Mobility Header (MH) has been defined for Mobile IPv6. It is an Extension header used by mobile node, correspondent node, and home agent. It is used in all messages that are related to establishing and maintaining bindings. A Mobility Header is specified by the Next Header value 135 in the preceding header and has the format shown in Figure 11-2. Figure 11-2. Format of the Mobility Header (MH) The Payload Proto field corresponds to the Next Header field and identifies the following header. It can therefore contain the same values. The current specification sets the value in this field to 59 decimal, which means "no next header". It is designed to be used for future extensions. The Header Length field contains the length of the Mobility header in 8-byte units. The first 8 bytes are not counted. The length of the Mobility header is always a multiple of 8 bytes. The Checksum field contains the checksum for the Mobility header. It is calculated based on a pseudoheader and follows the rules defined in RFC 2460. The addresses used in the pseudoheader are the source and destination address in the IPv6 header. If the Mobility message contains a Home Address Destination option, the home address is used for the calculation of the checksum. The MH Type field identifies the type of Mobility message. The messages defined are listed in Table 11-1. The Data field is variable; it depends on the type of message. Table 11-1 is an overview of the Mobility messages.
Values 8, 9, and 10 have been assigned in RFC 4068, "Fast Handovers for Mobile IPv6." This RFC specifies a protocol to improve handover latency due to Mobile IPv6 procedures. To help you understand the binding, the next section explores the Binding Update and the Binding Acknowledgement messages in more detail.
11.2.2. The Binding Update MessageThe Binding Update message is used by the mobile node to inform the home agent or a correspondent node about a new care-of address. The message is also used to extend the lifetime of an existing binding. The Binding Update message is of MH type 5 and has the format shown in Figure 11-3. Figure 11-3. Format of the Binding Update message The Sequence Number is used by the receiving node for sequencing Binding Updates. The sending node uses it to verify whether the Binding Acknowledgements received correspond to its Binding Updates. The Acknowledge bit (A-bit) is set by the mobile node if it expects an acknowledgement in answer to its Binding Update. The Home Registration bit (H-bit) is set by the mobile node to request the receiver to act as home agent for this node. This is possible only if the receiver is on the home link of the mobile node. The Link-Local Address Compatibility bit (L-bit) is set if the home address has the same Interface Identifier as the link-local address of the mobile node. The Key Management Mobility Capability bit (K-bit) is valid only in Binding Updates sent to the home agent. IPsec Security Associations should survive the move of the mobile node to another network. If that is the case, the K-bit is set. If that is not possible, the K-bit is set to 0. Correspondent nodes ignore the K-bit. The Lifetime shows in four-second units for how long the binding for the care-of address is valid. If the Lifetime is set to 0, the receiver must delete the entry in its Binding Cache. In this case, the mobile node must be on its home link, and the care-of address is the same as the home address. The M-bit shown in Figure 11-3 has additionally been created to identify Local Binding Updates sent to a local Home Agent called a Mobility Anchor Point (MAP). This new node is used to improve Mobile IPv6 handover performance, to obtain efficient routing between the mobile node and correspondent nodes within the same geographical area, and to achieve location privacy. The mechanism is defined in RFC 4140, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)," and is explained in more detail at the end of this chapter. When the M-bit is set, the H-bit cannot be set and vice versa. A Binding Update can have the following options:
11.2.3. The Binding AcknowledgementThe Binding Acknowledgement is sent to confirm receipt of a Binding Update. It has to be sent if the A-bit is set in the Binding Update. If the A-bit is not set (which means the sender of the Binding Update does not require an acknowledgment), the Binding Acknowledgement is sent only if there is a problem in the Binding Update. If the receiver accepts the Binding Update and the A-bit was not set, no acknowledgment is sent. The Binding Acknowledgement is of MH type 6 and has the format shown in Figure 11-4. Figure 11-4. Format of the Binding Acknowledgement The status field indicates the status of the Binding Update. Table 11-2 shows the status values. Values in the range of 0 to 127 indicate that the Binding Update has been accepted. Values above 128 indicate that the Binding Update has not been accepted.
The K-bit is the Key Management Mobility Capability bit (see the description earlier in "The Binding Update Message"). This bit is of importance only in bindings between mobile node and home agent. Correspondent nodes ignore this bit. The Sequence Number in the Binding Acknowledgement is copied from the Sequence Number field in the Binding Update. It is used by the mobile node in matching this Binding Acknowledgement with an outstanding Binding Update. The Lifetime shows in 4-second units for how long the binding for the care-of address is valid. During the time indicated here, either the home agent or the correspondent node keeps the entry for this binding in its Binding Cache. In a Binding Acknowledgement that indicates that the Binding has not been accepted (value of 128 or higher), the Lifetime is not specified. A Binding Acknowledgement can have the following options:
11.2.4. Mobility OptionsA mobility message can contain zero, one, or more options. These options are included in the variable data field of the mobility header. This architecture is very flexible, as options are inserted only if needed and additional options can easily be defined in the future. The presence of options is indicated in the header length field of the mobility header. They have the known TLV format (Type 1 Byte, Length 1 Byte, Value variable). Table 11-3 contains an overview of the currently defined options for mobility messages.
With the exception of the Binding Authorization Data option, these options can appear in arbitrary order. The Home Address option is an exception, as it is carried in a Destination Options header and not in the Mobility Header (MH). RFC 4283, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)," extends the original specification to allow MIPv6 nodes (HA, CN, MN) to use identifiers other than an IP address. It defines an option with a subtype number to specify the identifier type. The identifier type can be a Network Access Identifier (NAI; see RFC 4282), an International Mobile Station Identifier (IMSI), or an application/deployment specific opaque identifier. Additional identifier types will be specified in the future. 11.2.5. Routing Header Type 2A new Routing header has been defined for Mobile IPv6. This Extension header allows the data exchange between the care-of address of a mobile node and a correspondent node without being routed through the home agent. In other words, it is used when communication is performed with route optimization after a successful return routability procedure. In addition to the Type 0 Routing Extension header described in Chapter 2, RFC 3775 defines the Type 2 Routing header. It allows, among other things, the configuration of specific rules for Mobile IPv6 packets on firewalls. When a correspondent node sends an IPv6 datagram to a mobile node using route optimization, the Destination Address field in the IPv6 header contains the care-of address of the mobile node. The Routing Header Type 2 inserted contains the home address of the mobile node. The Routing Header Type 2 can only contain one unicast address. IPv6 nodes that process these Routing headers must verify that the IPv6 address contained corresponds to the home address of the mobile node. The format of the Routing Header Type 2 corresponds to the Routing Header Type 0 shown in Chapter 2 (Figure 2-5). The Header Extension Length field has the value 2; this header does not have a variable length, as it only contains one address. In the Routing Type field, the value 2 is indicated, and the Segments Left field is set to 1 for one address. The Home Address field carries the home address of the mobile node. If an IPv6 datagram carries two Routing Headers, the Type 0 routing header must be first, followed by the Type 2 routing header. How this Routing Header Type 2 is used and processed is described later in this chapter. |
