tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6275

 
 
 

Mobility Support in IPv6

Part 3 of 8, p. 34 to 64
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 34 
6.  New IPv6 Protocol, Message Types, and Destination Option

6.1.  Mobility Header

   The Mobility Header is an extension header used by mobile nodes,
   correspondent nodes, and home agents in all messaging related to the
   creation and management of bindings.  The subsections within this
   section describe the message types that may be sent using the
   Mobility Header.

   Mobility Header messages MUST NOT be sent with a type 2 routing
   header, except as described in Section 9.5.4 for Binding
   Acknowledgement.  Mobility Header messages also MUST NOT be used with
   a Home Address destination option, except as described in Sections
   11.7.1 and 11.7.2 for Binding Update.  Binding Update List or Binding
   Cache information (when present) for the destination MUST NOT be used
   in sending Mobility Header messages.  That is, Mobility Header
   messages bypass both the Binding Cache check described in
   Section 9.3.2 and the Binding Update List check described in
   Section 11.3.1 that are normally performed for all packets.  This
   applies even to messages sent to or from a correspondent node that is
   itself a mobile node.

6.1.1.  Format

   The Mobility Header is identified by a Next Header value of 135 in
   the immediately preceding header, and has the following format:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Payload Proto |  Header Len   |   MH Type     |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                                                               |
       .                                                               .
       .                       Message Data                            .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 35 
   Payload Proto

      8-bit selector.  Identifies the type of header immediately
      following the Mobility Header.  Uses the same values as the IPv6
      Next Header field [6].

      This field is intended to be used by a future extension (see
      Appendix A.1).

      Implementations conforming to this specification SHOULD set the
      payload protocol type to IPPROTO_NONE (59 decimal).

   Header Len

      8-bit unsigned integer, representing the length of the Mobility
      Header in units of 8 octets, excluding the first 8 octets.

      The length of the Mobility Header MUST be a multiple of 8 octets.

   MH Type

      8-bit selector.  Identifies the particular mobility message in
      question.  Current values are specified in Section 6.1.2 and
      onward.  An unrecognized MH Type field causes an error indication
      to be sent.

   Reserved

      8-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Checksum

      16-bit unsigned integer.  This field contains the checksum of the
      Mobility Header.  The checksum is calculated from the octet string
      consisting of a "pseudo-header" followed by the entire Mobility
      Header starting with the Payload Proto field.  The checksum is the
      16-bit one's complement of the one's complement sum of this
      string.

      The pseudo-header contains IPv6 header fields, as specified in
      Section 8.1 of RFC 2460 [6].  The Next Header value used in the
      pseudo-header is 135.  The addresses used in the pseudo-header are
      the addresses that appear in the Source and Destination Address
      fields in the IPv6 packet carrying the Mobility Header.

Top      Up      ToC       Page 36 
      Note that the procedures of calculating upper-layer checksums
      while away from home described in Section 11.3.1 apply even for
      the Mobility Header.  If a mobility message has a Home Address
      destination option, then the checksum calculation uses the home
      address in this option as the value of the IPv6 Source Address
      field.  The type 2 routing header is treated as explained in [6].

      The Mobility Header is considered as the upper-layer protocol for
      the purposes of calculating the pseudo-header.  The Upper-Layer
      Packet Length field in the pseudo-header MUST be set to the total
      length of the Mobility Header.

      For computing the checksum, the checksum field is set to zero.

   Message Data

      A variable-length field containing the data specific to the
      indicated Mobility Header type.

   Mobile IPv6 also defines a number of "mobility options" for use
   within these messages; if included, any options MUST appear after the
   fixed portion of the message data specified in this document.  The
   presence of such options will be indicated by the Header Len field
   within the message.  When the Header Len value is greater than the
   length required for the message specified here, the remaining octets
   are interpreted as mobility options.  These options include padding
   options that can be used to ensure that other options are aligned
   properly, and that the total length of the message is divisible by 8.
   The encoding and format of defined options are described in
   Section 6.2.

   Alignment requirements for the Mobility Header are the same as for
   any IPv6 protocol header.  That is, they MUST be aligned on an
   8-octet boundary.

6.1.2.  Binding Refresh Request Message

   The Binding Refresh Request (BRR) message requests a mobile node to
   update its mobility binding.  This message is sent by correspondent
   nodes according to the rules in Section 9.5.5.  When a mobile node
   receives a packet containing a Binding Refresh Request message it
   processes the message according to the rules in Section 11.7.4.

   The Binding Refresh Request message uses the MH Type value 0.  When
   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:

