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 2 of 8, p. 15 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
4.  Overview of Mobile IPv6

4.1.  Basic Operation

   A mobile node is always expected to be addressable at its home
   address, whether it is currently attached to its home link or is away
   from home.  The "home address" is an IP address assigned to the
   mobile node within its home subnet prefix on its home link.  While a
   mobile node is at home, packets addressed to its home address are
   routed to the mobile node's home link, using conventional Internet
   routing mechanisms.

   While a mobile node is attached to some foreign link away from home,
   it is also addressable at one or more care-of addresses.  A care-of
   address is an IP address associated with a mobile node that has the
   subnet prefix of a particular foreign link.  The mobile node can
   acquire its care-of address through conventional IPv6 mechanisms,
   such as stateless or stateful auto-configuration.  As long as the
   mobile node stays in this location, packets addressed to this care-of
   address will be routed to the mobile node.  The mobile node may also
   accept packets from several care-of addresses, such as when it is
   moving but still reachable at the previous link.

Top      Up      ToC       Page 16 
   The association between a mobile node's home address and care-of
   address is known as a "binding" for the mobile node.  While away from
   home, a mobile node registers its primary care-of address with a
   router on its home link, requesting this router to function as the
   "home agent" for the mobile node.  The mobile node performs this
   binding registration by sending a "Binding Update" message to the
   home agent.  The home agent replies to the mobile node by returning a
   "Binding Acknowledgement" message.  The operation of the mobile node
   is specified in Section 11, and the operation of the home agent is
   specified in Section 10.

   Any node communicating with a mobile node is referred to in this
   document as a "correspondent node" of the mobile node, and may itself
   be either a stationary node or a mobile node.  Mobile nodes can
   provide information about their current location to correspondent
   nodes.  This happens through the correspondent registration.  As a
   part of this procedure, a return routability test is performed in
   order to authorize the establishment of the binding.  The operation
   of the correspondent node is specified in Section 9.

   There are two possible modes for communications between the mobile
   node and a correspondent node.  The first mode, bidirectional
   tunneling, does not require Mobile IPv6 support from the
   correspondent node and is available even if the mobile node has not
   registered its current binding with the correspondent node.  Packets
   from the correspondent node are routed to the home agent and then
   tunneled to the mobile node.  Packets to the correspondent node are
   tunneled from the mobile node to the home agent ("reverse tunneled")
   and then routed normally from the home network to the correspondent
   node.  In this mode, the home agent uses proxy Neighbor Discovery to
   intercept any IPv6 packets addressed to the mobile node's home
   address (or home addresses) on the home link.  Each intercepted
   packet is tunneled to the mobile node's primary care-of address.
   This tunneling is performed using IPv6 encapsulation [7].

   The second mode, "route optimization", requires the mobile node to
   register its current binding at the correspondent node.  Packets from
   the correspondent node can be routed directly to the care-of address
   of the mobile node.  When sending a packet to any IPv6 destination,
   the correspondent node checks its cached bindings for an entry for
   the packet's destination address.  If a cached binding for this
   destination address is found, the node uses a new type of IPv6
   routing header [6] (see Section 6.4) to route the packet to the
   mobile node by way of the care-of address indicated in this binding.

Top      Up      ToC       Page 17 
   Routing packets directly to the mobile node's care-of address allows
   the shortest communications path to be used.  It also eliminates
   congestion at the mobile node's home agent and home link.  In
   addition, the impact of temporary failures of the home agent or
   networks on the path to or from the home agent is reduced.

   When routing packets directly to the mobile node, the correspondent
   node sets the Destination Address in the IPv6 header to the care-of
   address of the mobile node.  A new type of IPv6 routing header (see
   Section 6.4) is also added to the packet to carry the desired home
   address.  Similarly, the mobile node sets the Source Address in the
   packet's IPv6 header to its current care-of addresses.  The mobile
   node adds a new IPv6 "Home Address" destination option (see
   Section 6.3) to carry its home address.  The inclusion of home
   addresses in these packets makes the use of the care-of address
   transparent above the network layer (e.g., at the transport layer).

   Mobile IPv6 also provides support for multiple home agents, and a
   limited support for the reconfiguration of the home network.  In
   these cases, the mobile node may not know the IP address of its own
   home agent, and even the home subnet prefixes may change over time.
   A mechanism known as "dynamic home agent address discovery" allows a
   mobile node to dynamically discover the IP address of a home agent on
   its home link, even when the mobile node is away from home.  Mobile
   nodes can also learn new information about home subnet prefixes
   through the "mobile prefix discovery" mechanism.  These mechanisms
   are described starting in Section 6.5.

   This document is written under the assumption that the mobile node is
   configured with the home prefix for the mobile node to be able to
   discover a home agent and configure a home address.  This might be
   limiting in deployments where the home agent and the home address for
   the mobile node need to be assigned dynamically.  Additional
   mechanisms have been specified for the mobile node to dynamically
   configure a home agent, a home address, and the home prefix.  These
   mechanisms are described in "Mobile IPv6 Bootstrapping in Split
   Scenario" [22] and "MIP6-bootstrapping for the Integrated Scenario"
   [36].

