RFC 3775
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 Section 11.7.1 and Section 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 which are normally performed for all packets. This applies even to messages sent to or from a correspondent node which 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 [11]. This field is intended to be used by a future extension (see Appendix B.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 [11]. The Next Header value used in the
pseudo-header is 2. 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 [11].
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 which 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 which 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 which 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 which 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 which 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 which 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 which 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 which 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 which 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 Section 11.7.1 and Section 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. (In this case the specified care-of address MUST also be
set equal to the home address.) 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 which 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 which is not a unicast routable
address MUST be silently discarded. Similarly, the Binding Update
MUST be silently discarded if the care-of address appears as a home
address in an existing Binding Cache entry, with its current location
creating a circular reference back to the home address specified in
the Binding Update (possibly through additional entries).
The deletion of a binding can be indicated by setting the Lifetime
field to 0 and by setting the care-of address equal to the home
address. In deletion, the generation of the binding management key
depends exclusively on the home keygen token, as explained in Section
5.2.5. (Note that while the senders are required to set both the
Lifetime field to 0 and the care-of address equal to the home
address, Section 9.5.1 rules for receivers are more liberal, and
interpret either condition as a deletion.)
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 Section 9.5.4 and Section 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 . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
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
Up-to-date values of the Status field are to be specified in the IANA
registry of assigned numbers [19].
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 which 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
A 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 which 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 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 which 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) [11].
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 which it cannot use as a topologically correct source address (Section 6.1.7 and Section 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 which 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 which 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 which 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 [11] 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 [11]; 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
are present
For each IPv6 packet header, the Home Address Option MUST NOT appear
more than once. However, an encapsulated packet [15] 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 which 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 [11]. 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 [11]. The type 2 routing header defined for Mobile IPv6 follows the same ordering as other routing headers. If both a type 0 and a type 2 routing header are present, 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 the outer (type 0) routing header construction process. 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 [16] 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 2373 [3, 35].) 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 [14].
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 [14].
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 [14].
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 RFC 2461 [12]. 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 [14].
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 [12, 13].
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
[12, 13].
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 RFC 2461 [12]. This document defines one option which 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 RFC 2461 [12], 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.7. Modifications to IPv6 Neighbor Discovery
7.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the format of the Router Advertisement message [12] by the addition of a single flag bit to indicate that the router sending the Advertisement message is serving as a home agent on this link. The format of the Router Advertisement message 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally
specified for Neighbor Discovery [12]:
Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is also
functioning as a Mobile IPv6 home agent on this link.
Reserved
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit.
7.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address in
building a Home Agents List as part of the dynamic home agent address
discovery mechanism.
However, Neighbor Discovery [12] only advertises a router's link-
local address, by requiring this address to be used as the IP Source
Address of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow a router to advertise
its global address, by the addition of a single flag bit in the
format of a Prefix Information option for use in Router Advertisement
messages. The format of the Prefix Information 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 | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally
specified for Neighbor Discovery [12]:
Router Address (R)
1-bit router address flag. When set, indicates that the Prefix
field contains a complete IP address assigned to the sending
router. The indicated prefix is the first Prefix Length bits of
the Prefix field. The router IP address has the same scope and
conforms to the same lifetime values as the advertised prefix.
This use of the Prefix field is compatible with its use in
advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits.
Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit.
In a Router Advertisement, a home agent MUST, and all other routers
MAY, include at least one Prefix Information option with the Router
Address (R) bit set. Neighbor Discovery specifies that, if including
all options in a Router Advertisement causes the size of the
Advertisement to exceed the link MTU, multiple Advertisements can be
sent, each containing a subset of the options [12]. Also, when
sending unsolicited multicast Router Advertisements more frequently
than the limit specified in RFC 2461 [12], the sending router need not include all options in each of these Advertisements. However, in both of these cases the router SHOULD include at least one Prefix Information option with the Router Address (R) bit set in each such advertisement, if this bit is set in some advertisement sent by the router. In addition, the following requirement can assist mobile nodes in movement detection. Barring changes in the prefixes for the link, routers that send multiple Router Advertisements with the Router Address (R) bit set in some of the included Prefix Information options SHOULD provide at least one option and router address which stays the same in all of the Advertisements.7.3. New Advertisement Interval Option Format
Mobile IPv6 defines a new Advertisement Interval option, used in Router Advertisement messages to advertise the interval at which the sending router sends unsolicited multicast Router Advertisements. The format of the Advertisement Interval 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 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertisement Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 Length 8-bit unsigned integer. The length of the option (including the type and length fields) is in units of 8 octets. The value of this field MUST be 1. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited Router Advertisement messages sent
by this router on this network interface. Using the conceptual
router configuration variables defined by Neighbor Discovery [12],
this field MUST be equal to the value MaxRtrAdvInterval, expressed
in milliseconds.
Routers MAY include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for that router
in its movement detection algorithm, as described in Section 11.5.1.
This option MUST be silently ignored for other Neighbor Discovery
messages.
7.4. New Home Agent Information Option Format
Mobile IPv6 defines a new Home Agent Information option, used in
Router Advertisements sent by a home agent to advertise information
specific to this router's functionality as a home agent. The format
of the Home Agent Information 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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Length
8-bit unsigned integer. The length of the option (including the
type and length fields) in units of 8 octets. The value of this
field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Agent Preference
16-bit unsigned integer. The preference for the home agent
sending this Router Advertisement, for use in ordering the
addresses returned to a mobile node in the Home Agent Addresses
field of a Home Agent Address Discovery Reply message. Higher
values mean more preferable. If this option is not included in a
Router Advertisement in which the Home Agent (H) bit is set, the
preference value for this home agent MUST be considered to be 0.
Greater values indicate a more preferable home agent than lower
values.
The manual configuration of the Home Agent Preference value is
described in Section 8.4. In addition, the sending home agent MAY
dynamically set the Home Agent Preference value, for example
basing it on the number of mobile nodes it is currently serving or
on its remaining resources for serving additional mobile nodes;
such dynamic settings are beyond the scope of this document. Any
such dynamic setting of the Home Agent Preference, however, MUST
set the preference appropriately, relative to the default Home
Agent Preference value of 0 that may be in use by some home agents
on this link (i.e., a home agent not including a Home Agent
Information option in its Router Advertisements will be considered
to have a Home Agent Preference value of 0).
Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the home
agent in units of seconds. The default value is the same as the
Router Lifetime, as specified in the main body of the Router
Advertisement. The maximum value corresponds to 18.2 hours. A
value of 0 MUST NOT be used. The Home Agent Lifetime applies only
to this router's usefulness as a home agent; it does not apply to
information contained in other message fields or options.
Home agents MAY include this option in their Router Advertisements.
This option MUST NOT be included in a Router Advertisement in which
the Home Agent (H) bit (see Section 7.1) is not set. If this option
is not included in a Router Advertisement in which the Home Agent (H)
bit is set, the lifetime for this home agent MUST be considered to be
the same as the Router Lifetime in the Router Advertisement. If
multiple Advertisements are being sent instead of a single larger
unsolicited multicast Advertisement, all of the multiple
Advertisements with the Router Address (R) bit set MUST include this
option with the same contents, otherwise this option MUST be omitted
from all Advertisements.
This option MUST be silently ignored for other Neighbor Discovery messages. If both the Home Agent Preference and Home Agent Lifetime are set to their default values specified above, this option SHOULD NOT be included in the Router Advertisement messages sent by this home agent.7.5. Changes to Sending Router Advertisements
The Neighbor Discovery protocol specification [12] limits routers to a minimum interval of 3 seconds between sending unsolicited multicast Router Advertisement messages from any given network interface (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: "Routers generate Router Advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of advertisements to detect router failure; a separate Neighbor Unreachability Detection algorithm provides failure detection." This limitation, however, is not suitable to providing timely movement detection for mobile nodes. Mobile nodes detect their own movement by learning the presence of new routers as the mobile node moves into wireless transmission range of them (or physically connects to a new wired network), and by learning that previous routers are no longer reachable. Mobile nodes MUST be able to quickly detect when they move to a link served by a new router, so that they can acquire a new care-of address and send Binding Updates to register this care-of address with their home agent and to notify correspondent nodes as needed. One method which can provide for faster movement detection, is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. This method can be applied where the router is expecting to provide service to visiting mobile nodes (e.g., wireless network interfaces), or on which it is serving as a home agent to one or more mobile nodes (who may return home and need to hear its Advertisements). Routers supporting mobility SHOULD be able to be configured with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow sending of unsolicited multicast Router Advertisements more often. The minimum allowed values are:
o MinRtrAdvInterval 0.03 seconds o MaxRtrAdvInterval 0.07 seconds In the case where the minimum intervals and delays are used, the mean time between unsolicited multicast router advertisements is 50 ms. Use of these modified limits MUST be configurable (see also the configuration variable MinDelayBetweenRas in Section 13 which may also have to be modified accordingly). Systems where these values are available MUST NOT default to them, and SHOULD default to values specified in RFC 2461. Knowledge of the type of network interface and operating environment SHOULD be taken into account in configuring these limits for each network interface. This is important with some wireless links, where increasing the frequency of multicast beacons can cause considerable overhead. Routers SHOULD adhere to the intervals specified in RFC 2461 [12], if this overhead is likely to cause service degradation. Additionally, the possible low values of MaxRtrAdvInterval may cause some problems with movement detection in some mobile nodes. To ensure that this is not a problem, Routers SHOULD add 20 ms to any Advertisement Intervals sent in RAs, which are below 200 ms, in order to account for scheduling granularities on both the MN and the Router. Note that multicast Router Advertisements are not always required in certain wireless networks that have limited bandwidth. Mobility detection or link changes in such networks may be done at lower layers. Router advertisements in such networks SHOULD be sent only when solicited. In such networks it SHOULD be possible to disable unsolicited multicast Router Advertisements on specific interfaces. The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set to some high values. Home agents MUST include the Source Link-Layer Address option in all Router Advertisements they send. This simplifies the process of returning home, as discussed in Section 11.5.4. Note that according to RFC 2461 [12], AdvDefaultLifetime is by default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime field of Router Advertisements. Given that this field is expressed in seconds, a small MaxRtrAdvInterval value can result in a zero value for this field. To prevent this, routers SHOULD keep AdvDefaultLifetime in at least one second, even if the use of MaxRtrAdvInterval would result in a smaller value.