Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3775

Mobility Support in IPv6

Pages: 165
Obsoleted by:  6275
Part 4 of 5 – Pages 105 to 138
First   Prev   Next

ToP   noToC   RFC3775 - Page 105   prevText

11. Mobile Node Operation

11.1. Conceptual Data Structures

Each mobile node MUST maintain a Binding Update List. The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. The Binding Update List includes all bindings sent by the mobile node either to its home agent or correspondent nodes. It also contains Binding Updates which are waiting for the completion of the return routability procedure before they can be sent. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. The Binding Update List MAY be implemented in
ToP   noToC   RFC3775 - Page 106
   any manner consistent with the external behavior described in this
   document.

   Each Binding Update List entry conceptually contains the following
   fields:

   o  The IP address of the node to which a Binding Update was sent.

   o  The home address for which that Binding Update was sent.

   o  The care-of address sent in that Binding Update.  This value is
      necessary for the mobile node to determine if it has sent a
      Binding Update while giving its new care-of address to this
      destination after changing its care-of address.

   o  The initial value of the Lifetime field sent in that Binding
      Update.

   o  The remaining lifetime of that binding.  This lifetime is
      initialized from the Lifetime value sent in the Binding Update and
      is decremented until it reaches zero, at which time this entry
      MUST be deleted from the Binding Update List.

   o  The maximum value of the Sequence Number field sent in previous
      Binding Updates to this destination.  The Sequence Number field is
      16 bits long and all comparisons between Sequence Number values
      MUST be performed modulo 2**16 (see Section 9.5.1).

   o  The time at which a Binding Update was last sent to this
      destination, as needed to implement the rate limiting restriction
      for sending Binding Updates.

   o  The state of any retransmissions needed for this Binding Update.
      This state includes the time remaining until the next
      retransmission attempt for the Binding Update and the current
      state of the exponential back-off mechanism for retransmissions.

   o  A flag specifying whether or not future Binding Updates should be
      sent to this destination.  The mobile node sets this flag in the
      Binding Update List entry when it receives an ICMP Parameter
      Problem, Code 1, error message in response to a return routability
      message or Binding Update sent to that destination, as described
      in Section 11.3.5.

   The Binding Update List is used to determine whether a particular
   packet is sent directly to the correspondent node or tunneled via the
   home agent (see Section 11.3.1).
ToP   noToC   RFC3775 - Page 107
   The Binding Update list also conceptually contains the following data
   related to running the return routability procedure.  This data is
   relevant only for Binding Updates sent to correspondent nodes.

   o  The time at which a Home Test Init or Care-of Test Init message
      was last sent to this destination, as needed to implement the rate
      limiting restriction for the return routability procedure.

   o  The state of any retransmissions needed for this return
      routability procedure.  This state includes the time remaining
      until the next retransmission attempt and the current state of the
      exponential back-off mechanism for retransmissions.

   o  Cookie values used in the Home Test Init and Care-of Test Init
      messages.

   o  Home and care-of keygen tokens received from the correspondent
      node.

   o  Home and care-of nonce indices received from the correspondent
      node.

   o  The time at which each of the tokens and nonces were received from
      the correspondent node, as needed to implement reuse while moving.

11.2. Processing Mobility Headers

All IPv6 mobile nodes MUST observe the rules described in Section 9.2 when processing Mobility Headers.

11.3. Packet Processing

11.3.1. Sending Packets While Away from Home

While a mobile node is away from home, it continues to use its home address, as well as also using one or more care-of addresses. When sending a packet while away from home, a mobile node MAY choose among these in selecting the address that it will use as the source of the packet, as follows: o Protocols layered over IP will generally treat the mobile node's home address as its IP address for most packets. For packets sent that are part of transport-level connections established while the mobile node was at home, the mobile node MUST use its home address. Likewise, for packets sent that are part of transport- level connections that the mobile node may still be using after moving to a new location, the mobile node SHOULD use its home address in this way. If a binding exists, the mobile node SHOULD
ToP   noToC   RFC3775 - Page 108
      send the packets directly to the correspondent node.  Otherwise,
      if a binding does not exist, the mobile node MUST use reverse
      tunneling.

   o  The mobile node MAY choose to directly use one of its care-of
      addresses as the source of the packet, not requiring the use of a
      Home Address option in the packet.  This is particularly useful
      for short-term communication that may easily be retried if it
      fails.  Using the mobile node's care-of address as the source for
      such queries will generally have a lower overhead than using the
      mobile node's home address, since no extra options need be used in
      either the query or its reply.  Such packets can be routed
      normally, directly between their source and destination without
      relying on Mobile IPv6.  If application running on the mobile node
      has no particular knowledge that the communication being sent fits
      within this general type of communication, however, the mobile
      node should not use its care-of address as the source of the
      packet in this way.

      The choice of the most efficient communications method is
      application specific, and outside the scope of this specification.
      The APIs necessary for controlling the choice are also out of
      scope.

   o  While not at its home link, the mobile node MUST NOT use the Home
      Address destination option when communicating with link-local or
      site-local peers, if the scope of the home address is larger than
      the scope of the peer's address.

      Similarly, the mobile node MUST NOT use the Home Address
      destination option for IPv6 Neighbor Discovery [12] packets.

   Detailed operation of these cases is described later in this section
   and also discussed in [31].

   For packets sent by a mobile node while it is at home, no special
   Mobile IPv6 processing is required.  Likewise, if the mobile node
   uses any address other than one of its home addresses as the source
   of a packet sent while away from home, no special Mobile IPv6
   processing is required.  In either case, the packet is simply
   addressed and transmitted in the same way as any normal IPv6 packet.

   For packets sent by the mobile node sent while away from home using
   the mobile node's home address as the source, special Mobile IPv6
   processing of the packet is required.  This can be done in the
   following two ways:
ToP   noToC   RFC3775 - Page 109
   Route Optimization

   This manner of delivering packets does not require going through the
   home network, and typically will enable faster and more reliable
   transmission.

   The mobile node needs to ensure that a Binding Cache entry exists for
   its home address so that the correspondent node can process the
   packet (Section 9.3.1 specifies the rules for Home Address
   Destination Option Processing at a correspondent node).  The mobile
   node SHOULD examine its Binding Update List for an entry which
   fulfills the following conditions:

   *  The Source Address field of the packet being sent is equal to the
      home address in the entry.

   *  The Destination Address field of the packet being sent is equal to
      the address of the correspondent node in the entry.

   *  One of the current care-of addresses of the mobile node appears as
      the care-of address in the entry.

   *  The entry indicates that a binding has been successfully created.

   *  The remaining lifetime of the binding is greater than zero.

   When these conditions are met, the mobile node knows that the
   correspondent node has a suitable Binding Cache entry.

   A mobile node SHOULD arrange to supply the home address in a Home
   Address option, and MUST set the IPv6 header's Source Address field
   to the care-of address which the mobile node has registered to be
   used with this correspondent node.  The correspondent node will then
   use the address supplied in the Home Address option to serve the
   function traditionally done by the Source IP address in the IPv6
   header.  The mobile node's home address is then supplied to higher
   protocol layers and applications.

   Specifically:

   *  Construct the packet using the mobile node's home address as the
      packet's Source Address, in the same way as if the mobile node
      were at home.  This includes the calculation of upper layer
      checksums using the home address as the value of the source.

   *  Insert a Home Address option into the packet with the Home Address
      field copied from the original value of the Source Address field
      in the packet.
