RFC 6275
Mobility Support in IPv6
6. New IPv6 Protocol, Message Types, and Destination Option
6.1. Mobility Header
The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. The subsections within this section describe the message types that may be sent using the Mobility Header. Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section 9.5.4 for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Sections 11.7.1 and 11.7.2 for Binding Update. Binding Update List or Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass both the Binding Cache check described in Section 9.3.2 and the Binding Update List check described in Section 11.3.1 that are normally performed for all packets. This applies even to messages sent to or from a correspondent node that is itself a mobile node.6.1.1. Format
The Mobility Header is identified by a Next Header value of 135 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . Message Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Proto
8-bit selector. Identifies the type of header immediately
following the Mobility Header. Uses the same values as the IPv6
Next Header field [6].
This field is intended to be used by a future extension (see
Appendix A.1).
Implementations conforming to this specification SHOULD set the
payload protocol type to IPPROTO_NONE (59 decimal).
Header Len
8-bit unsigned integer, representing the length of the Mobility
Header in units of 8 octets, excluding the first 8 octets.
The length of the Mobility Header MUST be a multiple of 8 octets.
MH Type
8-bit selector. Identifies the particular mobility message in
question. Current values are specified in Section 6.1.2 and
onward. An unrecognized MH Type field causes an error indication
to be sent.
Reserved
8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Checksum
16-bit unsigned integer. This field contains the checksum of the
Mobility Header. The checksum is calculated from the octet string
consisting of a "pseudo-header" followed by the entire Mobility
Header starting with the Payload Proto field. The checksum is the
16-bit one's complement of the one's complement sum of this
string.
The pseudo-header contains IPv6 header fields, as specified in
Section 8.1 of RFC 2460 [6]. The Next Header value used in the
pseudo-header is 135. The addresses used in the pseudo-header are
the addresses that appear in the Source and Destination Address
fields in the IPv6 packet carrying the Mobility Header.
Note that the procedures of calculating upper-layer checksums
while away from home described in Section 11.3.1 apply even for
the Mobility Header. If a mobility message has a Home Address
destination option, then the checksum calculation uses the home
address in this option as the value of the IPv6 Source Address
field. The type 2 routing header is treated as explained in [6].
The Mobility Header is considered as the upper-layer protocol for
the purposes of calculating the pseudo-header. The Upper-Layer
Packet Length field in the pseudo-header MUST be set to the total
length of the Mobility Header.
For computing the checksum, the checksum field is set to zero.
Message Data
A variable-length field containing the data specific to the
indicated Mobility Header type.
Mobile IPv6 also defines a number of "mobility options" for use
within these messages; if included, any options MUST appear after the
fixed portion of the message data specified in this document. The
presence of such options will be indicated by the Header Len field
within the message. When the Header Len value is greater than the
length required for the message specified here, the remaining octets
are interpreted as mobility options. These options include padding
options that can be used to ensure that other options are aligned
properly, and that the total length of the message is divisible by 8.
The encoding and format of defined options are described in
Section 6.2.
Alignment requirements for the Mobility Header are the same as for
any IPv6 protocol header. That is, they MUST be aligned on an
8-octet boundary.
6.1.2. Binding Refresh Request Message
The Binding Refresh Request (BRR) message requests a mobile node to
update its mobility binding. This message is sent by correspondent
nodes according to the rules in Section 9.5.5. When a mobile node
receives a packet containing a Binding Refresh Request message it
processes the message according to the rules in Section 11.7.4.
The Binding Refresh Request message uses the MH Type value 0. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2. The
receiver MUST ignore and skip any options that it does not
understand.
There MAY be additional information, associated with this Binding
Refresh Request message that need not be present in all Binding
Refresh Request messages sent. Mobility options allow future
extensions to the format of the Binding Refresh Request message to
be defined. This specification does not define any options valid
for the Binding Refresh Request message.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 0.
6.1.3. Home Test Init Message
A mobile node uses the Home Test Init (HoTI) message to initiate the
return routability procedure and request a home keygen token from a
correspondent node (see Section 11.6.1). The Home Test Init message
uses the MH Type value 1. When this value is indicated in the MH
Type field, the format of the Message Data field in the Mobility
Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. This value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Home Init Cookie
64-bit field that contains a random value, the home init cookie.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options that it does not understand.
This specification does not define any options valid for the Home
Test Init message.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 1.
This message is tunneled through the home agent when the mobile node
is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel
mode between the home agent and the mobile node. This protection is
indicated by the IPsec security policy database. The protection of
Home Test Init messages is unrelated to the requirement to protect
regular payload traffic, which MAY use such tunnels as well.
6.1.4. Care-of Test Init Message
A mobile node uses the Care-of Test Init (CoTI) message to initiate
the return routability procedure and request a care-of keygen token
from a correspondent node (see Section 11.6.1). The Care-of Test
Init message uses the MH Type value 2. When this value is indicated
in the MH Type field, the format of the Message Data field in the
Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Care-of Init Cookie
64-bit field that contains a random value, the care-of init
cookie.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options that it does not understand.
This specification does not define any options valid for the
Care-of Test Init message.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 1.
6.1.5. Home Test Message
The Home Test (HoT) message is a response to the Home Test Init
message, and is sent from the correspondent node to the mobile node
(see Section 5.2.5). The Home Test message uses the MH Type value 3.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Nonce Index
This field will be echoed back by the mobile node to the
correspondent node in a subsequent Binding Update.
Home Init Cookie
64-bit field that contains the home init cookie.
Home Keygen Token
This field contains the 64-bit home keygen token used in the
return routability procedure.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options that it does not understand.
This specification does not define any options valid for the Home
Test message.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 2.
6.1.6. Care-of Test Message
The Care-of Test (CoT) message is a response to the Care-of Test Init message, and is sent from the correspondent node to the mobile node (see Section 11.6.2). The Care-of Test message uses the MH Type value 4. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Care-of Nonce Index This value will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update. Care-of Init Cookie 64-bit field that contains the care-of init cookie. Care-of Keygen Token This field contains the 64-bit care-of keygen token used in the return routability procedure. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options that it does not understand.
This specification does not define any options valid for the
Care-of Test message.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 2.
6.1.7. Binding Update Message
The Binding Update (BU) message is used by a mobile node to notify
other nodes of a new care-of address for itself. Binding Updates are
sent as described in Sections 11.7.1 and 11.7.2.
The Binding Update uses the MH Type value 5. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobile node to
request a Binding Acknowledgement (Section 6.1.8) be returned upon
receipt of the Binding Update.
Home Registration (H)
The Home Registration (H) bit is set by the sending mobile node to
request that the receiving node should act as this node's home
agent. The destination of the packet carrying this message MUST
be that of a router sharing the same subnet prefix as the home
address of the mobile node in the binding.
Link-Local Address Compatibility (L)
The Link-Local Address Compatibility (L) bit is set when the home
address reported by the mobile node has the same interface
identifier as the mobile node's link-local address.
Key Management Mobility Capability (K)
If this bit is cleared, the protocol used for establishing the
IPsec security associations between the mobile node and the home
agent does not survive movements. It may then have to be rerun.
(Note that the IPsec security associations themselves are expected
to survive movements.) If manual IPsec configuration is used, the
bit MUST be cleared.
This bit is valid only in Binding Updates sent to the home agent,
and MUST be cleared in other Binding Updates. Correspondent nodes
MUST ignore this bit.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Sequence #
A 16-bit unsigned integer used by the receiving node to sequence
Binding Updates and by the sending node to match a returned
Binding Acknowledgement with this Binding Update.
Lifetime
16-bit unsigned integer. The number of time units remaining
before the binding MUST be considered expired. A value of zero
indicates that the Binding Cache entry for the mobile node MUST be
deleted. One time unit is 4 seconds.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2. The
receiver MUST ignore and skip any options that it does not
understand.
The following options are valid in a Binding Update:
* Binding Authorization Data option (this option is mandatory in
Binding Updates sent to a correspondent node)
* Nonce Indices option
* Alternate Care-of Address option
If no options are present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1. The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. The care-of address MUST be a unicast routable address. IPv6 Source Address MUST be a topologically correct source address. Binding Updates for a care-of address that is not a unicast routable address MUST be silently discarded. The deletion of a binding MUST be indicated by setting the Lifetime field to 0. In deletion, the generation of the binding management key depends exclusively on the home keygen token, as explained in Section 5.2.5. Correspondent nodes SHOULD NOT delete the Binding Cache entry before the lifetime expires, if any application hosted by the correspondent node is still likely to require communication with the mobile node. A Binding Cache entry that is de-allocated prematurely might cause subsequent packets to be dropped from the mobile node, if they contain the Home Address destination option. This situation is recoverable, since a Binding Error message is sent to the mobile node (see Section 6.1.9); however, it causes unnecessary delay in the communications.6.1.8. Binding Acknowledgement Message
The Binding Acknowledgement is used to acknowledge receipt of a Binding Update (Section 6.1.7). This packet is sent as described in Sections 9.5.4 and 10.3.1. The Binding Acknowledgement has the MH Type value 6. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
8-bit unsigned integer indicating the disposition of the Binding
Update. Values of the Status field less than 128 indicate that
the Binding Update was accepted by the receiving node. Values
greater than or equal to 128 indicate that the Binding Update was
rejected by the receiving node. The following Status values are
currently defined:
0 Binding Update accepted
1 Accepted but prefix discovery necessary
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Home registration not supported
132 Not home subnet
133 Not home agent for this mobile node
134 Duplicate Address Detection failed
135 Sequence number out of window
136 Expired home nonce index
137 Expired care-of nonce index
138 Expired nonces
139 Registration type change disallowed
174 Invalid Care-of Address
Up-to-date values of the Status field are to be specified in the
IANA registry of assigned numbers [30].
Key Management Mobility Capability (K)
If this bit is cleared, the protocol used by the home agent for
establishing the IPsec security associations between the mobile
node and the home agent does not survive movements. It may then
have to be rerun. (Note that the IPsec security associations
themselves are expected to survive movements.)
Correspondent nodes MUST set the K bit to 0.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Sequence #
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.
Lifetime
The granted lifetime, in time units of 4 seconds, for which this
node SHOULD retain the entry for this mobile node in its Binding
Cache.
The value of this field is undefined if the Status field indicates
that the Binding Update was rejected.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2. The
receiver MUST ignore and skip any options that it does not
understand.
There MAY be additional information associated with this Binding
Acknowledgement that need not be present in all Binding
Acknowledgements sent. Mobility options allow future extensions
to the format of the Binding Acknowledgement to be defined. The
following options are valid for the Binding Acknowledgement:
* Binding Authorization Data option (this option is mandatory in
Binding Acknowledgements sent by a correspondent node, except
where otherwise noted in Section 9.5.4)
* Binding Refresh Advice option
If no options are present in this message, 4 octets of padding are
necessary and the Header Len field will be set to 1.
6.1.9. Binding Error Message
The Binding Error (BE) message is used by the correspondent node to
signal an error related to mobility, such as an inappropriate attempt
to use the Home Address destination option without an existing
binding; see Section 9.3.3 for details.
The Binding Error message uses the MH Type value 7. When this value
is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
8-bit unsigned integer indicating the reason for this message.
The following values are currently defined:
1 Unknown binding for Home Address destination option
2 Unrecognized MH Type value
Reserved
8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Home Address
The home address that was contained in the Home Address
destination option. The mobile node uses this information to
determine which binding does not exist, in cases where the mobile
node has several home addresses.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options that it does not understand.
There MAY be additional information associated with this Binding
Error message that need not be present in all Binding Error
messages sent. Mobility options allow future extensions to the
format of the Binding Error message to be defined. The encoding
and format of defined options are described in Section 6.2. This
specification does not define any options valid for the Binding
Error message.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 2.
6.2. Mobility Options
Mobility messages can include zero or more mobility options. This
allows optional fields that may not be needed in every use of a
particular Mobility Header, as well as future extensions to the
format of the messages. Such options are included in the Message
Data field of the message itself, after the fixed portion of the
message data specified in the message subsections of Section 6.1.
The presence of such options will be indicated by the Header Len of
the Mobility Header. If included, the Binding Authorization Data
option (Section 6.2.7) MUST be the last option and MUST NOT have
trailing padding. Otherwise, options can be placed in any order.
6.2.1. Format
Mobility options are encoded within the remaining space of the Message Data field of a mobility message, using a type-length-value (TLV) format as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Option Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit identifier of the type of mobility option. When processing a Mobility Header containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST quietly ignore and skip over the option, correctly handling any remaining options in the message. Option Length 8-bit unsigned integer, representing the length in octets of the mobility option, not including the Option Type and Option Length fields. Option Data A variable-length field that contains data specific to the option. The following subsections specify the Option types that are currently defined for use in the Mobility Header. Implementations MUST silently ignore any mobility options that they do not understand. Mobility options may have alignment requirements. Following the convention in IPv6, these options are aligned in a packet so that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8) [6].6.2.2. Pad1
The Pad1 option does not have any alignment requirements. Its format is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 option is a special case -- it has
neither Option Length nor Option Data fields.
The Pad1 option is used to insert one octet of padding in the
Mobility Options area of a Mobility Header. If more than one octet
of padding is required, the PadN option, described next, should be
used rather than multiple Pad1 options.
6.2.3. PadN
The PadN option does not have any alignment requirements. Its format
is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Type = 1 | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN option is used to insert two or more octets of padding in
the Mobility Options area of a mobility message. For N octets of
padding, the Option Length field contains the value N-2, and the
Option Data consists of N-2 zero-valued octets. PadN Option data
MUST be ignored by the receiver.
6.2.4. Binding Refresh Advice
The Binding Refresh Advice option has an alignment requirement of 2n.
Its format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Refresh Advice option is only valid in the Binding
Acknowledgement, and only on Binding Acknowledgements sent from the
mobile node's home agent in reply to a home registration. The
Refresh Interval is measured in units of four seconds, and indicates
remaining time until the mobile node SHOULD send a new home registration to the home agent. The Refresh Interval MUST be set to indicate a smaller time interval than the Lifetime value of the Binding Acknowledgement.6.2.5. Alternate Care-of Address
The Alternate Care-of Address option has an alignment requirement of 8n + 6. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Normally, a Binding Update specifies the desired care-of address in the Source Address field of the IPv6 header. However, this is not possible in some cases, such as when the mobile node wishes to indicate a care-of address that it cannot use as a topologically correct source address (Sections 6.1.7 and 11.7.2) or when the used security mechanism does not protect the IPv6 header (Section 11.7.1). The Alternate Care-of Address option is provided for these situations. This option is valid only in Binding Update. The Alternate Care-of Address field 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.
6.2.6. Nonce Indices
The Nonce Indices option has an alignment requirement of 2n. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Nonce Indices option is valid only in the Binding Update message sent to a correspondent node, and only when present together with a Binding Authorization Data option. When the correspondent node authorizes the Binding Update, it needs to produce home and care-of keygen tokens from its stored random nonce values. The Home Nonce Index field tells the correspondent node which nonce value to use when producing the home keygen token. The Care-of Nonce Index field is ignored in requests to delete a binding. Otherwise, it tells the correspondent node which nonce value to use when producing the care-of keygen token.6.2.7. Binding Authorization Data
The Binding Authorization Data option does not have alignment requirements as such. However, since this option must be the last mobility option, an implicit alignment requirement is 8n + 2. The format of this option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Binding Authorization Data option is valid in the Binding Update and Binding Acknowledgement.
The Option Length field contains the length of the authenticator in
octets.
The Authenticator field 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 depends on the used
authorization procedure.
For the return routability procedure, this option can appear in the
Binding Update and Binding Acknowledgements. Rules for calculating
the Authenticator value are the following:
Mobility Data = care-of address | correspondent | MH Data
Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
Where | denotes concatenation. "Care-of address" is the care-of
address that will be registered for the mobile node if the Binding
Update succeeds, or the home address of the mobile node if this
option is used in de-registration. Note also that this address might
be different from the source address of the Binding Update message,
if the Alternative Care-of Address mobility option is used, or when
the lifetime of the binding is set to zero.
The "correspondent" is the IPv6 address of the correspondent node.
Note that, if the message is sent to a destination that is itself
mobile, the "correspondent" address may not be the address found in
the Destination Address field of the IPv6 header; instead, the home
address from the type 2 Routing header should be used.
"MH Data" is the content of the Mobility Header, excluding the
Authenticator field itself. The Authenticator value is calculated as
if the Checksum field in the Mobility Header was zero. The Checksum
in the transmitted packet is still calculated in the usual manner,
with the calculated Authenticator being a part of the packet
protected by the Checksum. Kbm is the binding management key, which
is typically created using nonces provided by the correspondent node
(see Section 9.4). Note that while the contents of a potential Home
Address destination option are not covered in this formula, the rules
for the calculation of the Kbm do take the home address in account.
This ensures that the MAC will be different for different home
addresses.
The first 96 bits from the MAC result are used as the Authenticator
field.
6.3. Home Address Option
The Home Address option is carried by the Destination Option extension header (Next Header value = 60). It is used in a packet sent by a mobile node while away from home, to inform the recipient of the mobile node's home address. The Home Address option is encoded in type-length-value (TLV) format as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 201 = 0xC9 Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Home Address The home address of the mobile node sending the packet. This address MUST be a unicast routable address. The alignment requirement [6] for the Home Address option is 8n + 6. The three highest-order bits of the Option Type field are encoded to indicate specific processing of the option [6]; for the Home Address option, these three bits are set to 110. This indicates the following processing requirements:
o Any IPv6 node that does not recognize the Option Type must discard
the packet, and if the packet's Destination Address was not a
multicast address, return an ICMP Parameter Problem, Code 2,
message to the packet's Source Address. The Pointer field in the
ICMP message SHOULD point at the Option Type field. Otherwise,
for multicast addresses, the ICMP message MUST NOT be sent.
o The data within the option cannot change en route to the packet's
final destination.
The Home Address option MUST be placed as follows:
o After the routing header, if that header is present
o Before the Fragment Header, if that header is present
o Before the AH Header or ESP Header, if either one of those headers
is present
For each IPv6 packet header, the Home Address option MUST NOT appear
more than once. However, an encapsulated packet [7] MAY contain a
separate Home Address option associated with each encapsulating IP
header.
The inclusion of a Home Address destination option in a packet
affects the receiving node's processing of only this single packet.
No state is created or modified in the receiving node as a result of
receiving a Home Address option in a packet. In particular, the
presence of a Home Address option in a received packet MUST NOT alter
the contents of the receiver's Binding Cache and MUST NOT cause any
changes in the routing of subsequent packets sent by this receiving
node.
6.4. Type 2 Routing Header
Mobile IPv6 defines a new routing header variant, the type 2 routing
header, to allow the packet to be routed directly from a
correspondent to the mobile node's care-of address. The mobile
node's care-of address is inserted into the IPv6 Destination Address
field. Once the packet arrives at the care-of address, the mobile
node retrieves its home address from the routing header, and this is
used as the final destination address for the packet.
The new routing header uses a different type than defined for
"regular" IPv6 source routing, enabling firewalls to apply different
rules to source routed packets than to Mobile IPv6. This routing
header type (type 2) is restricted to carry only one IPv6 address.
All IPv6 nodes that process this routing header MUST verify that the
address contained within is the node's own home address in order to prevent packets from being forwarded outside the node. The IP address contained in the routing header, since it is the mobile node's home address, MUST be a unicast routable address. Furthermore, if the scope of the home address is smaller than the scope of the care-of address, the mobile node MUST discard the packet (see Section 4.6).6.4.1. Format
The type 2 routing header has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the routing header. Uses the same values as the IPv6 Next Header field [6]. Hdr Ext Len 2 (8-bit unsigned integer); length of the routing header in 8-octet units, not including the first 8 octets. Routing Type 2 (8-bit unsigned integer). Segments Left 1 (8-bit unsigned integer).
Reserved
32-bit reserved field. The value MUST be initialized to zero by
the sender, and MUST be ignored by the receiver.
Home Address
The home address of the destination mobile node.
For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments
Left value describes the number of route segments remaining, i.e.,
number of explicitly listed intermediate nodes still to be visited
before reaching the final destination. Segments Left MUST be 1. The
ordering rules for extension headers in an IPv6 packet are described
in Section 4.1 of RFC 2460 [6]. The type 2 routing header defined
for Mobile IPv6 follows the same ordering as other routing headers.
If another routing header is present along with a type 2 routing
header, the type 2 routing header should follow the other routing
header. A packet containing such nested encapsulation should be
created as if the inner (type 2) routing header was constructed first
and then treated as an original packet by header construction process
for the other routing header.
In addition, the general procedures defined by IPv6 for routing
headers suggest that a received routing header MAY be automatically
"reversed" to construct a routing header for use in any response
packets sent by upper-layer protocols, if the received packet is
authenticated [6]. This MUST NOT be done automatically for type 2
routing headers.
6.5. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is used by a
mobile node to initiate the dynamic home agent address discovery
mechanism, as described in Section 11.4.1. The mobile node sends the
Home Agent Address Discovery Request message to the Mobile IPv6 Home-
Agents anycast address [8] for its own home subnet prefix. (Note
that the currently defined anycast addresses may not work with all
prefix lengths other than those defined in RFC 4291 [16] [37].)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
144
Code
0
Checksum
The ICMP checksum [17].
Identifier
An identifier to aid in matching Home Agent Address Discovery
Reply messages to this Home Agent Address Discovery Request
message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
The Source Address of the Home Agent Address Discovery Request
message packet is typically one of the mobile node's current care-of
addresses. At the time of performing this dynamic home agent address
discovery procedure, it is likely that the mobile node is not
registered with any home agent. Therefore, neither the nature of the
address nor the identity of the mobile node can be established at
this time. The home agent MUST then return the Home Agent Address
Discovery Reply message directly to the Source Address chosen by the
mobile node.
6.6. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is used by a home
agent to respond to a mobile node that uses the dynamic home agent
address discovery mechanism, as described in Section 10.5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
145
Code
0
Checksum
The ICMP checksum [17].
Identifier
The identifier from the invoking Home Agent Address Discovery
Request message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Agent Addresses
A list of addresses of home agents on the home link for the mobile
node. The number of addresses presented in the list is indicated
by the remaining length of the IPv6 packet carrying the Home Agent
Address Discovery Reply message.
6.7. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation message is sent by a mobile node to its home agent while it is away from home. The purpose of the message is to solicit a Mobile Prefix Advertisement from the home agent, which will allow the mobile node to gather prefix information about its home network. This information can be used to configure and update home address(es) according to changes in prefix information supplied by the home agent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address The mobile node's care-of address. Destination Address The address of the mobile node's home agent. This home agent must be on the link that the mobile node wishes to learn prefix information about. Hop Limit Set to an initial hop limit value, similarly to any other unicast packet sent by the mobile node. Destination Option: A Home Address destination option MUST be included. ESP header: IPsec headers MUST be supported and SHOULD be used as described in Section 5.4. ICMP Fields:
Type
146
Code
0
Checksum
The ICMP checksum [17].
Identifier
An identifier to aid in matching a future Mobile Prefix
Advertisement to this Mobile Prefix Solicitation.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
The Mobile Prefix Solicitation messages may have options. These
options MUST use the option format defined in Neighbor Discovery (RFC
4861 [18]). This document does not define any option types for the
Mobile Prefix Solicitation message, but future documents may define
new options. Home agents MUST silently ignore any options they do
not recognize and continue processing the message.
6.8. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement to a mobile node
to distribute prefix information about the home link while the mobile
node is traveling away from the home network. This will occur in
response to a Mobile Prefix Solicitation with an Advertisement, or by
an unsolicited Advertisement sent according to the rules in
Section 10.6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |M|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
The home agent's address as the mobile node would expect to see it
(i.e., same network prefix).
Destination Address
If this message is a response to a Mobile Prefix Solicitation,
this field contains the Source Address field from that packet.
For unsolicited messages, the mobile node's care-of address SHOULD
be used. Note that unsolicited messages can only be sent if the
mobile node is currently registered with the home agent.
Routing header:
A type 2 routing header MUST be included.
ESP header:
IPsec headers MUST be supported and SHOULD be used as described in
Section 5.4.
ICMP Fields:
Type
147
Code
0
Checksum
The ICMP checksum [17].
Identifier
An identifier to aid in matching this Mobile Prefix Advertisement
to a previous Mobile Prefix Solicitation.
M
1-bit Managed Address Configuration flag. When set, hosts use the
administered (stateful) protocol for address autoconfiguration in
addition to any addresses autoconfigured using stateless address
autoconfiguration. The use of this flag is described in [18]
[19].
O
1-bit Other Stateful Configuration flag. When set, hosts use the
administered (stateful) protocol for autoconfiguration of other
(non-address) information. The use of this flag is described in
[18] [19].
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
The Mobile Prefix Advertisement messages may have options. These
options MUST use the option format defined in Neighbor Discovery (RFC
4861 [18]). This document defines one option that may be carried in
a Mobile Prefix Advertisement message, but future documents may
define new options. Mobile nodes MUST silently ignore any options
they do not recognize and continue processing the message.
Prefix Information
Each message contains one or more Prefix Information options.
Each option carries the prefix(es) that the mobile node should use
to configure its home address(es). Section 10.6 describes which
prefixes should be advertised to the mobile node.
The Prefix Information option is defined in Section 4.6.2 of
Neighbor Discovery (RFC 4861 [18]), with modifications defined in
Section 7.2 of this specification. The home agent MUST use this
modified Prefix Information option to send home network prefixes
as defined in Section 10.6.1.
If the Advertisement is sent in response to a Mobile Prefix
Solicitation, the home agent MUST copy the Identifier value from that
message into the Identifier field of the Advertisement.
The home agent MUST NOT send more than one Mobile Prefix Advertisement message per second to any mobile node. The M and O bits MUST be cleared if the Home Agent DHCPv6 support is not provided. If such support is provided, then they are set in concert with the home network's administrative settings.
(page 64 continued on part 4)