Top      Up      ToC       Page 37 
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      16-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in Section 6.2.  The
      receiver MUST ignore and skip any options that it does not
      understand.

      There MAY be additional information, associated with this Binding
      Refresh Request message that need not be present in all Binding
      Refresh Request messages sent.  Mobility options allow future
      extensions to the format of the Binding Refresh Request message to
      be defined.  This specification does not define any options valid
      for the Binding Refresh Request message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 0.

6.1.3.  Home Test Init Message

   A mobile node uses the Home Test Init (HoTI) message to initiate the
   return routability procedure and request a home keygen token from a
   correspondent node (see Section 11.6.1).  The Home Test Init message
   uses the MH Type value 1.  When this value is indicated in the MH
   Type field, the format of the Message Data field in the Mobility
   Header is as follows:

Top      Up      ToC       Page 38 
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                       Home Init Cookie                        +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                       Mobility Options                        .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      16-bit field reserved for future use.  This value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Home Init Cookie

      64-bit field that contains a random value, the home init cookie.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver
      MUST ignore and skip any options that it does not understand.
      This specification does not define any options valid for the Home
      Test Init message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 1.

   This message is tunneled through the home agent when the mobile node
   is away from home.  Such tunneling SHOULD employ IPsec ESP in tunnel
   mode between the home agent and the mobile node.  This protection is
   indicated by the IPsec security policy database.  The protection of
   Home Test Init messages is unrelated to the requirement to protect
   regular payload traffic, which MAY use such tunnels as well.

6.1.4.  Care-of Test Init Message

   A mobile node uses the Care-of Test Init (CoTI) message to initiate
   the return routability procedure and request a care-of keygen token
   from a correspondent node (see Section 11.6.1).  The Care-of Test

Top      Up      ToC       Page 39 
   Init message uses the MH Type value 2.  When this value is indicated
   in the MH Type field, the format of the Message Data field in the
   Mobility Header is as follows:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                      Care-of Init Cookie                      +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      16-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Care-of Init Cookie

      64-bit field that contains a random value, the care-of init
      cookie.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver
      MUST ignore and skip any options that it does not understand.
      This specification does not define any options valid for the
      Care-of Test Init message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 1.

6.1.5.  Home Test Message

   The Home Test (HoT) message is a response to the Home Test Init
   message, and is sent from the correspondent node to the mobile node
   (see Section 5.2.5).  The Home Test message uses the MH Type value 3.
   When this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:

Top      Up      ToC       Page 40 
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |       Home Nonce Index        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                        Home Init Cookie                       +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                       Home Keygen Token                       +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Home Nonce Index

      This field will be echoed back by the mobile node to the
      correspondent node in a subsequent Binding Update.

   Home Init Cookie

      64-bit field that contains the home init cookie.

   Home Keygen Token

      This field contains the 64-bit home keygen token used in the
      return routability procedure.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver
      MUST ignore and skip any options that it does not understand.
      This specification does not define any options valid for the Home
      Test message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 2.

Top      Up      ToC       Page 41 
6.1.6.  Care-of Test Message

   The Care-of Test (CoT) message is a response to the Care-of Test Init
   message, and is sent from the correspondent node to the mobile node
   (see Section 11.6.2).  The Care-of Test message uses the MH Type
   value 4.  When this value is indicated in the MH Type field, the
   format of the Message Data field in the Mobility Header is as
   follows:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |      Care-of Nonce Index      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                      Care-of Init Cookie                      +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                     Care-of Keygen Token                      +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Care-of Nonce Index

      This value will be echoed back by the mobile node to the
      correspondent node in a subsequent Binding Update.

   Care-of Init Cookie

      64-bit field that contains the care-of init cookie.

   Care-of Keygen Token

      This field contains the 64-bit care-of keygen token used in the
      return routability procedure.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver

Top      Up      ToC       Page 42 
      MUST ignore and skip any options that it does not understand.
      This specification does not define any options valid for the
      Care-of Test message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 2.