ToP   noToC   RFC3775 - Page 110
   *  Change the Source Address field in the packet's IPv6 header to one
      of the mobile node's care-of addresses.  This will typically be
      the mobile node's current primary care-of address, but MUST be an
      address assigned to the interface on the link being used.

   By using the care-of address as the Source Address in the IPv6
   header, with the mobile node's home address instead in the Home
   Address option, the packet will be able to safely pass through any
   router implementing ingress filtering [26].

   Reverse Tunneling

      This is the mechanism which tunnels the packets via the home
      agent.  It is not as efficient as the above mechanism, but is
      needed if there is no binding yet with the correspondent node.

      This mechanism is used for packets that have the mobile node's
      home address as the Source Address in the IPv6 header, or with
      multicast control protocol packets as described in Section 11.3.4.
      Specifically:

      *  The packet is sent to the home agent using IPv6 encapsulation
         [15].

      *  The Source Address in the tunnel packet is the primary care-of
         address as registered with the home agent.

      *  The Destination Address in the tunnel packet is the home
         agent's address.

      Then, the home agent will pass the encapsulated packet to the
      correspondent node.

11.3.2. Interaction with Outbound IPsec Processing

This section sketches the interaction between outbound Mobile IPv6 processing and outbound IP Security (IPsec) processing for packets sent by a mobile node while away from home. Any specific implementation MAY use algorithms and data structures other than those suggested here, but its processing MUST be consistent with the effect of the operation described here and with the relevant IPsec specifications. In the steps described below, it is assumed that IPsec is being used in transport mode [4] and that the mobile node is using its home address as the source for the packet (from the point of view of higher protocol layers or applications, as described in Section 11.3.1):
ToP   noToC   RFC3775 - Page 111
   o  The packet is created by higher layer protocols and applications
      (e.g., by TCP) as if the mobile node were at home and Mobile IPv6
      were not being used.

   o  Determine the outgoing interface for the packet.  (Note that the
      selection between reverse tunneling and route optimization may
      imply different interfaces, particularly if tunnels are considered
      interfaces as well.)

   o  As part of outbound packet processing in IP, the packet is
      compared against the IPsec security policy database to determine
      what processing is required for the packet [4].

   o  If IPsec processing is required, the packet is either mapped to an
      existing Security Association (or SA bundle), or a new SA (or SA
      bundle) is created for the packet, according to the procedures
      defined for IPsec.

   o  Since the mobile node is away from home, the mobile is either
      using reverse tunneling or route optimization to reach the
      correspondent node.

      If reverse tunneling is used, the packet is constructed in the
      normal manner and then tunneled through the home agent.

      If route optimization is in use, the mobile node inserts a Home
      Address destination option into the packet, replacing the Source
      Address in the packet's IP header with the care-of address used
      with this correspondent node, as described in Section 11.3.1.  The
      Destination Options header in which the Home Address destination
      option is inserted MUST appear in the packet after the routing
      header, if present, and before the IPsec (AH [5] or ESP [6])
      header, so that the Home Address destination option is processed
      by the destination node before the IPsec header is processed.

      Finally, once the packet is fully assembled, the necessary IPsec
      authentication (and encryption, if required) processing is
      performed on the packet, initializing the Authentication Data in
      the IPsec header.

      RFC 2402 treatment of destination options is extended as follows.
      The AH authentication data MUST be calculated as if the following
      were true:

      *  the IPv6 source address in the IPv6 header contains the mobile
         node's home address,
ToP   noToC   RFC3775 - Page 112
      *  the Home Address field of the Home Address destination option
         (Section 6.3) contains the new care-of address.

   o  This allows, but does not require, the receiver of the packet
      containing a Home Address destination option to exchange the two
      fields of the incoming packet to reach the above situation,
      simplifying processing for all subsequent packet headers.
      However, such an exchange is not required, as long as the result
      of the authentication calculation remains the same.

   When an automated key management protocol is used to create new
   security associations for a peer, it is important to ensure that the
   peer can send the key management protocol packets to the mobile node.
   This may not be possible if the peer is the home agent of the mobile
   node and the purpose of the security associations would be to send a
   Binding Update to the home agent.  Packets addressed to the home
   address of the mobile node cannot be used before the Binding Update
   has been processed.  For the default case of using IKE [9] as the
   automated key management protocol, such problems can be avoided by
   the following requirements when communicating with its home agent:

   o  When the mobile node is away from home, it MUST use its care-of
      address as the Source Address of all packets it sends as part of
      the key management protocol (without use of Mobile IPv6 for these
      packets, as suggested in Section 11.3.1).

   o  In addition, for all security associations bound to the mobile
      node's home address established by IKE, the mobile node MUST
      include an ISAKMP Identification Payload [8] in the IKE phase 2
      exchange, giving the mobile node's home address as the initiator
      of the Security Association [7].

   The Key Management Mobility Capability (K) bit in Binding Updates and
   Acknowledgements can be used to avoid the need to rerun IKE upon
   movements.

11.3.3. Receiving Packets While Away from Home