4.2.  New IPv6 Protocol

   Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header
   (see Section 6.1).  This header is used to carry the following
   messages:

   Home Test Init

   Home Test

Top      Up      ToC       Page 18 
   Care-of Test Init

   Care-of Test

      These four messages are used to perform the return routability
      procedure from the mobile node to a correspondent node.  This
      ensures authorization of subsequent Binding Updates, as described
      in Section 5.2.5.

   Binding Update

      A Binding Update is used by a mobile node to notify a
      correspondent node or the mobile node's home agent of its current
      binding.  The Binding Update sent to the mobile node's home agent
      to register its primary care-of address is marked as a "home
      registration".

   Binding Acknowledgement

      A Binding Acknowledgement is used to acknowledge receipt of a
      Binding Update, if an acknowledgement was requested in the Binding
      Update (e.g., the Binding Update was sent to a home agent), or an
      error occurred.

   Binding Refresh Request

      A Binding Refresh Request is used by a correspondent node to
      request that a mobile node re-establish its binding with the
      correspondent node.  This message is typically used when the
      cached binding is in active use but the binding's lifetime is
      close to expiration.  The correspondent node may use, for
      instance, recent traffic and open transport layer connections as
      an indication of active use.

   Binding Error

      The Binding Error 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.
      The Binding Error message is also used by the home agent to signal
      an error to the mobile node, if it receives an unrecognized
      Mobility Header Message Type from the mobile node.

4.3.  New IPv6 Destination Option

   Mobile IPv6 defines a new IPv6 destination option, the Home Address
   destination option.  This option is described in detail in
   Section 6.3.

Top      Up      ToC       Page 19 
4.4.  New IPv6 ICMP Messages

   Mobile IPv6 also introduces four new ICMP message types, two for use
   in the dynamic home agent address discovery mechanism, and two for
   renumbering and mobile configuration mechanisms.  As described in
   Sections 10.5 and 11.4.1, the following two new ICMP message types
   are used for home agent address discovery:

   o  Home Agent Address Discovery Request, described in Section 6.5.

   o  Home Agent Address Discovery Reply, described in Section 6.6.

   The next two message types are used for network renumbering and
   address configuration on the mobile node, as described in
   Section 10.6:

   o  Mobile Prefix Solicitation, described in Section 6.7.

   o  Mobile Prefix Advertisement, described in Section 6.8.

4.5.  Conceptual Data Structure Terminology

   This document describes the Mobile IPv6 protocol in terms of the
   following conceptual data structures:

   Binding Cache

      A cache of bindings for other nodes.  This cache is maintained by
      home agents and correspondent nodes.  The cache contains both
      "correspondent registration" entries (see Section 9.1) and "home
      registration" entries (see Section 10.1).

   Binding Update List

      This list is maintained by each mobile node.  The list has an item
      for every binding that the mobile node has or is trying to
      establish with a specific other node.  Both correspondent and home
      registrations are included in this list.  Entries from the list
      are deleted as the lifetime of the binding expires.  See
      Section 11.1.

Top      Up      ToC       Page 20 
   Home Agents List

      Home agents need to know which other home agents are on the same
      link.  This information is stored in the Home Agents List, as
      described in more detail in Section 10.1.  The list is used for
      informing mobile nodes during dynamic home agent address
      discovery.