6.1.7.  Binding Update Message

   The Binding Update (BU) message is used by a mobile node to notify
   other nodes of a new care-of address for itself.  Binding Updates are
   sent as described in Sections 11.7.1 and 11.7.2.

   The Binding Update uses the MH Type value 5.  When this value is
   indicated in the MH Type field, the format of the Message Data field
   in the Mobility Header is as follows:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|H|L|K|        Reserved       |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Acknowledge (A)

      The Acknowledge (A) bit is set by the sending mobile node to
      request a Binding Acknowledgement (Section 6.1.8) be returned upon
      receipt of the Binding Update.

   Home Registration (H)

      The Home Registration (H) bit is set by the sending mobile node to
      request that the receiving node should act as this node's home
      agent.  The destination of the packet carrying this message MUST
      be that of a router sharing the same subnet prefix as the home
      address of the mobile node in the binding.

   Link-Local Address Compatibility (L)

      The Link-Local Address Compatibility (L) bit is set when the home
      address reported by the mobile node has the same interface
      identifier as the mobile node's link-local address.

Top      Up      ToC       Page 43 
   Key Management Mobility Capability (K)

      If this bit is cleared, the protocol used for establishing the
      IPsec security associations between the mobile node and the home
      agent does not survive movements.  It may then have to be rerun.
      (Note that the IPsec security associations themselves are expected
      to survive movements.)  If manual IPsec configuration is used, the
      bit MUST be cleared.

      This bit is valid only in Binding Updates sent to the home agent,
      and MUST be cleared in other Binding Updates.  Correspondent nodes
      MUST ignore this bit.

   Reserved

      These fields are unused.  They MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   Sequence #

      A 16-bit unsigned integer used by the receiving node to sequence
      Binding Updates and by the sending node to match a returned
      Binding Acknowledgement with this Binding Update.

   Lifetime

      16-bit unsigned integer.  The number of time units remaining
      before the binding MUST be considered expired.  A value of zero
      indicates that the Binding Cache entry for the mobile node MUST be
      deleted.  One time unit is 4 seconds.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in Section 6.2.  The
      receiver MUST ignore and skip any options that it does not
      understand.

      The following options are valid in a Binding Update:

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

      *  Nonce Indices option

      *  Alternate Care-of Address option

Top      Up      ToC       Page 44 
   If no options are present in this message, 4 octets of padding are
   necessary and the Header Len field will be set to 1.

   The care-of address is specified either by the Source Address field
   in the IPv6 header or by the Alternate Care-of Address option, if
   present.  The care-of address MUST be a unicast routable address.
   IPv6 Source Address MUST be a topologically correct source address.
   Binding Updates for a care-of address that is not a unicast routable
   address MUST be silently discarded.

   The deletion of a binding MUST be indicated by setting the Lifetime
   field to 0.  In deletion, the generation of the binding management
   key depends exclusively on the home keygen token, as explained in
   Section 5.2.5.

   Correspondent nodes SHOULD NOT delete the Binding Cache entry before
   the lifetime expires, if any application hosted by the correspondent
   node is still likely to require communication with the mobile node.
   A Binding Cache entry that is de-allocated prematurely might cause
   subsequent packets to be dropped from the mobile node, if they
   contain the Home Address destination option.  This situation is
   recoverable, since a Binding Error message is sent to the mobile node
   (see Section 6.1.9); however, it causes unnecessary delay in the
   communications.

6.1.8.  Binding Acknowledgement Message

   The Binding Acknowledgement is used to acknowledge receipt of a
   Binding Update (Section 6.1.7).  This packet is sent as described in
   Sections 9.5.4 and 10.3.1.

   The Binding Acknowledgement has the MH Type value 6.  When this value
   is indicated in the MH Type field, the format of the Message Data
   field in the Mobility Header is as follows:

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |    Status     |K|  Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Sequence #          |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 45 
   Status

      8-bit unsigned integer indicating the disposition of the Binding
      Update.  Values of the Status field less than 128 indicate that
      the Binding Update was accepted by the receiving node.  Values
      greater than or equal to 128 indicate that the Binding Update was
      rejected by the receiving node.  The following Status values are
      currently defined:

           0  Binding Update accepted

           1  Accepted but prefix discovery necessary

         128  Reason unspecified

         129  Administratively prohibited

         130  Insufficient resources

         131  Home registration not supported

         132  Not home subnet

         133  Not home agent for this mobile node

         134  Duplicate Address Detection failed

         135  Sequence number out of window

         136  Expired home nonce index

         137  Expired care-of nonce index

         138  Expired nonces

         139  Registration type change disallowed

         174  Invalid Care-of Address

      Up-to-date values of the Status field are to be specified in the
      IANA registry of assigned numbers [30].