While away from home, a mobile node will receive packets addressed to its home address, by one of two methods: o Packets sent by a correspondent node, that does not have a Binding Cache entry for the mobile node, will be sent to the home address, captured by the home agent and tunneled to the mobile node. o Packets sent by a correspondent node that has a Binding Cache entry for the mobile node that contains the mobile node's current care-of address, will be sent by the correspondent node using a
ToP   noToC   RFC3775 - Page 113
      type 2 routing header.  The packet will be addressed to the mobile
      node's care-of address, with the final hop in the routing header
      directing the packet to the mobile node's home address; the
      processing of this last hop of the routing header is entirely
      internal to the mobile node, since the care-of address and home
      address are both addresses within the mobile node.

   For packets received by the first method, the mobile node MUST check
   that the IPv6 source address of the tunneled packet is the IP address
   of its home agent.  In this method, the mobile node may also send a
   Binding Update to the original sender of the packet as described in
   Section 11.7.2 and subject to the rate limiting defined in Section
   11.8.  The mobile node MUST also process the received packet in the
   manner defined for IPv6 encapsulation [15], which will result in the
   encapsulated (inner) packet being processed normally by upper-layer
   protocols within the mobile node as if it had been addressed (only)
   to the mobile node's home address.

   For packets received by the second method, the following rules will
   result in the packet being processed normally by upper-layer
   protocols within the mobile node as if it had been addressed to the
   mobile node's home address.

   A node receiving a packet addressed to itself (i.e., one of the
   node's addresses is in the IPv6 destination field) follows the next
   header chain of headers and processes them.  When it encounters a
   type 2 routing header during this processing, it performs the
   following checks.  If any of these checks fail, the node MUST
   silently discard the packet.

   o  The length field in the routing header is exactly 2.

   o  The segments left field in the routing header is 1 on the wire.
      (But implementations may process the routing header so that the
      value may become 0 after the routing header has been processed,
      but before the rest of the packet is processed.)

   o  The Home Address field in the routing header is one of the node's
      home addresses, if the segments left field was 1.  Thus, in
      particular the address field is required to be a unicast routable
      address.

   Once the above checks have been performed, the node swaps the IPv6
   destination field with the Home Address field in the routing header,
   decrements segments left by one from the value it had on the wire,
   and resubmits the packet to IP for processing the next header.
ToP   noToC   RFC3775 - Page 114
   Conceptually, this follows the same model as in RFC 2460.  However,
   in the case of type 2 routing header this can be simplified since it
   is known that the packet will not be forwarded to a different node.

   The definition of AH requires the sender to calculate the AH
   integrity check value of a routing header in the same way it appears
   in the receiver after it has processed the header.  Since IPsec
   headers follow the routing header, any IPsec processing will operate
   on the packet with the home address in the IP destination field and
   segments left being zero.  Thus, the AH calculations at the sender
   and receiver will have an identical view of the packet.

11.3.4. Routing Multicast Packets

A mobile node that is connected to its home link functions in the same way as any other (stationary) node. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. Therefore, this section describes the behavior of a mobile node that is not on its home link. In order to receive packets sent to some multicast group, a mobile node must join that multicast group. One method, in which a mobile node MAY join the group, is via a (local) multicast router on the foreign link being visited. In this case, the mobile node MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD packets [17]. Alternatively, a mobile node MAY join multicast groups via a bi- directional tunnel to its home agent. The mobile node tunnels its multicast group membership control packets (such as those defined in [17] or in [37]) to its home agent, and the home agent forwards multicast packets down the tunnel to the mobile node. A mobile node MUST NOT tunnel multicast group membership control packets until (1) the mobile node has a binding in place at the home agent, and (2) the latter sends at least one multicast group membership control packet via the tunnel. Once this condition is true, the mobile node SHOULD assume it does not change as long as the binding does not expire. A mobile node that wishes to send packets to a multicast group also has two options: 1. Send directly on the foreign link being visited. The application is aware of the care-of address and uses it as a source address for multicast traffic, just like it would use a stationary address. The mobile node MUST NOT use Home Address destination option in such traffic.
ToP   noToC   RFC3775 - Page 115
   2.  Send via a tunnel to its home agent.

       Because multicast routing in general depends upon the Source
       Address used in the IPv6 header of the multicast packet, a mobile
       node that tunnels a multicast packet to its home agent MUST use
       its home address as the IPv6 Source Address of the inner
       multicast packet.

   Note that direct sending from the foreign link is only applicable
   while the mobile node is at that foreign link.  This is because the
   associated multicast tree is specific to that source location and any
   change of location and source address will invalidate the source
   specific tree or branch and the application context of the other
   multicast group members.

   This specification does not provide mechanisms to enable such local
   multicast session to survive hand-off and to seamlessly continue from
   a new care-of address on each new foreign link.  Any such mechanism,
   developed as an extension to this specification, needs to take into
   account the impact of fast moving mobile nodes on the Internet
   multicast routing protocols and their ability to maintain the
   integrity of source specific multicast trees and branches.

   While the use of bidirectional tunneling can ensure that multicast
   trees are independent of the mobile nodes movement, in some case such
   tunneling can have adverse affects.  The latency of specific types of
   multicast applications (such as multicast based discovery protocols)
   will be affected when the round-trip time between the foreign subnet
   and the home agent is significant compared to that of the topology to
   be discovered.  In addition, the delivery tree from the home agent in
   such circumstances relies on unicast encapsulation from the agent to
   the mobile node.  Therefore, bandwidth usage is inefficient compared
   to the native multicast forwarding in the foreign multicast system.

11.3.5. Receiving ICMP Error Messages

Any node that does not recognize the Mobility header will return an ICMP Parameter Problem, Code 1, message to the sender of the packet. If the mobile node receives such an ICMP error message in response to a return routability procedure or Binding Update, it SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination. Such Binding Update List entries SHOULD be removed after a period of time in order to allow for retrying route optimization. New Binding Update List entries MUST NOT be created as a result of receiving ICMP error messages.
ToP   noToC   RFC3775 - Page 116
   Correspondent nodes that have participated in the return routability
   procedure MUST implement the ability to correctly process received
   packets containing a Home Address destination option.  Therefore,
   correctly implemented correspondent nodes should always be able to
   recognize Home Address options.  If a mobile node receives an ICMP
   Parameter Problem, Code 2, message from some node indicating that it
   does not support the Home Address option, the mobile node SHOULD log
   the error and then discard the ICMP message.

11.3.6. Receiving Binding Error Messages

When a mobile node receives a packet containing a Binding Error message, it should first check if the mobile node has a Binding Update List entry for the source of the Binding Error message. If the mobile node does not have such an entry, it MUST ignore the message. This is necessary to prevent a waste of resources on, e.g., return routability procedure due to spoofed Binding Error messages. Otherwise, if the message Status field was 1 (unknown binding for Home Address destination option), the mobile node should perform one of the following two actions: o If the mobile node has recent upper layer progress information, which indicates that communications with the correspondent node are progressing, it MAY ignore the message. This can be done in order to limit the damage that spoofed Binding Error messages can cause to ongoing communications. o If the mobile node has no upper layer progress information, it MUST remove the entry and route further communications through the home agent. It MAY also optionally start a return routability procedure (see Section 5.2). If the message Status field was 2 (unrecognized MH Type value), the mobile node should perform one of the following two actions: o If the mobile node is not expecting an acknowledgement or response from the correspondent node, the mobile node SHOULD ignore this message. o Otherwise, the mobile node SHOULD cease the use of any extensions to this specification. If no extensions had been used, the mobile node should cease the attempt to use route optimization.
ToP   noToC   RFC3775 - Page 117

11.4. Home Agent and Prefix Management

11.4.1. Dynamic Home Agent Address Discovery

Sometimes when the mobile node needs to send a Binding Update to its home agent to register its new primary care-of address, as described in Section 11.7.1, the mobile node may not know the address of any router on its home link that can serve as a home agent for it. For example, some nodes on its home link may have been reconfigured while the mobile node has been away from home, such that the router that was operating as the mobile node's home agent has been replaced by a different router serving this role. In this case, the mobile node MAY attempt to discover the address of a suitable home agent on its home link. To do so, the mobile node sends an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its home subnet prefix. As described in Section 10.5, the home agent on its home link that receives this Request message will return an ICMP Home Agent Address Discovery Reply message. This message gives the addresses for the home agents operating on the home link. The mobile node, upon receiving this Home Agent Address Discovery Reply message, MAY then send its home registration Binding Update to any of the unicast IP addresses listed in the Home Agent Addresses field in the Reply. For example, the mobile node MAY attempt its home registration to each of these addresses, in turn, until its registration is accepted. The mobile node sends a Binding Update to an address and waits for the matching Binding Acknowledgement, moving on to the next address if there is no response. The mobile node MUST, however, wait at least InitialBindackTimeoutFirstReg seconds (see Section 13) before sending a Binding Update to the next home agent. In trying each of the returned home agent addresses, the mobile node SHOULD try each of them in the order they appear in the Home Agent Addresses field in the received Home Agent Address Discovery Reply message. If the mobile node has a current registration with some home agent (the Lifetime for that registration has not yet expired), then the mobile node MUST attempt any new registration first with that home agent. If that registration attempt fails (e.g., timed out or rejected), the mobile node SHOULD then reattempt this registration with another home agent. If the mobile node knows of no other suitable home agent, then it MAY attempt the dynamic home agent address discovery mechanism described above.
ToP   noToC   RFC3775 - Page 118
   If, after a mobile node transmits a Home Agent Address Discovery
   Request message to the Home Agents Anycast address, it does not
   receive a corresponding Home Agent Address Discovery Reply message
   within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile
   node MAY retransmit the same Request message to the same anycast
   address.  This retransmission MAY be repeated up to a maximum of
   DHAAD_RETRIES (see Section 12) attempts.  Each retransmission MUST be
   delayed by twice the time interval of the previous retransmission.

11.4.2. Sending Mobile Prefix Solicitations

When a mobile node has a home address that is about to become invalid, it SHOULD send a Mobile Prefix Solicitation to its home agent in an attempt to acquire fresh routing prefix information. The new information also enables the mobile node to participate in renumbering operations affecting the home network, as described in Section 10.6. The mobile node MUST use the Home Address destination option to carry its home address. The mobile node MUST support and SHOULD use IPsec to protect the solicitation. The mobile node MUST set the Identifier field in the ICMP header to a random value. As described in Section 11.7.2, Binding Updates sent by the mobile node to other nodes MUST use a lifetime no greater than the remaining lifetime of its home registration of its primary care-of address. The mobile node SHOULD further limit the lifetimes that it sends on any Binding Updates to be within the remaining valid lifetime (see Section 10.6.2) for the prefix in its home address. When the lifetime for a changed prefix decreases, and the change would cause cached bindings at correspondent nodes in the Binding Update List to be stored past the newly shortened lifetime, the mobile node MUST issue a Binding Update to all such correspondent nodes. These limits on the binding lifetime serve to prohibit use of a mobile node's home address after it becomes invalid.

11.4.3. Receiving Mobile Prefix Advertisements

Section 10.6 describes the operation of a home agent to support boot time configuration and renumbering a mobile node's home subnet while the mobile node is away from home. The home agent sends Mobile Prefix Advertisements to the mobile node while away from home, giving "important" Prefix Information options that describe changes in the prefixes in use on the mobile node's home link.
ToP   noToC   RFC3775 - Page 119
   The Mobile Prefix Solicitation is similar to the Router Solicitation
   used in Neighbor Discovery [12], except it is routed from the mobile
   node on the visited network to the home agent on the home network by
   usual unicast routing rules.

   When a mobile node receives a Mobile Prefix Advertisement, it MUST
   validate it according to the following test:

   o  The Source Address of the IP packet carrying the Mobile Prefix
      Advertisement is the same as the home agent address to which the
      mobile node last sent an accepted home registration Binding Update
      to register its primary care-of address.  Otherwise, if no such
      registrations have been made, it SHOULD be the mobile node's
      stored home agent address, if one exists.  Otherwise, if the
      mobile node has not yet discovered its home agent's address, it
      MUST NOT accept Mobile Prefix Advertisements.

   o  The packet MUST have a type 2 routing header and SHOULD be
      protected by an IPsec header as described in Section 5.4 and
      Section 6.8.

   o  If the ICMP Identifier value matches the ICMP Identifier value of
      the most recently sent Mobile Prefix Solicitation and no other
      advertisement has yet been received for this value, then the
      advertisement is considered to be solicited and will be processed
      further.

      Otherwise, the advertisement is unsolicited, and MUST be
      discarded.  In this case the mobile node SHOULD send a Mobile
      Prefix Solicitation.

   Any received Mobile Prefix Advertisement not meeting these tests MUST
   be silently discarded.

   For an accepted Mobile Prefix Advertisement, the mobile node MUST
   process Managed Address Configuration (M), Other Stateful
   Configuration (O), and the Prefix Information Options as if they
   arrived in a Router Advertisement [12] on the mobile node's home
   link.  (This specification does not, however, describe how to acquire
   home addresses through stateful protocols.)  Such processing may
   result in the mobile node configuring a new home address, although
   due to separation between preferred lifetime and valid lifetime, such
   changes should not affect most communications by the mobile node, in
   the same way as for nodes that are at home.

   This specification assumes that any security associations and
   security policy entries that may be needed for new prefixes have been
   pre-configured in the mobile node.  Note that while dynamic key
ToP   noToC   RFC3775 - Page 120
   management avoids the need to create new security associations, it is
   still necessary to add policy entries to protect the communications
   involving the home address(es).  Mechanisms for automatic set-up of
   these entries are outside the scope of this specification.

11.5. Movement

11.5.1. Movement Detection

The primary goal of movement detection is to detect L3 handovers. This section does not attempt to specify a fast movement detection algorithm which will function optimally for all types of applications, link-layers and deployment scenarios; instead, it describes a generic method that uses the facilities of IPv6 Neighbor Discovery, including Router Discovery and Neighbor Unreachability Detection. At the time of this writing, this method is considered well enough understood to recommend for standardization, however it is expected that future versions of this specification or other specifications may contain updated versions of the movement detection algorithm that have better performance. Generic movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bi-directionally reachable, in which case the mobile node must discover a new default router (usually on a new link). However, this detection only occurs when the mobile node has packets to send, and in the absence of frequent Router Advertisements or indications from the link-layer, the mobile node might become unaware of an L3 handover that occurred. Therefore, the mobile node should supplement this method with other information whenever it is available to the mobile node (e.g., from lower protocol layers). When the mobile node detects an L3 handover, it performs Duplicate Address Detection [13] on its link-local address, selects a new default router as a consequence of Router Discovery, and then performs Prefix Discovery with that new router to form new care-of address(es) as described in Section 11.5.2. It then registers its new primary care-of address with its home agent as described in Section 11.7.1. After updating its home registration, the mobile node then updates associated mobility bindings in correspondent nodes that it is performing route optimization with as specified in Section 11.7.2. Due to the temporary packet flow disruption and signaling overhead involved in updating mobility bindings, the mobile node should avoid performing an L3 handover until it is strictly necessary. Specifically, when the mobile node receives a Router Advertisement from a new router that contains a different set of on-link prefixes,
ToP   noToC   RFC3775 - Page 121
   if the mobile node detects that the currently selected default router
   on the old link is still bi-directionally reachable, it should
   generally continue to use the old router on the old link rather than
   switch away from it to use a new default router.

   Mobile nodes can use the information in received Router
   Advertisements to detect L3 handovers.  In doing so the mobile node
   needs to consider the following issues:

   o  There might be multiple routers on the same link, thus hearing a
      new router does not necessarily constitute an L3 handover.

   o  When there are multiple routers on the same link they might
      advertise different prefixes.  Thus even hearing a new router with
      a new prefix might not be a reliable indication of an L3 handover.

   o  The link-local addresses of routers are not globally unique, hence
      after completing an L3 handover the mobile node might continue to
      receive Router Advertisements with the same link-local source
      address.  This might be common if routers use the same link-local
      address on multiple interfaces.  This issue can be avoided when
      routers use the Router Address (R) bit, since that provides a
      global address of the router.

   In addition, the mobile node should consider the following events as
   indications that an L3 handover may have occurred.  Upon receiving
   such indications, the mobile node needs to perform Router Discovery
   to discover routers and prefixes on the new link, as described in
   Section 6.3.7 of RFC 2461 [12].

   o  If Router Advertisements that the mobile node receives include an
      Advertisement Interval option, the mobile node may use its
      Advertisement Interval field as an indication of the frequency
      with which it should expect to continue to receive future
      Advertisements from that router.  This field specifies the minimum
      rate (the maximum amount of time between successive
      Advertisements) that the mobile node should expect.  If this
      amount of time elapses without the mobile node receiving any
      Advertisement from this router, the mobile node can be sure that
      at least one Advertisement sent by the router has been lost.  The
      mobile node can then implement its own policy to determine how
      many lost Advertisements from its current default router
      constitute an L3 handover indication.

   o  Neighbor Unreachability Detection determines that the default
      router is no longer reachable.
ToP   noToC   RFC3775 - Page 122
   o  With some types of networks, notification that an L2 handover has
      occurred might be obtained from lower layer protocols or device
      driver software within the mobile node.  While further details
      around handling L2 indications as movement hints is an item for
      further study, at the time of writing this specification the
      following is considered reasonable:

      An L2 handover indication may or may not imply L2 movement and L2
      movement may or may not imply L3 movement; the correlations might
      be a function of the type of L2 but might also be a function of
      actual deployment of the wireless topology.

      Unless it is well-known that an L2 handover indication is likely
      to imply L3 movement, instead of immediately multicasting a router
      solicitation it may be better to attempt to verify whether the
      default router is still bi-directionally reachable.  This can be
      accomplished by sending a unicast Neighbor Solicitation and
      waiting for a Neighbor Advertisement with the solicited flag set.
      Note that this is similar to Neighbor Unreachability detection but
      it does not have the same state machine, such as the STALE state.

      If the default router does not respond to the Neighbor
      Solicitation it makes sense to proceed to multicasting a Router
      Solicitation.

11.5.2. Forming New Care-of Addresses

After detecting that it has moved a mobile node SHOULD generate a new primary care-of address using normal IPv6 mechanisms. This SHOULD also be done when the current primary care-of address becomes deprecated. A mobile node MAY form a new primary care-of address at any time, but a mobile node MUST NOT send a Binding Update about a new care-of address to its home agent more than MAX_UPDATE_RATE times within a second. In addition, a mobile node MAY form new non-primary care-of addresses even when it has not switched to a new default router. A mobile node can have only one primary care-of address at a time (which is registered with its home agent), but it MAY have an additional care- of address for any or all of the prefixes on its current link. Furthermore, since a wireless network interface may actually allow a mobile node to be reachable on more than one link at a time (i.e., within wireless transmitter range of routers on more than one separate link), a mobile node MAY have care-of addresses on more than one link at a time. The use of more than one care-of address at a time is described in Section 11.5.3.
ToP   noToC   RFC3775 - Page 123
   As described in Section 4, in order to form a new care-of address, a
   mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6
   [29]) Address Autoconfiguration.  If a mobile node needs to use a
   source address (other than the unspecified address) in packets sent
   as a part of address autoconfiguration, it MUST use an IPv6 link-
   local address rather than its own IPv6 home address.

   RFC 2462 [13] specifies that in normal processing for Duplicate
   Address Detection, the node SHOULD delay sending the initial Neighbor
   Solicitation message by a random delay between 0 and
   MAX_RTR_SOLICITATION_DELAY.  Since delaying DAD can result in
   significant delays in configuring a new care-of address when the
   Mobile Node moves to a new link, the Mobile Node preferably SHOULD
   NOT delay DAD when configuring a new care-of address.  The Mobile
   Node SHOULD delay according to the mechanisms specified in RFC 2462
   unless the implementation has a behavior that desynchronizes the
   steps that happen before the DAD in the case that multiple nodes
   experience handover at the same time.  Such desynchronizing behaviors
   might be due to random delays in the L2 protocols or device drivers,
   or due to the movement detection mechanism that is used.