4.6.  Unique-Local Addressability

   This specification requires that home and care-of addresses MUST be
   unicast routable addresses.  Unique-local IPv6 unicast addresses
   (ULAs, RFC 4193 [15]) may be usable on networks that use such non-
   globally routable addresses, but this specification does not define
   when such usage is safe and when it is not.  Mobile nodes may not be
   able to distinguish between their home site and the site at which
   they are currently located.  This can make it hard to prevent
   accidental attachment to other sites, because the mobile node might
   use the ULA at another site, which could not be used to successfully
   send packets to the mobile node's home agent (HA).  This would result
   in unreachability between the mobile node (MN) and the HA, when
   unique-local IPv6 routable addresses are used as care-of addresses.
   Similarly, CNs outside the MN's own site will not be reachable when
   ULAs are used as home addresses.  Therefore, unique-local IPv6
   unicast addresses SHOULD NOT be used as home or care-of addresses
   when other address choices are available.  If such addresses are
   used, however, according to RFC 4193 [15], they are treated as any
   global unicast IPv6 address so, for the remainder of this
   specification, use of unique-local IPv6 unicast addresses is not
   differentiated from other globally unique IPv6 addresses.

5.  Overview of Mobile IPv6 Security

   This specification provides a number of security features.  These
   include the protection of Binding Updates both to home agents and
   correspondent nodes, the protection of mobile prefix discovery, and
   the protection of the mechanisms that Mobile IPv6 uses for
   transporting data packets.

   Binding Updates are protected by the use of IPsec extension headers,
   or by the use of the Binding Authorization Data option.  This option
   employs a binding management key, Kbm, which can be established
   through the return routability procedure.  Mobile prefix discovery is
   protected through the use of IPsec extension headers.  Mechanisms
   related to transporting payload packets -- such as the Home Address
   destination option and type 2 routing header -- have been specified
   in a manner that restricts their use in attacks.

Top      Up      ToC       Page 21 
5.1.  Binding Updates to Home Agents

   The mobile node and the home agent MUST use an IPsec security
   association to protect the integrity and authenticity of the Binding
   Updates and Acknowledgements.  Both the mobile nodes and the home
   agents MUST support and SHOULD use the Encapsulating Security Payload
   (ESP) [5] header in transport mode and MUST use a non-NULL payload
   authentication algorithm to provide data origin authentication,
   connectionless integrity, and optional anti-replay protection.  Note
   that Authentication Header (AH) [4] is also possible but for brevity
   not discussed in this specification.

   In order to protect messages exchanged between the mobile node and
   the home agent with IPsec, appropriate security policy database
   entries must be created.  A mobile node must be prevented from using
   its security association to send a Binding Update on behalf of
   another mobile node using the same home agent.  This MUST be achieved
   by having the home agent check that the given home address has been
   used with the right security association.  Such a check is provided
   in the IPsec processing, by having the security policy database
   entries unequivocally identify a single security association for
   protecting Binding Updates between any given home address and home
   agent.  In order to make this possible, it is necessary that the home
   address of the mobile node is visible in the Binding Updates and
   Acknowledgements.  The home address is used in these packets as a
   source or destination, or in the Home Address destination option or
   the type 2 routing header.

   As with all IPsec security associations in this specification, manual
   configuration of security associations MUST be supported.  The shared
   secrets used MUST be random and unique for different mobile nodes,
   and MUST be distributed off-line to the mobile nodes.  Automatic key
   management with the Internet Key Exchange Protocol version 2 (IKEv2)
   [24] MAY be supported as described in [20].

   Section 11.3.2 discusses how IKEv2 connections to the home agent need
   a careful treatment of the addresses used for transporting IKEv2.
   This is necessary to ensure that a Binding Update is not needed
   before the IKEv2 exchange that is needed for securing the Binding
   Update.

   More detailed descriptions and examples using IPsec to protect
   communications between the mobile node and the home agent have been
   published [12][20].