Top      Up      ToC       Page 46 
   Key Management Mobility Capability (K)

      If this bit is cleared, the protocol used by the home agent for
      establishing the IPsec security associations between the mobile
      node and the home agent does not survive movements.  It may then
      have to be rerun.  (Note that the IPsec security associations
      themselves are expected to survive movements.)

      Correspondent nodes MUST set the K bit to 0.

   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   Sequence #

      The Sequence Number in the Binding Acknowledgement is copied from
      the Sequence Number field in the Binding Update.  It is used by
      the mobile node in matching this Binding Acknowledgement with an
      outstanding Binding Update.

   Lifetime

      The granted lifetime, in time units of 4 seconds, for which this
      node SHOULD retain the entry for this mobile node in its Binding
      Cache.

      The value of this field is undefined if the Status field indicates
      that the Binding Update was rejected.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The encoding
      and format of defined options are described in Section 6.2.  The
      receiver MUST ignore and skip any options that it does not
      understand.

      There MAY be additional information associated with this Binding
      Acknowledgement that need not be present in all Binding
      Acknowledgements sent.  Mobility options allow future extensions
      to the format of the Binding Acknowledgement to be defined.  The
      following options are valid for the Binding Acknowledgement:

Top      Up      ToC       Page 47 
      *  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

Top      Up      ToC       Page 48 
   Reserved

      8-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Home Address

      The home address that was contained in the Home Address
      destination option.  The mobile node uses this information to
      determine which binding does not exist, in cases where the mobile
      node has several home addresses.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver
      MUST ignore and skip any options that it does not understand.
      There MAY be additional information associated with this Binding
      Error message that need not be present in all Binding Error
      messages sent.  Mobility options allow future extensions to the
      format of the Binding Error message to be defined.  The encoding
      and format of defined options are described in Section 6.2.  This
      specification does not define any options valid for the Binding
      Error message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 2.

6.2.  Mobility Options

   Mobility messages can include zero or more mobility options.  This
   allows optional fields that may not be needed in every use of a
   particular Mobility Header, as well as future extensions to the
   format of the messages.  Such options are included in the Message
   Data field of the message itself, after the fixed portion of the
   message data specified in the message subsections of Section 6.1.

   The presence of such options will be indicated by the Header Len of
   the Mobility Header.  If included, the Binding Authorization Data
   option (Section 6.2.7) MUST be the last option and MUST NOT have
   trailing padding.  Otherwise, options can be placed in any order.

Top      Up      ToC       Page 49 
6.2.1.  Format

   Mobility options are encoded within the remaining space of the
   Message Data field of a mobility message, using a type-length-value
   (TLV) format as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Type  | Option Length |   Option Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      8-bit identifier of the type of mobility option.  When processing
      a Mobility Header containing an option for which the Option Type
      value is not recognized by the receiver, the receiver MUST quietly
      ignore and skip over the option, correctly handling any remaining
      options in the message.

   Option Length

      8-bit unsigned integer, representing the length in octets of the
      mobility option, not including the Option Type and Option Length
      fields.

   Option Data

      A variable-length field that contains data specific to the option.

   The following subsections specify the Option types that are currently
   defined for use in the Mobility Header.

   Implementations MUST silently ignore any mobility options that they
   do not understand.

   Mobility options may have alignment requirements.  Following the
   convention in IPv6, these options are aligned in a packet so that
   multi-octet values within the Option Data field of each option fall
   on natural boundaries (i.e., fields of width n octets are placed at
   an integer multiple of n octets from the start of the header, for n =
   1, 2, 4, or 8) [6].

6.2.2.  Pad1

   The Pad1 option does not have any alignment requirements.  Its format
   is as follows:

Top      Up      ToC       Page 50 
        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

Top      Up      ToC       Page 51 
   remaining time until the mobile node SHOULD send a new home
   registration to the home agent.  The Refresh Interval MUST be set to
   indicate a smaller time interval than the Lifetime value of the
   Binding Acknowledgement.