11.5.3. Using Multiple Care-of Addresses

As described in Section 11.5.2, a mobile node MAY use more than one care-of address at a time. Particularly in the case of many wireless networks, a mobile node effectively might be reachable through multiple links at the same time (e.g., with overlapping wireless cells), on which different on-link subnet prefixes may exist. The mobile node MUST ensure that its primary care-of address always has a prefix that is advertised by its current default router. After selecting a new primary care-of address, the mobile node MUST send a Binding Update containing that care-of address to its home agent. The Binding Update MUST have the Home Registration (H) and Acknowledge (A) bits set its home agent, as described on Section 11.7.1. To assist with smooth handovers, a mobile node SHOULD retain its previous primary care-of address as a (non-primary) care-of address, and SHOULD still accept packets at this address, even after registering its new primary care-of address with its home agent. This is reasonable, since the mobile node could only receive packets at its previous primary care-of address if it were indeed still connected to that link. If the previous primary care-of address was allocated using stateful Address Autoconfiguration [29], the mobile node may not wish to release the address immediately upon switching to a new primary care-of address.
ToP   noToC   RFC3775 - Page 124
   Whenever a mobile node determines that it is no longer reachable
   through a given link, it SHOULD invalidate all care-of addresses
   associated with address prefixes that it discovered from routers on
   the unreachable link which are not in the current set of address
   prefixes advertised by the (possibly new) current default router.