Top      Up      ToC       Page 22 
5.2.  Binding Updates to Correspondent Nodes

   The protection of Binding Updates sent to correspondent nodes does
   not require the configuration of security associations or the
   existence of an authentication infrastructure between the mobile
   nodes and correspondent nodes.  Instead, a method called the return
   routability procedure is used to ensure that the right mobile node is
   sending the message.  This method does not protect against attackers
   who are on the path between the home network and the correspondent
   node.  However, attackers in such a location are capable of
   performing the same attacks even without Mobile IPv6.  The main
   advantage of the return routability procedure is that it limits the
   potential attackers to those having an access to one specific path in
   the Internet, and avoids forged Binding Updates from anywhere else in
   the Internet.  For a more in-depth explanation of the security
   properties of the return routability procedure, see Section 15.
   Also, consult [43].

   The integrity and authenticity of the Binding Update messages to
   correspondent nodes are protected by using a keyed-hash algorithm.
   The binding management key, Kbm, is used to key the hash algorithm
   for this purpose.  Kbm is established using data exchanged during the
   return routability procedure.  The data exchange is accomplished by
   use of node keys, nonces, cookies, tokens, and certain cryptographic
   functions.  Section 5.2.5 outlines the basic return routability
   procedure.  Section 5.2.6 shows how the results of this procedure are
   used to authorize a Binding Update to a correspondent node.

5.2.1.  Node Keys

   Each correspondent node has a secret key, Kcn, called the "node key",
   which it uses to produce the keygen tokens sent to the mobile nodes.
   The node key MUST be a random number, 20 octets in length.  The node
   key allows the correspondent node to verify that the keygen tokens
   used by the mobile node in authorizing a Binding Update are indeed
   its own.  This key MUST NOT be shared with any other entity.

   A correspondent node MAY generate a fresh node key at any time; this
   avoids the need for secure persistent key storage.  Procedures for
   optionally updating the node key are discussed later in
   Section 5.2.7.

Top      Up      ToC       Page 23 
5.2.2.  Nonces

   Each correspondent node also generates nonces at regular intervals.
   The nonces should be generated by using a random number generator
   that is known to have good randomness properties [14].  A
   correspondent node may use the same Kcn and nonce with all the mobile
   nodes with which it is in communication.

   Each nonce is identified by a nonce index.  When a new nonce is
   generated, it must be associated with a new nonce index; this may be
   done, for example, by incrementing the value of the previous nonce
   index, if the nonce index is used as an array pointer into a linear
   array of nonces.  However, there is no requirement that nonces be
   stored that way, or that the values of subsequent nonce indices have
   any particular relationship to each other.  The index value is
   communicated in the protocol, so that if a nonce is replaced by a new
   nonce during the run of a protocol, the correspondent node can
   distinguish messages that should be checked against the old nonce
   from messages that should be checked against the new nonce.  Strictly
   speaking, indices are not necessary in the authentication, but allow
   the correspondent node to efficiently find the nonce value that it
   used in creating a keygen token.

   Correspondent nodes keep both the current nonce and a small set of
   valid previous nonces whose lifetime has not yet expired.  Expired
   values MUST be discarded, and messages using stale or unknown indices
   will be rejected.

   The specific nonce index values cannot be used by mobile nodes to
   determine the validity of the nonce.  Expected validity times for the
   nonces values and the procedures for updating them are discussed
   later in Section 5.2.7.

   A nonce is an octet string of any length.  The recommended length is
   64 bits.

5.2.3.  Cookies and Tokens

   The return routability address test procedure uses cookies and keygen
   tokens as opaque values within the test init and test messages,
   respectively.

   o  The "home init cookie" and "care-of init cookie" are 64-bit values
      sent to the correspondent node from the mobile node, and later
      returned to the mobile node.  The home init cookie is sent in the
      Home Test Init message, and returned in the Home Test message.
      The care-of init cookie is sent in the Care-of Test Init message,
      and returned in the Care-of Test message.

Top      Up      ToC       Page 24 
   o  The "home keygen token" and "care-of keygen token" are 64-bit
      values sent by the correspondent node to the mobile node via the
      home agent (via the Home Test message) and the care-of address (by
      the Care-of Test message), respectively.

   The mobile node should set the home init or care-of init cookie to a
   newly generated random number in every Home or Care-of Test Init
   message it sends.  The cookies are used to verify that the Home Test
   or Care-of Test message matches the Home Test Init or Care-of Test
   Init message, respectively.  These cookies also serve to ensure that
   parties who have not seen the request cannot spoof responses.

   Home and care-of keygen tokens are produced by the correspondent node
   based on its currently active secret key (Kcn) and nonces, as well as
   the home or care-of address (respectively).  A keygen token is valid
   as long as both the secret key (Kcn) and the nonce used to create it
   are valid.