6.2.5.  Alternate Care-of Address

   The Alternate Care-of Address option has an alignment requirement of
   8n + 6.  Its format is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = 3    |  Length = 16  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                   Alternate Care-of Address                   +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Normally, a Binding Update specifies the desired care-of address in
   the Source Address field of the IPv6 header.  However, this is not
   possible in some cases, such as when the mobile node wishes to
   indicate a care-of address that it cannot use as a topologically
   correct source address (Sections 6.1.7 and 11.7.2) or when the used
   security mechanism does not protect the IPv6 header (Section 11.7.1).

   The Alternate Care-of Address option is provided for these
   situations.  This option is valid only in Binding Update.  The
   Alternate Care-of Address field contains an address to use as the
   care-of address for the binding, rather than using the Source Address
   of the packet as the care-of address.

Top      Up      ToC       Page 52 
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.

Top      Up      ToC       Page 53 
   The Option Length field contains the length of the authenticator in
   octets.

   The Authenticator field contains a cryptographic value that can be
   used to determine that the message in question comes from the right
   authority.  Rules for calculating this value depends on the used
   authorization procedure.

   For the return routability procedure, this option can appear in the
   Binding Update and Binding Acknowledgements.  Rules for calculating
   the Authenticator value are the following:

     Mobility Data = care-of address | correspondent | MH Data
     Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))

   Where | denotes concatenation.  "Care-of address" is the care-of
   address that will be registered for the mobile node if the Binding
   Update succeeds, or the home address of the mobile node if this
   option is used in de-registration.  Note also that this address might
   be different from the source address of the Binding Update message,
   if the Alternative Care-of Address mobility option is used, or when
   the lifetime of the binding is set to zero.

   The "correspondent" is the IPv6 address of the correspondent node.
   Note that, if the message is sent to a destination that is itself
   mobile, the "correspondent" address may not be the address found in
   the Destination Address field of the IPv6 header; instead, the home
   address from the type 2 Routing header should be used.

   "MH Data" is the content of the Mobility Header, excluding the
   Authenticator field itself.  The Authenticator value is calculated as
   if the Checksum field in the Mobility Header was zero.  The Checksum
   in the transmitted packet is still calculated in the usual manner,
   with the calculated Authenticator being a part of the packet
   protected by the Checksum.  Kbm is the binding management key, which
   is typically created using nonces provided by the correspondent node
   (see Section 9.4).  Note that while the contents of a potential Home
   Address destination option are not covered in this formula, the rules
   for the calculation of the Kbm do take the home address in account.
   This ensures that the MAC will be different for different home
   addresses.

   The first 96 bits from the MAC result are used as the Authenticator
   field.

Top      Up      ToC       Page 54 
6.3.  Home Address Option

   The Home Address option is carried by the Destination Option
   extension header (Next Header value = 60).  It is used in a packet
   sent by a mobile node while away from home, to inform the recipient
   of the mobile node's home address.

   The Home Address option is encoded in type-length-value (TLV) format
   as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  | Option Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                          Home Address                         +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      201 = 0xC9

   Option Length

      8-bit unsigned integer.  Length of the option, in octets,
      excluding the Option Type and Option Length fields.  This field
      MUST be set to 16.

   Home Address

      The home address of the mobile node sending the packet.  This
      address MUST be a unicast routable address.

   The alignment requirement [6] for the Home Address option is 8n + 6.

   The three highest-order bits of the Option Type field are encoded to
   indicate specific processing of the option [6]; for the Home Address
   option, these three bits are set to 110.  This indicates the
   following processing requirements:

Top      Up      ToC       Page 55 
   o  Any IPv6 node that does not recognize the Option Type must discard
      the packet, and if the packet's Destination Address was not a
      multicast address, return an ICMP Parameter Problem, Code 2,
      message to the packet's Source Address.  The Pointer field in the
      ICMP message SHOULD point at the Option Type field.  Otherwise,
      for multicast addresses, the ICMP message MUST NOT be sent.

   o  The data within the option cannot change en route to the packet's
      final destination.

   The Home Address option MUST be placed as follows:

   o  After the routing header, if that header is present

   o  Before the Fragment Header, if that header is present

   o  Before the AH Header or ESP Header, if either one of those headers
      is present

   For each IPv6 packet header, the Home Address option MUST NOT appear
   more than once.  However, an encapsulated packet [7] MAY contain a
   separate Home Address option associated with each encapsulating IP
   header.

   The inclusion of a Home Address destination option in a packet
   affects the receiving node's processing of only this single packet.
   No state is created or modified in the receiving node as a result of
   receiving a Home Address option in a packet.  In particular, the
   presence of a Home Address option in a received packet MUST NOT alter
   the contents of the receiver's Binding Cache and MUST NOT cause any
   changes in the routing of subsequent packets sent by this receiving
   node.