11.5.4. Returning Home

A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In this home registration, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the Lifetime field to zero, and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its home address as the source address in the Binding Update. When sending this Binding Update to its home agent, the mobile node must be careful in how it uses Neighbor Solicitation [12] (if needed) to learn the home agent's link-layer address, since the home agent will be currently configured to intercept packets to the mobile node's home address using Duplicate Address Detection (DAD). In particular, the mobile node is unable to use its home address as the Source Address in the Neighbor Solicitation until the home agent stops defending the home address. Neighbor Solicitation by the mobile node for the home agent's address will normally not be necessary, since the mobile node has already learned the home agent's link-layer address from a Source Link-Layer Address option in a Router Advertisement. However, if there are multiple home agents it may still be necessary to send a solicitation. In this special case of the mobile node returning home, the mobile node MUST multicast the packet, and in addition set the Source Address of this Neighbor Solicitation to the unspecified address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation MUST be set to the mobile node's home address. The destination IP address MUST be set to the Solicited-Node multicast address [3]. The home agent will send a multicast Neighbor Advertisement back to the mobile node with the Solicited flag (S) set to zero. In any case, the mobile node SHOULD record the information from the Source Link- Layer Address option or from the advertisement, and set the state of the Neighbor Cache entry for the home agent to REACHABLE. The mobile node then sends its Binding Update to the home agent's link-layer address, instructing its home agent to no longer serve as a home agent for it. By processing this Binding Update, the home
ToP   noToC   RFC3775 - Page 125
   agent will cease defending the mobile node's home address for
   Duplicate Address Detection and will no longer respond to Neighbor
   Solicitations for the mobile node's home address.  The mobile node is
   then the only node on the link receiving packets at the mobile node's
   home address.  In addition, when returning home prior to the
   expiration of a current binding for its home address, and configuring
   its home address on its network interface on its home link, the
   mobile node MUST NOT perform Duplicate Address Detection on its own
   home address, in order to avoid confusion or conflict with its home
   agent's use of the same address.  This rule also applies to the
   derived link-local address of the mobile node, if the Link Local
   Address Compatibility (L) bit was set when the binding was created.
   If the mobile node returns home after the bindings for all of its
   care-of addresses have expired, then it SHOULD perform DAD.

   After the Mobile Node sends the Binding Update, it MUST be prepared
   to reply to Neighbor Solicitations for its home address.  Such
   replies MUST be sent using a unicast Neighbor Advertisement to the
   sender's link-layer address.  It is necessary to reply, since sending
   the Binding Acknowledgement from the home agent may require
   performing Neighbor Discovery, and the mobile node may not be able to
   distinguish Neighbor Solicitations coming from the home agent from
   other Neighbor Solicitations.  Note that a race condition exists
   where both the mobile node and the home agent respond to the same
   solicitations sent by other nodes; this will be only temporary,
   however, until the Binding Update is accepted.

   After receiving the Binding Acknowledgement for its Binding Update to
   its home agent, the mobile node MUST multicast onto the home link (to
   the all-nodes multicast address) a Neighbor Advertisement [12], to
   advertise the mobile node's own link-layer address for its own home
   address.  The Target Address in this Neighbor Advertisement MUST be
   set to the mobile node's home address, and the Advertisement MUST
   include a Target Link-layer Address option specifying the mobile
   node's link-layer address.  The mobile node MUST multicast such a
   Neighbor Advertisement for each of its home addresses, as defined by
   the current on-link prefixes, including its link-local address and
   site-local address.  The Solicited Flag (S) in these Advertisements
   MUST NOT be set, since they were not solicited by any Neighbor
   Solicitation.  The Override Flag (O) in these Advertisements MUST be
   set, indicating that the Advertisements SHOULD override any existing
   Neighbor Cache entries at any node receiving them.

   Since multicasting on the local link (such as Ethernet) is typically
   not guaranteed to be reliable, the mobile node MAY retransmit these
   Neighbor Advertisements [12] up to MAX_NEIGHBOR_ADVERTISEMENT times
   to increase their reliability.  It is still possible that some nodes
ToP   noToC   RFC3775 - Page 126
   on the home link will not receive any of these Neighbor
   Advertisements, but these nodes will eventually be able to recover
   through use of Neighbor Unreachability Detection [12].

   Note that the tunnel via the home agent typically stops operating at
   the same time that the home registration is deleted.

11.6. Return Routability Procedure

This section defines the rules that the mobile node must follow when performing the return routability procedure. Section 11.7.2 describes the rules when the return routability procedure needs to be initiated.

11.6.1. Sending Test Init Messages