5.2.4.  Cryptographic Functions

   By default in this specification, the function used to compute hash
   values is SHA-1 [11], which is considered to offer sufficient
   protection for Mobile IPv6 control messages (see Section 15.10).
   Message Authentication Codes (MACs) are then computed using HMAC_SHA1
   [1][11].  HMAC_SHA1(K,m) denotes such a MAC computed on message m
   with key K.

5.2.5.  Return Routability Procedure

   The return routability procedure enables the correspondent node to
   obtain some reasonable assurance that the mobile node is in fact
   addressable at its claimed care-of address as well as at its home
   address.  Only with this assurance is the correspondent node able to
   accept Binding Updates from the mobile node, which would then
   instruct the correspondent node to direct that mobile node's data
   traffic to its claimed care-of address.

   This is done by testing whether packets addressed to the two claimed
   addresses are routed to the mobile node.  The mobile node can pass
   the test only if it is able to supply proof that it received certain
   data (the "keygen tokens") that the correspondent node sends to those
   addresses.  These data are combined by the mobile node into a binding
   management key, denoted Kbm.

   The figure below shows the message flow for the return routability
   procedure.

Top      Up      ToC       Page 25 
    Mobile node                 Home agent           Correspondent node
         |                                                     |
         |  Home Test Init (HoTI)   |                          |
         |------------------------->|------------------------->|
         |                          |                          |
         |  Care-of Test Init (CoTI)                           |
         |---------------------------------------------------->|
         |                                                     |
         |                          |  Home Test (HoT)         |
         |<-------------------------|<-------------------------|
         |                          |                          |
         |                             Care-of Test (CoT)      |
         |<----------------------------------------------------|
         |                                                     |

   The Home and Care-of Test Init messages are sent at the same time.
   The procedure requires very little processing at the correspondent
   node, and the Home and Care-of Test messages can be returned quickly,
   perhaps nearly simultaneously.  These four messages form the return
   routability procedure.

   Home Test Init

      A mobile node sends a Home Test Init message to the correspondent
      node (via the home agent) to acquire the home keygen token.  The
      contents of the message can be summarized as follows:

      *  Source Address = home address

      *  Destination Address = correspondent

      *  Parameters:

         +  home init cookie

      The Home Test Init message conveys the mobile node's home address
      to the correspondent node.  The mobile node also sends along a
      home init cookie that the correspondent node must return later.
      The Home Test Init message is reverse tunneled through the home
      agent.  (The headers and addresses related to reverse tunneling
      have been omitted from the above discussion of the message
      contents.)  The mobile node remembers these cookie values to
      obtain some assurance that its protocol messages are being
      processed by the desired correspondent node.

Top      Up      ToC       Page 26 
   Care-of Test Init

      The mobile node sends a Care-of Test Init message to the
      correspondent node (directly, not via the home agent) to acquire
      the care-of keygen token.  The contents of this message can be
      summarized as follows:

      *  Source Address = care-of address

      *  Destination Address = correspondent

      *  Parameters:

         +  care-of init cookie

      The Care-of Test Init message conveys the mobile node's care-of
      address to the correspondent node.  The mobile node also sends
      along a care-of init cookie that the correspondent node must
      return later.  The Care-of Test Init message is sent directly to
      the correspondent node.

   Home Test

      The Home Test message is sent in response to a Home Test Init
      message.  It is sent via the home agent.  The contents of the
      message are:

      *  Source Address = correspondent

      *  Destination Address = home address

      *  Parameters:

         +  home init cookie

         +  home keygen token

         +  home nonce index

      When the correspondent node receives the Home Test Init message,
      it generates a home keygen token as follows:

       home keygen token :=
            First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0)))

   where | denotes concatenation.  The final "0" inside the HMAC_SHA1
   function is a single zero octet, used to distinguish home and care-of
   cookies from each other.

