Mobile IPv6 Messages and Options
Mobile IPv6 requires the use of the following messages and message options:
- A new Mobility extension header with a set of Mobile IPv6 messages
- A set of mobility options to include in mobility messages
- A new Home Address option for the Destination Options header
- A new Type 2 Routing header
- New Internet Control Message Protocol for IPv6 (ICMPv6) messages to discover the set of home agents and to obtain the prefix of the home link
- Changes to router discovery messages and options, and additional Neighbor Discovery options
Mobility Header and Messages
To facilitate the sending of messages between mobile nodes, correspondent nodes, and home agents for the purposes of managing the set of bindings between home addresses and care-of addresses, the Internet Engineering Task Force (IETF) has defined a new Mobility extension header. This new header can contain one of several defined mobility messages to perform specific functions. Some mobility messages can contain one or more options.
Mobility Header
The new Mobility extension header is dedicated to carrying mobility messages and has the structure shown in Figure below. Setting the previous header's Next Header field to the value of 135 identifies the Mobility extension header.
Within the Mobility extension header, you will find the following settings:
- The Payload Protocol field, equivalent to the Next Header field in the IPv6 header, is always set to the value of 59 to indicate that the Mobility header is the last header in the packet.
- The MH Type field identifies the specific type of mobility message.
- The Message Data field contains a mobility message.
The following types of mobility messages are defined:
- Binding Refresh Request:
Sent by a correspondent node or home agent to request the current binding from a mobile node. If a mobile node receives a binding refresh request, it responds with a binding update. A correspondent node sends a binding refresh request when a binding cache entry is in active use and the lifetime of the binding cache entry approaches expiration. A home agent sends a binding refresh request when the lifetime of its binding cache entry approaches expiration. - Home Test Init (HoTI):
Sent by the mobile node during the Return Routability procedure to test the indirect path from a mobile node to a correspondent node via the home agent. For more information, see the "Return Routability Procedure" section of this article. - Care-of Test Init (CoTI):
Sent by the mobile node during the Return Routability procedure to test the direct path from a mobile node to a correspondent node. - Home Test (HoT):
Sent by the correspondent node during the Return Routability procedure to respond to the HoTI message. - Care-of Test (CoT):
Sent by the correspondent node during the Return Routability procedure to respond to the CoTI message. - Binding Update Sent by a Mobile IPv6 node that is away from home to update another node with its new care-of address. The Binding Update option is used for the following:
- To update the home agent with a new primary care-of address. This is known as a home registration binding update. The home agent uses the home address in the Home Address option and the care-of address in an Alternate Care-of Address mobility option to update its Home Address/Primary Care-of Address binding cache entry for the mobile node.
- To update a Mobile IPv6-capable correspondent node with which the mobile node is actively communicating with a binding that maps the home address of the mobile node to its care-of address. This is known as a correspondent registration binding update. The correspondent node uses the home address in the Home Address option and the source address of the packet to update its Home Address/Care-of Address binding cache entry for the mobile node.
- Binding Acknowledgement:
Sent by a home agent or a correspondent node to acknowledge the receipt of a Binding Update message. Included in the binding acknowledgement is an indication of how long the node will cache the binding. For home agents, this lifetime indicates how long the home agent will be in service as the home agent for the mobile node. To refresh the binding, either the mobile node sends a new binding update or the correspondent nodes and home agent send Binding Refresh Request messages. The binding acknowledgement also includes an indication of how often the mobile node should send binding updates. - Binding Error:
Sent by a correspondent node to report errors in a binding update.
Mobility messages can contain mobility message options. RFC 3775 defines the following options:
- Pad1 Option:
Used to insert a single byte of padding - PadN Option:
Used to insert 2 or more bytes of padding - Binding Refresh Advice Option:
Used in a Binding Acknowledgement sent from a home agent to indicate how long before the mobile node should send a new home registration - Alternate Care-of Address Option:
Used to indicate the care-of address in the Binding Update message - Nonce Indices Option:
Used to indicate information needed to determine binding keys - Binding Authorization Data Option:
Used to contain cryptographic information from which the receiver can verify that the binding message originated from a node with which a Return Routability procedure has occurred
Type 2 Routing Header
Mobile IPv6-capable correspondent nodes use a new Type 2 Routing header when sending a packet directly to a mobile node that is away from home to indicate the mobile node's home address. Correspondent nodes set the Destination Address field in the IPv6 header to the mobile node's care-of address when performing direct delivery.
Figure below shows the structure of the new Type 2 Routing header.
During the processing of a packet with a Type 2 Routing header, the mobile node replaces the Destination Address field with the value in the Home Address field. The Home Address field in the Type 2 Routing header is the actual destination address of the mobile node to which the packet has been sent. (The care-of address stored in the Destination Address field of the IPv6 header is merely an intermediate delivery address.)
The Type 2 Routing header is different from the Type 0 Routing header defined in RFC 2460 in that it can store only a single address and is specified for use only with Mobile IPv6. The Type 0 Routing header can store multiple addresses and is processed by routers for generalized source routing. Using a different routing type allows firewalls to treat source-routed packets differently from packets sent directly by Mobile IPv6-capable correspondent nodes to mobile nodes that are away from home.
Home Address Option for the Destination Options Header
The Home Address option in the Destination Options extension header is used to indicate the home address of the mobile node. It is included in binding updates sent to home agents and packets sent directly to Mobile IPv6-capable correspondent nodes by a mobile node when it is away from home when a binding exists. When a mobile node sends a packet, the source address in the IPv6 header is set to the care-of address. If the source address in the IPv6 header were set to the home address, the router on the foreign link might discard the packet because the source address does not match the prefix of the link on which the mobile node is located. To help minimize Internet attacks in which the source address of attack packets is spoofed with an address that is not assigned to the attacking computer, peripheral routers can implement ingress filtering and silently discard packets that do not have topologically correct source addresses. Ingress in this instance is defined relative to the Internet for packets entering the Internet, rather than packets entering an intranet from the Internet.
Figure below shows the structure of the Home Address destination option.
By using the care-of address as the source address in the packet (a topologically correct address on the foreign link) and including the Home Address destination option, the router on the foreign link forwards the packet to its destination. When the packet is received at the destination, the correspondent node processes the Destination Options header and logically replaces the source address of the packet with the address in the Home Address option before passing the payload to the upper-layer protocol. To the upper-layer protocol, the packet was sent from the home address.
In contrast to the Home Address field in the Type 2 Routing header, the Home Address field in the Home Address destination option is the actual source address of the mobile node from which the packet was sent. (The care-of address stored in the Source Address of the IPv6 header is merely an intermediate address.)
The Home Address option is also included with the binding update so that the home address for the binding is indicated to the receiving node.
ICMPv6 Messages for Mobile IPv6
The mobile node uses the following ICMPv6 messages for dynamic home agent address and home subnet prefix discovery:
- Home Agent Address Discovery Request
- Home Agent Address Discovery Reply
- Mobile Prefix Solicitation
- Mobile Prefix Advertisement
Dynamic home agent address discovery is a process by which the mobile node dynamically discovers the global address of a home agent on the home link. This process is needed only if the mobile node is not already configured with the address of its home agent or if the current home agent becomes unavailable.
Home subnet prefix discovery is the process by which a mobile node dynamically discovers the address prefix of its home link. This process is needed only when a mobile node's home address is about to enter the invalid state.
Home Agent Address Discovery Request
The mobile node uses the ICMPv6 Home Agent Address Discovery Request message to begin dynamic home agent address discovery. The ICMPv6 Home Agent Address Discovery Request message is sent to the Mobile IPv6 Home-Agents anycast address that is described in RFC 2526. The Mobile IPv6 Home-Agents anycast is composed of the 64-bit home subnet prefix and the interface ID of ::FEFF:FFFF:FFFF:FFFE. All home agents are automatically configured with this anycast address. The home agent that is topologically closest to the mobile node receives the request message.
Figure below shows the structure of the ICMPv6 Home Agent Address Discovery Request message.
In the Home Agent Address Discovery Request message, the Type field is set to 150 and the Code field is set to 0. Following the Checksum field is a 16-bit Identifier field. The value of the Identifier field is chosen by the sending node, and it is copied to the Identifier field of the Home Agent Address Discovery Reply message to match a reply with its request. Following the Identifier field is a 16-bit Reserved field that is set to 0 by the sender.
The Home Agent Address Discovery Request message is sent with the source address in the IPv6 header set to the mobile node's care-of address.
Home Agent Address Discovery Reply
The home agent uses the ICMPv6 Home Agent Address Discovery Reply message to complete the dynamic home agent address discovery process by informing the mobile node of the addresses of the home agents on the mobile node's home link.
Figure below shows the structure of the ICMPv6 Home Agent Address Discovery Reply message.
In the Home Agent Address Discovery Reply message, the Type field is set to 151 and the Code field is set to 0. Following the Checksum field is a 16-bit Identifier field. The value of the Identifier field is set to the same value as the Identifier field of the received Home Agent Address Discovery Request message. Following the Identifier field is a 16-bit Reserved field that is set to 0 by the sender, and one or more 128-bit Home Agent Address fields. The Home Agent Address fields contain the global addresses of home agents on the home link in preference order (highest preference first).
The Home Agent Address Discovery Reply message is sent with the source address in the IPv6 header set to the global address of the answering home agent, and with the destination address set to the mobile node's care-of address. A Type 2 Routing extension header is not included.
Mobile Prefix Solicitation
A mobile node uses the ICMPv6 Mobile Prefix Solicitation message to obtain its home subnet prefix while it is away from home. The response to the ICMPv6 Mobile Prefix Solicitation message is an ICMPv6 Mobile Prefix Advertisement message from the home agent, which contains the home subnet prefix and other configuration information by which the mobile node can update or refresh its home address.
Figure below shows the structure of the ICMPv6 Mobile Prefix Solicitation message.
The Identifier field is set by the mobile node and used to match a sent Mobile Prefix Solicitation message with its corresponding Mobile Prefix Advertisement message.
Mobile Prefix Advertisement
The home agent uses the ICMPv6 Mobile Prefix Advertisement message to advertise the home subnet prefix and other configuration options to mobile nodes that are away from home, either unsolicited or in response to a received ICMPv6 Mobile Prefix Solicitation message Figure below shows the structure of the ICMPv6 Mobile Prefix Advertisement message.
The Identifier field is set to the value of the Identifier field of a received Mobile Prefix Solicitation message. The Managed Address Configuration, Other Stateful Configuration, and Options fields are the same as the corresponding fields of the Router Advertisement message as defined in RFC 4861, except that RFC 3775 defines the use of the Mobile IPv6-modified Prefix Information option, described in the next section.