6.4.  Type 2 Routing Header

   Mobile IPv6 defines a new routing header variant, the type 2 routing
   header, to allow the packet to be routed directly from a
   correspondent to the mobile node's care-of address.  The mobile
   node's care-of address is inserted into the IPv6 Destination Address
   field.  Once the packet arrives at the care-of address, the mobile
   node retrieves its home address from the routing header, and this is
   used as the final destination address for the packet.

   The new routing header uses a different type than defined for
   "regular" IPv6 source routing, enabling firewalls to apply different
   rules to source routed packets than to Mobile IPv6.  This routing
   header type (type 2) is restricted to carry only one IPv6 address.
   All IPv6 nodes that process this routing header MUST verify that the

Top      Up      ToC       Page 56 
   address contained within is the node's own home address in order to
   prevent packets from being forwarded outside the node.  The IP
   address contained in the routing header, since it is the mobile
   node's home address, MUST be a unicast routable address.
   Furthermore, if the scope of the home address is smaller than the
   scope of the care-of address, the mobile node MUST discard the packet
   (see Section 4.6).

6.4.1.  Format

   The type 2 routing header has the following format:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Reserved                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                         Home Address                          +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header

      8-bit selector.  Identifies the type of header immediately
      following the routing header.  Uses the same values as the IPv6
      Next Header field [6].

   Hdr Ext Len

      2 (8-bit unsigned integer); length of the routing header in
      8-octet units, not including the first 8 octets.

   Routing Type

      2 (8-bit unsigned integer).

   Segments Left

      1 (8-bit unsigned integer).

Top      Up      ToC       Page 57 
   Reserved

      32-bit reserved field.  The value MUST be initialized to zero by
      the sender, and MUST be ignored by the receiver.

   Home Address

      The home address of the destination mobile node.

   For a type 2 routing header, the Hdr Ext Len MUST be 2.  The Segments
   Left value describes the number of route segments remaining, i.e.,
   number of explicitly listed intermediate nodes still to be visited
   before reaching the final destination.  Segments Left MUST be 1.  The
   ordering rules for extension headers in an IPv6 packet are described
   in Section 4.1 of RFC 2460 [6].  The type 2 routing header defined
   for Mobile IPv6 follows the same ordering as other routing headers.
   If another routing header is present along with a type 2 routing
   header, the type 2 routing header should follow the other routing
   header.  A packet containing such nested encapsulation should be
   created as if the inner (type 2) routing header was constructed first
   and then treated as an original packet by header construction process
   for the other routing header.

   In addition, the general procedures defined by IPv6 for routing
   headers suggest that a received routing header MAY be automatically
   "reversed" to construct a routing header for use in any response
   packets sent by upper-layer protocols, if the received packet is
   authenticated [6].  This MUST NOT be done automatically for type 2
   routing headers.

6.5.  ICMP Home Agent Address Discovery Request Message

   The ICMP Home Agent Address Discovery Request message is used by a
   mobile node to initiate the dynamic home agent address discovery
   mechanism, as described in Section 11.4.1.  The mobile node sends the
   Home Agent Address Discovery Request message to the Mobile IPv6 Home-
   Agents anycast address [8] for its own home subnet prefix.  (Note
   that the currently defined anycast addresses may not work with all
   prefix lengths other than those defined in RFC 4291 [16] [37].)

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |            Checksum           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Identifier           |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 58 
   Type

      144

   Code

      0

   Checksum

      The ICMP checksum [17].

   Identifier

      An identifier to aid in matching Home Agent Address Discovery
      Reply messages to this Home Agent Address Discovery Request
      message.

   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   The Source Address of the Home Agent Address Discovery Request
   message packet is typically one of the mobile node's current care-of
   addresses.  At the time of performing this dynamic home agent address
   discovery procedure, it is likely that the mobile node is not
   registered with any home agent.  Therefore, neither the nature of the
   address nor the identity of the mobile node can be established at
   this time.  The home agent MUST then return the Home Agent Address
   Discovery Reply message directly to the Source Address chosen by the
   mobile node.

6.6.  ICMP Home Agent Address Discovery Reply Message

   The ICMP Home Agent Address Discovery Reply message is used by a home
   agent to respond to a mobile node that uses the dynamic home agent
   address discovery mechanism, as described in Section 10.5.