Top      Up      ToC       Page 27 
   The home keygen token is formed from the first 64 bits of the MAC.
   The home keygen token tests that the mobile node can receive messages
   sent to its home address.  Kcn is used in the production of home
   keygen token in order to allow the correspondent node to verify that
   it generated the home and care-of nonces, without forcing the
   correspondent node to remember a list of all tokens it has handed
   out.

   The Home Test message is sent to the mobile node via the home
   network, where it is presumed that the home agent will tunnel the
   message to the mobile node.  This means that the mobile node needs to
   already have sent a Binding Update to the home agent, so that the
   home agent will have received and authorized the new care-of address
   for the mobile node before the return routability procedure.  For
   improved security, the data passed between the home agent and the
   mobile node is made immune to inspection and passive attacks.  Such
   protection is gained by encrypting the home keygen token as it is
   tunneled from the home agent to the mobile node as specified in
   Section 10.4.6.  The security properties of this additional security
   are discussed in Section 15.4.1.

   The home init cookie from the mobile node is returned in the Home
   Test message, to ensure that the message comes from a node on the
   route between the home agent and the correspondent node.

   The home nonce index is delivered to the mobile node to later allow
   the correspondent node to efficiently find the nonce value that it
   used in creating the home keygen token.

   Care-of Test

      This message is sent in response to a Care-of Test Init message.
      This message is not sent via the home agent; it is sent directly
      to the mobile node.  The contents of the message are:

      *  Source Address = correspondent

      *  Destination Address = care-of address

      *  Parameters:

         +  care-of init cookie

         +  care-of keygen token

         +  care-of nonce index

Top      Up      ToC       Page 28 
      When the correspondent node receives the Care-of Test Init
      message, it generates a care-of keygen token as follows:

       care-of keygen token :=
           First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))

   Here, the final "1" inside the HMAC_SHA1 function is a single octet
   containing the hex value 0x01, and is used to distinguish home and
   care-of cookies from each other.  The keygen token is formed from the
   first 64 bits of the MAC, and sent directly to the mobile node at its
   care-of address.  The care-of init cookie from the Care-of Test Init
   message is returned to ensure that the message comes from a node on
   the route to the correspondent node.

   The care-of nonce index is provided to identify the nonce used for
   the care-of keygen token.  The home and care-of nonce indices MAY be
   the same, or different, in the Home and Care-of Test messages.

   When the mobile node has received both the Home and Care-of Test
   messages, the return routability procedure is complete.  As a result
   of the procedure, the mobile node has the data it needs to send a
   Binding Update to the correspondent node.  The mobile node hashes the
   tokens together to form a 20-octet binding key Kbm:

       Kbm = SHA-1 (home keygen token | care-of keygen token)

   A Binding Update may also be used to delete a previously established
   binding (Section 6.1.7).  In this case, the care-of keygen token is
   not used.  Instead, the binding management key is generated as
   follows:

       Kbm = SHA-1(home keygen token)

   Note that the correspondent node does not create any state specific
   to the mobile node, until it receives the Binding Update from that
   mobile node.  The correspondent node does not maintain the value for
   the binding management key Kbm; it creates Kbm when given the nonce
   indices and the mobile node's addresses.

5.2.6.  Authorizing Binding Management Messages

   After the mobile node has created the binding management key (Kbm),
   it can supply a verifiable Binding Update to the correspondent node.
   This section provides an overview of this registration.  The figure
   below shows the message flow.

Top      Up      ToC       Page 29 
     Mobile node                                Correspondent node
          |                                               |
          |             Binding Update (BU)               |
          |---------------------------------------------->|
          |  (MAC, seq#, nonce indices, care-of address)  |
          |                                               |
          |                                               |
          |    Binding Acknowledgement (BA) (if sent)     |
          |<----------------------------------------------|
          |              (MAC, seq#, status)              |

   Binding Update

      To authorize a Binding Update, the mobile node creates a binding
      management key Kbm from the keygen tokens as described in the
      previous section.  The contents of the Binding Update include the
      following:

      *  Source Address = care-of address

      *  Destination Address = correspondent

      *  Parameters:

         +  home address (within the Home Address destination option if
            different from the Source Address)

         +  sequence number (within the Binding Update message header)

         +  home nonce index (within the Nonce Indices option)

         +  care-of nonce index (within the Nonce Indices option)

         +  First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
            | BU)))

      The Binding Update contains a Nonce Indices option, indicating to
      the correspondent node which home and care-of nonces to use to
      recompute Kbm, the binding management key.  The MAC is computed as
      described in Section 6.2.7, using the correspondent node's address
      as the destination address and the Binding Update message itself
      ("BU" above) as the Mobility Header (MH) Data.

      Once the correspondent node has verified the MAC, it can create a
      Binding Cache entry for the mobile.