A mobile node that initiates a return routability procedure MUST send (in parallel) a Home Test Init message and a Care-of Test Init messages. However, if the mobile node has recently received (see Section 5.2.7) one or both home or care-of keygen tokens, and associated nonce indices for the desired addresses, it MAY reuse them. Therefore, the return routability procedure may in some cases be completed with only one message pair. It may even be completed without any messages at all, if the mobile node has a recent home keygen token and has previously visited the same care-of address so that it also has a recent care-of keygen token. If the mobile node intends to send a Binding Update with the Lifetime set to zero and the care-of address equal to its home address - such as when returning home - sending a Home Test Init message is sufficient. In this case, generation of the binding management key depends exclusively on the home keygen token (Section 5.2.5). A Home Test Init message MUST be created as described in Section 6.1.3. A Care-of Test Init message MUST be created as described in Section 6.1.4. When sending a Home Test Init or Care-of Test Init message the mobile node MUST record in its Binding Update List the following fields from the messages: o The IP address of the node to which the message was sent. o The home address of the mobile node. This value will appear in the Source Address field of the Home Test Init message. When sending the Care-of Test Init message, this address does not appear in the message, but represents the home address for which the binding is desired.
ToP   noToC   RFC3775 - Page 127
   o  The time at which each of these messages was sent.

   o  The cookies used in the messages.

   Note that a single Care-of Test Init message may be sufficient even
   when there are multiple home addresses.  In this case the mobile node
   MAY record the same information in multiple Binding Update List
   entries.

11.6.2. Receiving Test Messages

Upon receiving a packet carrying a Home Test message, a mobile node MUST validate the packet according to the following tests: o The Source Address of the packet belongs to a correspondent node for which the mobile node has a Binding Update List entry with a state indicating that return routability procedure is in progress. Note that there may be multiple such entries. o The Binding Update List indicates that no home keygen token has been received yet. o The Destination Address of the packet has the home address of the mobile node, and the packet has been received in a tunnel from the home agent. o The Home Init Cookie field in the message matches the value stored in the Binding Update List. Any Home Test message not satisfying all of these tests MUST be silently ignored. Otherwise, the mobile node MUST record the Home Nonce Index and home keygen token in the Binding Update List. If the Binding Update List entry does not have a care-of keygen token, the mobile node SHOULD continue waiting for the Care-of Test message. Upon receiving a packet carrying a Care-of Test message, a mobile node MUST validate the packet according to the following tests: o The Source Address of the packet belongs to a correspondent node for which the mobile node has a Binding Update List entry with a state indicating that return routability procedure is in progress. Note that there may be multiple such entries. o The Binding Update List indicates that no care-of keygen token has been received yet. o The Destination Address of the packet is the current care-of address of the mobile node.
ToP   noToC   RFC3775 - Page 128
   o  The Care-of Init Cookie field in the message matches the value
      stored in the Binding Update List.

   Any Care-of Test message not satisfying all of these tests MUST be
   silently ignored.  Otherwise, the mobile node MUST record the Care-of
   Nonce Index and care-of keygen token in the Binding Update List.  If
   the Binding Update List entry does not have a home keygen token, the
   mobile node SHOULD continue waiting for the Home Test message.

   If after receiving either the Home Test or the Care-of Test message
   and performing the above actions, the Binding Update List entry has
   both the home and the care-of keygen tokens, the return routability
   procedure is complete.  The mobile node SHOULD then proceed with
   sending a Binding Update as described in Section 11.7.2.

   Correspondent nodes from the time before this specification was
   published may not support the Mobility Header protocol.  These nodes
   will respond to Home Test Init and Care-of Test Init messages with an
   ICMP Parameter Problem code 1.  The mobile node SHOULD take such
   messages as an indication that the correspondent node cannot provide
   route optimization, and revert back to the use of bidirectional
   tunneling.

11.6.3. Protecting Return Routability Packets

The mobile node MUST support the protection of Home Test and Home Test Init messages as described in Section 10.4.6. When IPsec is used to protect return routability signaling or payload packets, the mobile node MUST set the source address it uses for the outgoing tunnel packets to the current primary care-of address. The mobile node starts to use a new primary care-of address immediately after sending a Binding Update to the home agent to register this new address.

11.7. Processing Bindings

11.7.1. Sending Binding Updates to the Home Agent

After deciding to change its primary care-of address as described in Section 11.5.1 and Section 11.5.2, a mobile node MUST register this care-of address with its home agent in order to make this its primary care-of address. Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node should send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. However, if the
ToP   noToC   RFC3775 - Page 129
   home agent returned a Binding Acknowledgement for the current
   registration with Status field set to 1 (accepted but prefix
   discovery necessary), the mobile node should not try to register
   again before it has learned the validity of its home prefixes through
   mobile prefix discovery.  This is typically necessary every time this
   Status value is received, because information learned earlier may
   have changed.

   To register a care-of address or to extend the lifetime of an
   existing registration, the mobile node sends a packet to its home
   agent containing a Binding Update, with the packet constructed as
   follows:

   o  The Home Registration (H) bit MUST be set in the Binding Update.

   o  The Acknowledge (A) bit MUST be set in the Binding Update.

   o  The packet MUST contain a Home Address destination option, giving
      the mobile node's home address for the binding.

   o  The care-of address for the binding MUST be used as the Source
      Address in the packet's IPv6 header, unless an Alternate Care-of
      Address mobility option is included in the Binding Update.  This
      option MUST be included in all home registrations, as the ESP
      protocol will not be able to protect care-of addresses in the IPv6
      header.  (Mobile IPv6 implementations that know they are using
      IPsec AH to protect a particular message might avoid this option.
      For brevity the usage of AH is not discussed in this document.)

   o  If the mobile node's link-local address has the same interface
      identifier as the home address for which it is supplying a new
      care-of address, then the mobile node SHOULD set the Link-Local
      Address Compatibility (L) bit.

   o  If the home address was generated using RFC 3041 [18], then the
      link local address is unlikely to have a compatible interface
      identifier.  In this case, the mobile node MUST clear the Link-
      Local Address Compatibility (L) bit.

   o  If the IPsec security associations between the mobile node and the
      home agent have been established dynamically, and the mobile node
      has the capability to update its endpoint in the used key
      management protocol to the new care-of address every time it
      moves, the mobile node SHOULD set the Key Management Mobility
      Capability (K) bit in the Binding Update.  Otherwise, the mobile
      node MUST clear the bit.
ToP   noToC   RFC3775 - Page 130
   o  The value specified in the Lifetime field MUST be non-zero and
      SHOULD be less than or equal to the remaining valid lifetime of
      the home address and the care-of address specified for the
      binding.

      Mobile nodes that use dynamic home agent address discovery should
      be careful with long lifetimes.  If the mobile node loses the
      knowledge of its binding with a specific home agent, registering a
      new binding with another home agent may be impossible as the
      previous home agent is still defending the existing binding.
      Therefore, to ensure that mobile nodes using home agent address
      discovery do not lose information about their binding, they SHOULD
      de-register before losing this information, or use small
      lifetimes.

   The Acknowledge (A) bit in the Binding Update requests the home agent
   to return a Binding Acknowledgement in response to this Binding
   Update.  As described in Section 6.1.8, the mobile node SHOULD
   retransmit this Binding Update to its home agent until it receives a
   matching Binding Acknowledgement.  Once reaching a retransmission
   timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart
   the process of delivering the Binding Update, but trying instead the
   next home agent returned during dynamic home agent address discovery
   (see Section 11.4.1).  If there was only one home agent, the mobile
   node instead SHOULD continue to periodically retransmit the Binding
   Update at this rate until acknowledged (or until it begins attempting
   to register a different primary care-of address).  See Section 11.8
   for information about retransmitting Binding Updates.

   With the Binding Update, the mobile node requests the home agent to
   serve as the home agent for the given home address.  Until the
   lifetime of this registration expires, the home agent considers
   itself the home agent for this home address.

   Each Binding Update MUST be authenticated as coming from the right
   mobile node, as defined in Section 5.1.  The mobile node MUST use its
   home address - either in the Home Address destination option or in
   the Source Address field of the IPv6 header - in Binding Updates sent
   to the home agent.  This is necessary in order to allow the IPsec
   policies to be matched with the correct home address.

   When sending a Binding Update to its home agent, the mobile node MUST
   also create or update the corresponding Binding Update List entry, as
   specified in Section 11.7.2.

   The last Sequence Number value sent to the home agent in a Binding
   Update is stored by the mobile node.  If the sending mobile node has
   no knowledge of the correct Sequence Number value, it may start at
