Section 11.2. The Mobile IPv6 Protocol


11.2. The Mobile IPv6 Protocol

This section describes the components, messages, and options for Mobile IPv6.

11.2.1. Mobility Header and Mobility Messages

The 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.

Table 11-1. Mobility message types

Value

Message type

Description

0

Binding Refresh Request

Sent by CN requesting the MN to update its binding.

1

Home Test Init

Sent by the MN to initiate the Return Routability Procedure and request a Home Keygen token from a CN. Sent to the CN through the tunnel via HA.

2

Care-of Test Init

Sent by the MN to initiate the Return Routability Procedure and request a Keygen token from a CN. Sent to the CN directly.

3

Home Test Message

Response to a Home Test Init message (type 1). Sent from the CN to MN. Contains a cookie and a Home Keygen token for the authorization in the Return Routability Process. Sent through the tunnel via HA.

4

Care-of Test Message

Response to Care-of Test Init message (type 2). Sent from CN to MN. Contains cookie and a Care-of Keygen token for the authorization in the Return Routability Procedure. Sent to the MN directly.

5

Binding Update

Sent by MN to notify a change of its care-of address. This message is explained in more detail later in the chapter.

6

Binding Ack

Sent as acknowledgement for receipt of a Binding Update message. This message is explained in more detail later in the chapter.

7

Binding Error

Sent by CN to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding. The status field can have the following values:

1 = unkown binding for Home Address Destination option

2 = unrecognized MH type value

8

Fast Binding Update

Identical to binding update message, only with slightly different processing rules.

9

Fast Binding Ack

Sent as acknowledgement for receipt of a Fast Binding Update message.

10

Fast Neighbor Advertisement

Sent by mobile node to announce itself to its new access router.


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.

You can find all message and option types as well as status codes at http://www.iana.org/assignments/mobility-parameters.


11.2.2. The Binding Update Message

The 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:

  • Binding Authorization Data option (this option is mandatory in Binding Updates sent to a correspondent node)

  • Nonce Indices option

  • Alternate Care-of Address option

11.2.3. The Binding Acknowledgement

The 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.

Table 11-2. Status values in the Binding Acknowledgement

Value

Description

Defined in

0

Binding Update accepted

RFC 3775

1

Accepted but prefix discovery necessary

RFC 3775

128

Reason unspecified

RFC 3775

129

Administratively prohibited

RFC 3775

130

Insufficient resources

RFC 3775

131

Home Registration not supported

RFC 3775

132

Not home subnet

RFC 3775

133

Not home agent for this mobile node

RFC 3775

134

Duplicate Address Detection failed

RFC 3775

135

Sequence number out of window

RFC 3775

136

Expired home nonce index

RFC 3775

137

Expired care-of nonce index

RFC 3775

138

Expired nonces

RFC 3775

139

Registration type change disallowed

RFC 3775

140

Mobile Router Operation not permitted

RFC 3963

141

Invalid Prefix

RFC 3963

142

Not Authorized for Prefix

RFC 3963

143

Forwarding Setup failed

RFC 3963

144

MIPV6-ID-MISMATCH

RFC 4285

145

MIPV6-MESG-ID-REQD

RFC 4285

146

MIPV6-AUTH-FAIL

RFC 4285


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:

  • Binding Authorization Data option (this option is mandatory in Binding Acknowledgements sent by a correspondent node)

  • Binding Refresh Advice option

11.2.4. Mobility Options

A 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.

Table 11-3. Mobility options

Value Length

Name

Description

Defined in

Type 0

Pad1

Used to insert one padding Byte. This option has a special format; it contains only a type field, and no fields for length and data.

RFC 3775

Type 1

PadN

Used to insert two or more padding Bytes.

RFC 3775

Type 2 Length 2

Binding Refresh Advice

Indicates the remaining time until the MN should send a new home registration to HA. Only valid in Binding Acks sent from the HA in response to a home registration. The interval must be shorter than the lifetime value in the Binding Acknowledgement. A time unit is four seconds.

RFC 3775

Type 3 Length 16

Alternate Care-of address

Contains an address to use as the care-of address for the binding rather than using the Source address of the packet as the care-of address. Only in Binding Update messages.

RFC 3775

Type 4 Length 4

Nonce Indices

Has two additional fields besides the Type and Length field. The Home Nonce Index field tells the CN which nonce value to use when producing the Home Keygen Token. The Care-of Nonce field indicates the value for generating the Care-of Keygen Token. Valid only in the Binding Update message sent to a CN, and only when present together with a Binding Authorization Data option.

RFC 3775

Type 5 Length variable

Binding Authorization Data

Contains a cryptographic value that can be used to determine that the message in question comes from the right authority. Rules for calculating this value depend on the authorization procedure used. Must always be the last option in the MH. Only valid in Binding Update and Binding Acknowledgement. Used for the Return Routability process. In this case, the calculation of the Authenticator value is based on care-of address of MN, IPv6 address of CN, and data from the MH.

RFC 3775

Type 6

Mobile Network Prefix Option

Included in the Binding Update to indicate the prefix information for the Mobile Network to the HA.

RFC 3963

Type 7

Mobility Header Link-Layer Address option

Link-layer address option carried in an MH; used for Fast Handovers.

RFC 4068

Type 8

MN-ID-OPTION-TYPE

Optional suboption in the MH to specify the type of identifier used to identify the MN.

RFC 4283

Type 9

AUTH-OPTION-TYPE

When receiving a binding update, the HA must check the timestamp field. If it is invalid, it replies with a binding acknowledgment including this status code.

RFC 4285

Type 10

MESG-ID-OPTION-TYPE

Defines the type of mobility option.

RFC 4285

Type 201 Length 16

Home Address

Contains the home address of MN. Sent by MN when away from home to indicate its home address to the receiver. Carried in a Destination Options header. Must be inserted after Routing header and before Fragment, AH, or ESP header (if present).

RFC 3775


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 2

A 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.



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

Similar book on Amazon

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