Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3775

Mobility Support in IPv6

Pages: 165
Obsoleted by:  6275
Part 2 of 5 – Pages 31 to 68
First   Prev   Next

ToP   noToC   RFC3775 - Page 31   prevText

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
ToP   noToC   RFC3775 - Page 32
   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.
ToP   noToC   RFC3775 - Page 33
   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
ToP   noToC   RFC3775 - Page 34
   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.
ToP   noToC   RFC3775 - Page 35
      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
ToP   noToC   RFC3775 - Page 36
      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.
ToP   noToC   RFC3775 - Page 37
   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.
ToP   noToC   RFC3775 - Page 38
   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.
ToP   noToC   RFC3775 - Page 39
   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.
ToP   noToC   RFC3775 - Page 40
   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.
ToP   noToC   RFC3775 - Page 41
   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
ToP   noToC   RFC3775 - Page 42
   (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.
ToP   noToC   RFC3775 - Page 43
   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.
ToP   noToC   RFC3775 - Page 44
   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.
ToP   noToC   RFC3775 - Page 45
   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.
ToP   noToC   RFC3775 - Page 46
   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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC3775 - Page 47
   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.
ToP   noToC   RFC3775 - Page 48
   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.
ToP   noToC   RFC3775 - Page 49

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC3775 - Page 50
   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.
ToP   noToC   RFC3775 - Page 51
   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.
ToP   noToC   RFC3775 - Page 52
   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.
ToP   noToC   RFC3775 - Page 53
   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).
ToP   noToC   RFC3775 - Page 54

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.
ToP   noToC   RFC3775 - Page 55
   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
ToP   noToC   RFC3775 - Page 56
   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 . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC3775 - Page 57
   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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC3775 - Page 58
   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.
ToP   noToC   RFC3775 - Page 59
   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.
ToP   noToC   RFC3775 - Page 60
   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.
ToP   noToC   RFC3775 - Page 61
   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:
ToP   noToC   RFC3775 - Page 62
    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:
ToP   noToC   RFC3775 - Page 63
    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
ToP   noToC   RFC3775 - Page 64
   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.
ToP   noToC   RFC3775 - Page 65
   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.
ToP   noToC   RFC3775 - Page 66
   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.
ToP   noToC   RFC3775 - Page 67
   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:
ToP   noToC   RFC3775 - Page 68
   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.