ToP   noToC   RFC3775 - Page 131
   any value.  If the home agent rejects the value, it sends back a
   Binding Acknowledgement with a status code 135, and the last accepted
   sequence number in the Sequence Number field of the Binding
   Acknowledgement.  The mobile node MUST store this information and use
   the next Sequence Number value for the next Binding Update it sends.

   If the mobile node has additional home addresses, then the mobile
   node SHOULD send an additional packet containing a Binding Update to
   its home agent to register the care-of address for each such other
   home address.

   The home agent will only perform DAD for the mobile node's home
   address when the mobile node has supplied a valid binding between its
   home address and a care-of address.  If some time elapses during
   which the mobile node has no binding at the home agent, it might be
   possible for another node to autoconfigure the mobile node's home
   address.  Therefore, the mobile node MUST treat the creation of a new
   binding with the home agent using an existing home address, the same
   as creation of a new home address.  In the unlikely event that the
   mobile node's home address is autoconfigured as the IPv6 address of
   another network node on the home network, the home agent will reply
   to the mobile node's subsequent Binding Update with a Binding
   Acknowledgement containing a Status of 134 (Duplicate Address
   Detection failed).  In this case, the mobile node MUST NOT attempt to
   re-use the same home address.  It SHOULD continue to register the
   care-of addresses for its other home addresses, if any.  (Mechanisms
   outlined in Appendix B.5 may in the future allow mobile nodes to
   acquire new home addresses to replace the one for which Status 134
   was received.)

11.7.2. Correspondent Registration

When the mobile node is assured that its home address is valid, it can initiate a correspondent registration with the purpose of allowing the correspondent node to cache the mobile node's current care-of address. This procedure consists of the return routability procedure followed by a registration. This section defines when the correspondent registration is to be initiated and the rules to follow while it is being performed. After the mobile node has sent a Binding Update to its home agent, registering a new primary care-of address (as described in Section 11.7.1), the mobile node SHOULD initiate a correspondent registration for each node that already appears in the mobile node's Binding Update List. The initiated procedures can be used to either update or delete binding information in the correspondent node.
ToP   noToC   RFC3775 - Page 132
   For nodes that do not appear in the mobile node's Binding Update
   List, the mobile node MAY initiate a correspondent registration at
   any time after sending the Binding Update to its home agent.

   Considerations regarding when (and if) to initiate the procedure
   depend on the specific movement and traffic patterns of the mobile
   node and are outside the scope of this document.

   In addition, the mobile node MAY initiate the correspondent
   registration in response to receiving a packet that meets all of the
   following tests:

   o  The packet was tunneled using IPv6 encapsulation.

   o  The Destination Address in the tunnel (outer) IPv6 header is equal
      to any of the mobile node's care-of addresses.

   o  The Destination Address in the original (inner) IPv6 header is
      equal to one of the mobile node's home addresses.

   o  The Source Address in the tunnel (outer) IPv6 header differs from
      the Source Address in the original (inner) IPv6 header.

   o  The packet does not contain a Home Test, Home Test Init, Care-of
      Test, or Care-of Test Init message.

   If a mobile node has multiple home addresses, it becomes important to
   select the right home address to use in the correspondent
   registration.  The used home address MUST be the Destination Address
   of the original (inner) packet.

   The peer address used in the procedure MUST be determined as follows:

   o  If a Home Address destination option is present in the original
      (inner) packet, the address from this option is used.

   o  Otherwise, the Source Address in the original (inner) IPv6 header
      of the packet is used.

   Note that the validity of the original packet is checked before
   attempting to initiate a correspondent registration.  For instance,
   if a Home Address destination option appeared in the original packet,
   then rules in Section 9.3.1 are followed.

   A mobile node MAY also choose to keep its topological location
   private from certain correspondent nodes, and thus need not initiate
   the correspondent registration.
ToP   noToC   RFC3775 - Page 133
   Upon successfully completing the return routability procedure, and
   after receiving a successful Binding Acknowledgement from the Home
   Agent, a Binding Update MAY be sent to the correspondent node.

   In any Binding Update sent by a mobile node, the care-of address
   (either the Source Address in the packet's IPv6 header or the Care-of
   Address in the Alternate Care-of Address mobility option of the
   Binding Update) MUST be set to one of the care-of addresses currently
   in use by the mobile node or to the mobile node's home address.  A
   mobile node MAY set the care-of address differently for sending
   Binding Updates to different correspondent nodes.

   A mobile node MAY also send a Binding Update to such a correspondent
   node, instructing it to delete any existing binding for the mobile
   node from its Binding Cache, as described in Section 6.1.7.  Even in
   this case a successful completion of the return routability procedure
   is required first.

   If the care-of address is not set to the mobile node's home address,
   the Binding Update requests that the correspondent node create or
   update an entry for the mobile node in the correspondent node's
   Binding Cache.  This is done in order to record a care-of address for
   use in sending future packets to the mobile node.  In this case, the
   value specified in the Lifetime field sent in the Binding Update
   SHOULD be less than or equal to the remaining lifetime of the home
   registration and the care-of address specified for the binding.  The
   care-of address given in the Binding Update MAY differ from the
   mobile node's primary care-of address.

   If the Binding Update is sent to the correspondent node, requesting
   the deletion of any existing Binding Cache entry it has for the
   mobile node, the care-of address is set to the mobile node's home
   address and the Lifetime field set to zero.  In this case, generation
   of the binding management key depends exclusively on the home keygen
   token (Section 5.2.5).  The care-of nonce index SHOULD be set to zero
   in this case.  In keeping with the Binding Update creation rules
   below, the care-of address MUST be set to the home address if the
   mobile node is at home, or to the current care-of address if it is
   away from home.

   If the mobile node wants to ensure that its new care-of address has
   been entered into a correspondent node's Binding Cache, the mobile
   node needs to request an acknowledgement by setting the Acknowledge
   (A) bit in the Binding Update.
ToP   noToC   RFC3775 - Page 134
   A Binding Update is created as follows:

   o  The current care-of address of the mobile node MUST be sent either
      in the Source Address of the IPv6 header, or in the Alternate
      Care-of Address mobility option.

   o  The Destination Address of the IPv6 header MUST contain the
      address of the correspondent node.

   o  The Mobility Header is constructed according to rules in Section
      6.1.7 and Section 5.2.6, including the Binding Authorization Data
      (calculated as defined in Section 6.2.7) and possibly the Nonce
      Indices mobility options.

   o  The home address of the mobile node MUST be added to the packet in
      a Home Address destination option, unless the Source Address is
      the home address.

   Each Binding Update MUST have a Sequence Number greater than the
   Sequence Number value sent in the previous Binding Update to the same
   destination address (if any).  The sequence numbers are compared
   modulo 2**16, as described in Section 9.5.1.  There is no
   requirement, however, that the Sequence Number value strictly
   increase by 1 with each new Binding Update sent or received, as long
   as the value stays within the window.  The last Sequence Number value
   sent to a destination in a Binding Update is stored by the mobile
   node in its Binding Update List entry for that destination.  If the
   sending mobile node has no Binding Update List entry, the Sequence
   Number SHOULD start at a random value.  The mobile node MUST NOT use
   the same Sequence Number in two different Binding Updates to the same
   correspondent node, even if the Binding Updates provide different
   care-of addresses.

   The mobile node is responsible for the completion of the
   correspondent registration, as well as any retransmissions that may
   be needed (subject to the rate limitation defined in Section 11.8).