Top      Up      ToC       Page 59 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |            Checksum           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |             Reserved          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      .                                                               .
      .                      Home Agent Addresses                     .
      .                                                               .
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      145

   Code

      0

   Checksum

      The ICMP checksum [17].

   Identifier

      The identifier from the invoking Home Agent Address Discovery
      Request message.

   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   Home Agent Addresses

      A list of addresses of home agents on the home link for the mobile
      node.  The number of addresses presented in the list is indicated
      by the remaining length of the IPv6 packet carrying the Home Agent
      Address Discovery Reply message.

Top      Up      ToC       Page 60 
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:

Top      Up      ToC       Page 61 
   Type

      146

   Code

      0

   Checksum

      The ICMP checksum [17].

   Identifier

      An identifier to aid in matching a future Mobile Prefix
      Advertisement to this Mobile Prefix Solicitation.

   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   The Mobile Prefix Solicitation messages may have options.  These
   options MUST use the option format defined in Neighbor Discovery (RFC
   4861 [18]).  This document does not define any option types for the
   Mobile Prefix Solicitation message, but future documents may define
   new options.  Home agents MUST silently ignore any options they do
   not recognize and continue processing the message.

6.8.  ICMP Mobile Prefix Advertisement Message Format

   A home agent will send a Mobile Prefix Advertisement to a mobile node
   to distribute prefix information about the home link while the mobile
   node is traveling away from the home network.  This will occur in
   response to a Mobile Prefix Solicitation with an Advertisement, or by
   an unsolicited Advertisement sent according to the rules in
   Section 10.6.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Identifier           |M|O|        Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 62 
   IP Fields:

   Source Address

      The home agent's address as the mobile node would expect to see it
      (i.e., same network prefix).

   Destination Address

      If this message is a response to a Mobile Prefix Solicitation,
      this field contains the Source Address field from that packet.
      For unsolicited messages, the mobile node's care-of address SHOULD
      be used.  Note that unsolicited messages can only be sent if the
      mobile node is currently registered with the home agent.

   Routing header:

      A type 2 routing header MUST be included.

   ESP header:

      IPsec headers MUST be supported and SHOULD be used as described in
      Section 5.4.

   ICMP Fields:

   Type

      147

   Code

      0

   Checksum

      The ICMP checksum [17].

Top      Up      ToC       Page 63 
   Identifier

      An identifier to aid in matching this Mobile Prefix Advertisement
      to a previous Mobile Prefix Solicitation.

   M

      1-bit Managed Address Configuration flag.  When set, hosts use the
      administered (stateful) protocol for address autoconfiguration in
      addition to any addresses autoconfigured using stateless address
      autoconfiguration.  The use of this flag is described in [18]
      [19].

   O

      1-bit Other Stateful Configuration flag.  When set, hosts use the
      administered (stateful) protocol for autoconfiguration of other
      (non-address) information.  The use of this flag is described in
      [18] [19].

   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   The Mobile Prefix Advertisement messages may have options.  These
   options MUST use the option format defined in Neighbor Discovery (RFC
   4861 [18]).  This document defines one option that may be carried in
   a Mobile Prefix Advertisement message, but future documents may
   define new options.  Mobile nodes MUST silently ignore any options
   they do not recognize and continue processing the message.

   Prefix Information

      Each message contains one or more Prefix Information options.
      Each option carries the prefix(es) that the mobile node should use
      to configure its home address(es).  Section 10.6 describes which
      prefixes should be advertised to the mobile node.

      The Prefix Information option is defined in Section 4.6.2 of
      Neighbor Discovery (RFC 4861 [18]), with modifications defined in
      Section 7.2 of this specification.  The home agent MUST use this
      modified Prefix Information option to send home network prefixes
      as defined in Section 10.6.1.

   If the Advertisement is sent in response to a Mobile Prefix
   Solicitation, the home agent MUST copy the Identifier value from that
   message into the Identifier field of the Advertisement.

Top      Up      ToC       Page 64 
   The home agent MUST NOT send more than one Mobile Prefix
   Advertisement message per second to any mobile node.

   The M and O bits MUST be cleared if the Home Agent DHCPv6 support is
   not provided.  If such support is provided, then they are set in
   concert with the home network's administrative settings.



(page 64 continued on part 4)

Next RFC Part