Top      Up      ToC       Page 30 
   Binding Acknowledgement

      The Binding Update is in some cases acknowledged by the
      correspondent node.  The contents of the message are as follows:

      *  Source Address = correspondent

      *  Destination Address = care-of address

      *  Parameters:

         +  sequence number (within the Binding Update message header)

         +  First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
            | BA)))

      The Binding Acknowledgement contains the same sequence number as
      the Binding Update.  The MAC is computed as described in
      Section 6.2.7, using the correspondent node's address as the
      destination address and the message itself ("BA" above) as the MH
      Data.

   Bindings established with correspondent nodes using keys created by
   way of the return routability procedure MUST NOT exceed
   MAX_RR_BINDING_LIFETIME seconds (see Section 12).

   The value in the Source Address field in the IPv6 header carrying the
   Binding Update is normally also the care-of address that is used in
   the binding.  However, a different care-of address MAY be specified
   by including an Alternate Care-of Address mobility option in the
   Binding Update (see Section 6.2.5).  When such a message is sent to
   the correspondent node and the return routability procedure is used
   as the authorization method, the Care-of Test Init and Care-of Test
   messages MUST have been performed for the address in the Alternate
   Care-of Address option (not the Source Address).  The nonce indices
   and MAC value MUST be based on information gained in this test.

   Binding Updates may also be sent to delete a previously established
   binding.  In this case, generation of the binding management key
   depends exclusively on the home keygen token and the care-of nonce
   index is ignored.

5.2.7.  Updating Node Keys and Nonces

   Correspondent nodes generate nonces at regular intervals.  It is
   recommended to keep each nonce (identified by a nonce index)
   acceptable for at least MAX_TOKEN_LIFETIME seconds (see Section 12)
   after it has been first used in constructing a return routability

Top      Up      ToC       Page 31 
   message response.  However, the correspondent node MUST NOT accept
   nonces beyond MAX_NONCE_LIFETIME seconds (see Section 12) after the
   first use.  As the difference between these two constants is 30
   seconds, a convenient way to enforce the above lifetimes is to
   generate a new nonce every 30 seconds.  The node can then continue to
   accept tokens that have been based on the last 8 (MAX_NONCE_LIFETIME
   / 30) nonces.  This results in tokens being acceptable
   MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been
   sent to the mobile node, depending on whether the token was sent at
   the beginning or end of the first 30-second period.  Note that the
   correspondent node may also attempt to generate new nonces on demand,
   or only if the old nonces have been used.  This is possible, as long
   as the correspondent node keeps track of how long a time ago the
   nonces were used for the first time, and does not generate new nonces
   on every return routability request.

   Due to resource limitations, rapid deletion of bindings, or reboots
   the correspondent node may not in all cases recognize the nonces that
   the tokens were based on.  If a nonce index is unrecognized, the
   correspondent node replies with an error code in the Binding
   Acknowledgement (either 136, 137, or 138 as discussed in
   Section 6.1.8).  The mobile node can then retry the return
   routability procedure.

   An update of Kcn SHOULD be done at the same time as an update of a
   nonce, so that nonce indices can identify both the nonce and the key.
   Old Kcn values have to be therefore remembered as long as old nonce
   values.

   Given that the tokens are normally expected to be usable for
   MAX_TOKEN_LIFETIME seconds, the mobile node MAY use them beyond a
   single run of the return routability procedure until
   MAX_TOKEN_LIFETIME expires.  After this the mobile node SHOULD NOT
   use the tokens.  A fast moving mobile node MAY reuse a recent home
   keygen token from a correspondent node when moving to a new location,
   and just acquire a new care-of keygen token to show routability in
   the new location.

   While this does not save the number of round-trips due to the
   simultaneous processing of home and care-of return routability tests,
   there are fewer messages being exchanged, and a potentially long
   round-trip through the home agent is avoided.  Consequently, this
   optimization is often useful.  A mobile node that has multiple home
   addresses MAY also use the same care-of keygen token for Binding
   Updates concerning all of these addresses.