11.7.3. Receiving Binding Acknowledgements

Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests: o The packet meets the authentication requirements for Binding Acknowledgements defined in Section 6.1.8 and Section 5. That is, if the Binding Update was sent to the home agent, underlying IPsec protection is used. If the Binding Update was sent to the correspondent node, the Binding Authorization Data mobility option MUST be present and have a valid value.
ToP   noToC   RFC3775 - Page 135
   o  The Binding Authorization Data mobility option, if present, MUST
      be the last option and MUST not have trailing padding.

   o  The Sequence Number field matches the Sequence Number sent by the
      mobile node to this destination address in an outstanding Binding
      Update.

   Any Binding Acknowledgement not satisfying all of these tests MUST be
   silently ignored.

   When a mobile node receives a packet carrying a valid Binding
   Acknowledgement, the mobile node MUST examine the Status field as
   follows:

   o  If the Status field indicates that the Binding Update was accepted
      (the Status field is less than 128), then the mobile node MUST
      update the corresponding entry in its Binding Update List to
      indicate that the Binding Update has been acknowledged; the mobile
      node MUST then stop retransmitting the Binding Update.  In
      addition, if the value specified in the Lifetime field in the
      Binding Acknowledgement is less than the Lifetime value sent in
      the Binding Update being acknowledged, the mobile node MUST
      subtract the difference between these two Lifetime values from the
      remaining lifetime for the binding as maintained in the
      corresponding Binding Update List entry (with a minimum value for
      the Binding Update List entry lifetime of 0).  That is, if the
      Lifetime value sent in the Binding Update was L_update, the
      Lifetime value received in the Binding Acknowledgement was L_ack,
      and the current remaining lifetime of the Binding Update List
      entry is L_remain, then the new value for the remaining lifetime
      of the Binding Update List entry should be

         max((L_remain - (L_update - L_ack)), 0)

      where max(X, Y) is the maximum of X and Y.  The effect of this
      step is to correctly manage the mobile node's view of the
      binding's remaining lifetime (as maintained in the corresponding
      Binding Update List entry) so that it correctly counts down from
      the Lifetime value given in the Binding Acknowledgement, but with
      the timer countdown beginning at the time that the Binding Update
      was sent.

      Mobile nodes SHOULD send a new Binding Update well before the
      expiration of this period in order to extend the lifetime.  This
      helps to avoid disruptions in communications which might otherwise
      be caused by network delays or clock drift.
ToP   noToC   RFC3775 - Page 136
   o  Additionally, if the Status field value is 1 (accepted but prefix
      discovery necessary), the mobile node SHOULD send a Mobile Prefix
      Solicitation message to update its information about the available
      prefixes.

   o  If the Status field indicates that the Binding Update was rejected
      (the Status field is greater than or equal to 128), then the
      mobile node can take steps to correct the cause of the error and
      retransmit the Binding Update (with a new Sequence Number value),
      subject to the rate limiting restriction specified in Section
      11.8.  If this is not done or it fails, then the mobile node
      SHOULD record in its Binding Update List that future Binding
      Updates SHOULD NOT be sent to this destination.

   The treatment of a Binding Refresh Advice mobility option within the
   Binding Acknowledgement depends on where the acknowledgement came
   from.  This option MUST be ignored if the acknowledgement came from a
   correspondent node.  If it came from the home agent, the mobile node
   uses the Refresh Interval field in the option as a suggestion that it
   SHOULD attempt to refresh its home registration at the indicated
   shorter interval.

   If the acknowledgement came from the home agent, the mobile node
   examines the value of the Key Management Mobility Capability (K) bit.
   If this bit is not set, the mobile node SHOULD discard key management
   protocol connections, if any, to the home agent.  The mobile node MAY
   also initiate a new key management connection.

   If this bit is set, the mobile node SHOULD move its own endpoint in
   the key management protocol connections to the home agent, if any.
   The mobile node's new endpoint should be the new care-of address.
   For an IKE phase 1 connection, this means that packets sent to this
   address with the original ISAKMP cookies are accepted.

11.7.4. Receiving Binding Refresh Requests

When a mobile node receives a packet containing a Binding Refresh Request message, the mobile node has a Binding Update List entry for the source of the Binding Refresh Request, and the mobile node wants to retain its binding cache entry at the correspondent node, then the mobile node should start a return routability procedure. If the mobile node wants to have its binding cache entry removed, it can either ignore the Binding Refresh Request and wait for the binding to time out, or at any time, it can delete its binding from a correspondent node with an explicit binding update with a zero lifetime and the care-of address set to the home address. If the
ToP   noToC   RFC3775 - Page 137
   mobile node does not know if it needs the binding cache entry, it can
   make the decision in an implementation dependent manner, such as
   based on available resources.

   Note that the mobile node should be careful to not respond to Binding
   Refresh Requests for addresses not in the Binding Update List to
   avoid being subjected to a denial of service attack.

   If the return routability procedure completes successfully, a Binding
   Update message SHOULD be sent, as described in Section 11.7.2.  The
   Lifetime field in this Binding Update SHOULD be set to a new
   lifetime, extending any current lifetime remaining from a previous
   Binding Update sent to this node (as indicated in any existing
   Binding Update List entry for this node), and the lifetime SHOULD
   again be less than or equal to the remaining lifetime of the home
   registration and the care-of address specified for the binding.  When
   sending this Binding Update, the mobile node MUST update its Binding
   Update List in the same way as for any other Binding Update sent by
   the mobile node.

11.8. Retransmissions and Rate Limiting

The mobile node is responsible for retransmissions and rate limiting in the return routability procedure, registrations, and in solicited prefix discovery. When the mobile node sends a Mobile Prefix Solicitation, Home Test Init, Care-of Test Init or Binding Update for which it expects a response, the mobile node has to determine a value for the initial retransmission timer: o If the mobile node is sending a Mobile Prefix Solicitation, it SHOULD use an initial retransmission interval of INITIAL_SOLICIT_TIMER (see Section 12). o If the mobile node is sending a Binding Update and does not have an existing binding at the home agent, it SHOULD use InitialBindackTimeoutFirstReg (see Section 13) as a value for the initial retransmission timer. This long retransmission interval will allow the home agent to complete the Duplicate Address Detection procedure mandated in this case, as detailed in Section 11.7.1. o Otherwise, the mobile node should use the specified value of INITIAL_BINDACK_TIMEOUT for the initial retransmission timer.
ToP   noToC   RFC3775 - Page 138
   If the mobile node fails to receive a valid matching response within
   the selected initial retransmission interval, the mobile node SHOULD
   retransmit the message until a response is received.

   The retransmissions by the mobile node MUST use an exponential back-
   off process in which the timeout period is doubled upon each
   retransmission, until either the node receives a response or the
   timeout period reaches the value MAX_BINDACK_TIMEOUT.  The mobile
   node MAY continue to send these messages at this slower rate
   indefinitely.

   The mobile node SHOULD start a separate back-off process for
   different message types, different home addresses and different
   care-of addresses.  However, in addition an overall rate limitation
   applies for messages sent to a particular correspondent node.  This
   ensures that the correspondent node has a sufficient amount of time
   to respond when bindings for multiple home addresses are registered,
   for instance.  The mobile node MUST NOT send Mobility Header messages
   of a particular type to a particular correspondent node more than
   MAX_UPDATE_RATE times within a second.

   Retransmitted Binding Updates MUST use a Sequence Number value
   greater than that used for the previous transmission of this Binding
   Update.  Retransmitted Home Test Init and Care-of Test Init messages
   MUST use new cookie values.



(page 138 continued on part 5)

Next Section