Top      Up      ToC       Page 32 
5.2.8.  Preventing Replay Attacks

   The return routability procedure also protects the participants
   against replayed Binding Updates through the use of the sequence
   number and a MAC.  Care must be taken when removing bindings at the
   correspondent node, however.  Correspondent nodes must retain
   bindings and the associated sequence number information at least as
   long as the nonces used in the authorization of the binding are still
   valid.  Alternatively, if memory is very constrained, the
   correspondent node MAY invalidate the nonces that were used for the
   binding being deleted (or some larger group of nonces that they
   belong to).  This may, however, impact the ability to accept Binding
   Updates from mobile nodes that have recently received keygen tokens.
   This alternative is therefore recommended only as a last measure.

5.2.9.  Handling Interruptions to Return Routability

   In some scenarios, such as simultaneous mobility, where both
   correspondent host and mobile host move at the same time, or in the
   case where the correspondent node reboots and loses data, route
   optimization may not complete, or relevant data in the binding cache
   might be lost.

   o  Return Routability signaling MUST be sent to the correspondent
      node's home address if it has one (i.e., not to the correspondent
      nodes care-of address if the correspondent node is also mobile).

   o  If Return Routability signaling timed out after MAX_RO_FAILURE
      attempts, the mobile node MUST revert to sending packets to the
      correspondent node's home address through its home agent.

   The mobile node may run the bidirectional tunneling in parallel with
   the return routability procedure until it is successful.  Exponential
   backoff SHOULD be used for retransmission of return routability
   messages.

   The return routability procedure may be triggered by movement of the
   mobile node or by sustained loss of end-to-end communication with a
   correspondent node (e.g., based on indications from upper layers)
   that has been using a route optimized connection to the mobile node.
   If such indications are received, the mobile node MAY revert to
   bidirectional tunneling while restarting the return routability
   procedure.

Top      Up      ToC       Page 33 
5.3.  Dynamic Home Agent Address Discovery

   Dynamic home agent address discovery has been designed for use in
   deployments where security is not needed.  For this reason, no
   security solution is provided in this document for dynamic home agent
   address discovery.

5.4.  Mobile Prefix Discovery

   The mobile node and the home agent SHOULD use an IPsec security
   association to protect the integrity and authenticity of the Mobile
   Prefix Solicitations and Advertisements.  Both the mobile nodes and
   the home agents MUST support and SHOULD use the Encapsulating
   Security Payload (ESP) header in transport mode with a non-NULL
   payload authentication algorithm to provide data origin
   authentication, connectionless integrity, and optional anti-replay
   protection.

5.5.  Payload Packets

   Payload packets exchanged with mobile nodes can be protected in the
   usual manner, in the same way as stationary hosts can protect them.
   However, Mobile IPv6 introduces the Home Address destination option,
   a routing header, and tunneling headers in the payload packets.  In
   the following we define the security measures taken to protect these,
   and to prevent their use in attacks against other parties.

   This specification limits the use of the Home Address destination
   option to the situation where the correspondent node already has a
   Binding Cache entry for the given home address.  This avoids the use
   of the Home Address option in attacks described in Section 15.1.

   Mobile IPv6 uses a type of routing header specific to Mobile IPv6.
   This type provides the necessary functionality but does not open
   vulnerabilities discussed in Section 15.1 and RFC 5095 [45].

   Tunnels between the mobile node and the home agent are protected by
   ensuring proper use of source addresses, and optional cryptographic
   protection.  The mobile node verifies that the outer IP address
   corresponds to its home agent.  The home agent verifies that the
   outer IP address corresponds to the current location of the mobile
   node (Binding Updates sent to the home agents are secure).  The home
   agent identifies the mobile node through the source address of the
   inner packet.  (Typically, this is the home address of the mobile
   node, but it can also be a link-local address, as discussed in
   Section 10.4.2.  To recognize the latter type of addresses, the home

Top      Up      ToC       Page 34 
   agent requires that the Link-Local Address Compatibility (L) was set
   in the Binding Update.)  These measures protect the tunnels against
   vulnerabilities discussed in Section 15.1.

   For traffic tunneled via the home agent, additional IPsec ESP
   encapsulation MAY be supported and used.  If multicast group
   membership control protocols or stateful address autoconfiguration
   protocols are supported, payload data protection MUST be supported.



(page 34 continued on part 3)

Next RFC Part