tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3775

 
 
 

Mobility Support in IPv6

Part 3 of 5, p. 69 to 105
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 69 
8.  Requirements for Types of IPv6 Nodes

   Mobile IPv6 places some special requirements on the functions
   provided by different types of IPv6 nodes.  This section summarizes
   those requirements, identifying the functionality each requirement is
   intended to support.

   The requirements are set for the following groups of nodes:

   o  All IPv6 nodes.

   o  All IPv6 nodes with support for route optimization.

   o  All IPv6 routers.

   o  All Mobile IPv6 home agents.

   o  All Mobile IPv6 mobile nodes.

   It is outside the scope of this specification to specify which of
   these groups are mandatory in IPv6.  We only describe what is
   mandatory for a node that supports, for instance, route optimization.
   Other specifications are expected to define the extent of IPv6.

8.1.  All IPv6 Nodes

   Any IPv6 node may at any time be a correspondent node of a mobile
   node, either sending a packet to a mobile node or receiving a packet
   from a mobile node.  There are no Mobile IPv6 specific MUST
   requirements for such nodes, and basic IPv6 techniques are
   sufficient.  If a mobile node attempts to set up route optimization
   with a node with only basic IPv6 support, an ICMP error will signal
   that the node does not support such optimizations (Section 11.3.5),
   and communications will flow through the home agent.

   An IPv6 node MUST NOT support the Home Address destination option,
   type 2 routing header, or the Mobility Header unless it fully
   supports the requirements listed in the next sections for either
   route optimization, mobile node, or home agent functionality.

8.2.  IPv6 Nodes with Support for Route Optimization

   Nodes that implement route optimization are a subset of all IPv6
   nodes on the Internet.  The ability of a correspondent node to
   participate in route optimization is essential for the efficient
   operation of the IPv6 Internet, for the following reasons:

Top      Up      ToC       Page 70 
   o  Avoidance of congestion in the home network, and enabling the use
      of lower-performance home agent equipment even for supporting
      thousands of mobile nodes.

   o  Reduced network load across the entire Internet, as mobile devices
      begin to predominate.

   o  Reduction of jitter and latency for the communications.

   o  Greater likelihood of success for QoS signaling as tunneling is
      avoided and, again, fewer sources of congestion.

   o  Improved robustness against network partitions, congestion, and
      other problems, since fewer routing path segments are traversed.

   These effects combine to enable much better performance and
   robustness for communications between mobile nodes and IPv6
   correspondent nodes.  Route optimization introduces a small amount of
   additional state for the peers, some additional messaging, and up to
   1.5 roundtrip delays before it can be turned on.  However, it is
   believed that the benefits far outweigh the costs in most cases.
   Section 11.3.1 discusses how mobile nodes may avoid route
   optimization for some of the remaining cases, such as very short-term
   communications.

   The following requirements apply to all correspondent nodes that
   support route optimization:

   o  The node MUST be able to validate a Home Address option using an
      existing Binding Cache entry, as described in Section 9.3.1.

   o  The node MUST be able to insert a type 2 routing header into
      packets to be sent to a mobile node, as described in Section
      9.3.2.

   o  Unless the correspondent node is also acting as a mobile node, it
      MUST ignore type 2 routing headers and silently discard all
      packets that it has received with such headers.

   o  The node SHOULD be able to interpret ICMP messages as described in
      Section 9.3.4.

   o  The node MUST be able to send Binding Error messages as described
      in Section 9.3.3.

   o  The node MUST be able to process Mobility Headers as described in
      Section 9.2.

Top      Up      ToC       Page 71 
   o  The node MUST be able to participate in a return routability
      procedure (Section 9.4).

   o  The node MUST be able to process Binding Update messages (Section
      9.5).

   o  The node MUST be able to return a Binding Acknowledgement (Section
      9.5.4).

   o  The node MUST be able to maintain a Binding Cache of the bindings
      received in accepted Binding Updates, as described in Section 9.1
      and Section 9.6.

   o  The node SHOULD allow route optimization to be administratively
      enabled or disabled.  The default SHOULD be enabled.

8.3.  All IPv6 Routers

   All IPv6 routers, even those not serving as a home agent for Mobile
   IPv6, have an effect on how well mobile nodes can communicate:

   o  Every IPv6 router SHOULD be able to send an Advertisement Interval
      option (Section 7.3) in each of its Router Advertisements [12], to
      aid movement detection by mobile nodes (as in Section 11.5.1).
      The use of this option in Router Advertisements SHOULD be
      configurable.

   o  Every IPv6 router SHOULD be able to support sending unsolicited
      multicast Router Advertisements at the faster rate described in
      Section 7.5.  If the router supports a faster rate, the used rate
      MUST be configurable.

   o  Each router SHOULD include at least one prefix with the Router
      Address (R) bit set and with its full IP address in its Router
      Advertisements (as described in Section 7.2).

   o  Routers supporting filtering packets with routing headers SHOULD
      support different rules for type 0 and type 2 routing headers (see
      Section 6.4) so that filtering of source routed packets (type 0)
      will not necessarily limit Mobile IPv6 traffic which is delivered
      via type 2 routing headers.

8.4.  IPv6 Home Agents

   In order for a mobile node to operate correctly while away from home,
   at least one IPv6 router on the mobile node's home link must function
   as a home agent for the mobile node.  The following additional
   requirements apply to all IPv6 routers that serve as a home agent:

Top      Up      ToC       Page 72 
   o  Every home agent MUST be able to maintain an entry in its Binding
      Cache for each mobile node for which it is serving as the home
      agent (Section 10.1 and Section 10.3.1).

   o  Every home agent MUST be able to intercept packets (using proxy
      Neighbor Discovery [12]) addressed to a mobile node for which it
      is currently serving as the home agent, on that mobile node's home
      link, while the mobile node is away from home (Section 10.4.1).

   o  Every home agent MUST be able to encapsulate [15] such intercepted
      packets in order to tunnel them to the primary care-of address for
      the mobile node indicated in its binding in the home agent's
      Binding Cache (Section 10.4.2).

   o  Every home agent MUST support decapsulating [15] reverse tunneled
      packets sent to it from a mobile node's home address.  Every home
      agent MUST also check that the source address in the tunneled
      packets corresponds to the currently registered location of the
      mobile node (Section 10.4.5).

   o  The node MUST be able to process Mobility Headers as described in
      Section 10.2.

   o  Every home agent MUST be able to return a Binding Acknowledgement
      in response to a Binding Update (Section 10.3.1).

   o  Every home agent MUST maintain a separate Home Agents List for
      each link on which it is serving as a home agent, as described in
      Section 10.1 and Section 10.5.1.

   o  Every home agent MUST be able to accept packets addressed to the
      Mobile IPv6 Home-Agents anycast address [16] for the subnet on
      which it is serving as a home agent, and MUST be able to
      participate in dynamic home agent address discovery (Section
      10.5).

   o  Every home agent SHOULD support a configuration mechanism to allow
      a system administrator to manually set the value to be sent by
      this home agent in the Home Agent Preference field of the Home
      Agent Information Option in Router Advertisements that it sends
      (Section 7.4).

   o  Every home agent SHOULD support sending ICMP Mobile Prefix
      Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
      Solicitations (Section 6.7).  If supported, this behavior MUST be
      configurable, so that home agents can be configured to avoid
      sending such Prefix Advertisements according to the needs of the
      network administration in the home domain.

Top      Up      ToC       Page 73 
   o  Every home agent MUST support IPsec ESP for protection of packets
      belonging to the return routability procedure (Section 10.4.6).

   o  Every home agent SHOULD support the multicast group membership
      control protocols as described in Section 10.4.3.  If this support
      is provided, the home agent MUST be capable of using it to
      determine which multicast data packets to forward via the tunnel
      to the mobile node.

   o  Home agents MAY support stateful address autoconfiguration for
      mobile nodes as described in Section 10.4.4.

8.5.  IPv6 Mobile Nodes

   Finally, the following requirements apply to all IPv6 nodes capable
   of functioning as mobile nodes:

   o  The node MUST maintain a Binding Update List (Section 11.1).

   o  The node MUST support sending packets containing a Home Address
      option (Section 11.3.1), and follow the required IPsec interaction
      (Section 11.3.2).

   o  The node MUST be able to perform IPv6 encapsulation and
      decapsulation [15].

   o  The node MUST be able to process type 2 routing header as defined
      in Section 6.4 and Section 11.3.3.

   o  The node MUST support receiving a Binding Error message (Section
      11.3.6).

   o  The node MUST support receiving ICMP errors (Section 11.3.5).

   o  The node MUST support movement detection, care-of address
      formation, and returning home (Section 11.5).

   o  The node MUST be able to process Mobility Headers as described in
      Section 11.2.

   o  The node MUST support the return routability procedure (Section
      11.6).

   o  The node MUST be able to send Binding Updates, as specified in
      Section 11.7.1 and Section 11.7.2.

   o  The node MUST be able to receive and process Binding
      Acknowledgements, as specified in Section 11.7.3.

Top      Up      ToC       Page 74 
   o  The node MUST support receiving a Binding Refresh Request (Section
      6.1.2), by responding with a Binding Update.

   o  The node MUST support receiving Mobile Prefix Advertisements
      (Section 11.4.3) and reconfiguring its home address based on the
      prefix information contained therein.

   o  The node SHOULD support use of the dynamic home agent address
      discovery mechanism, as described in Section 11.4.1.

   o  The node MUST allow route optimization to be administratively
      enabled or disabled.  The default SHOULD be enabled.

   o  The node MAY support the multicast address listener part of a
      multicast group membership protocol as described in Section
      11.3.4.  If this support is provided, the mobile node MUST be able
      to receive tunneled multicast packets from the home agent.

   o  The node MAY support stateful address autoconfiguration mechanisms
      such as DHCPv6 [29] on the interface represented by the tunnel to
      the home agent.

9.  Correspondent Node Operation

9.1.  Conceptual Data Structures

   IPv6 nodes with route optimization support maintain a Binding Cache
   of bindings for other nodes.  A separate Binding Cache SHOULD be
   maintained by each IPv6 node for each of its unicast routable
   addresses.  The Binding Cache MAY be implemented in any manner
   consistent with the external behavior described in this document, for
   example by being combined with the node's Destination Cache as
   maintained by Neighbor Discovery [12].  When sending a packet, the
   Binding Cache is searched before the Neighbor Discovery conceptual
   Destination Cache [12].

   Each Binding Cache entry conceptually contains the following fields:

   o  The home address of the mobile node for which this is the Binding
      Cache entry.  This field is used as the key for searching the
      Binding Cache for the destination address of a packet being sent.

   o  The care-of address for the mobile node indicated by the home
      address field in this Binding Cache entry.

Top      Up      ToC       Page 75 
   o  A lifetime value, indicating the remaining lifetime for this
      Binding Cache entry.  The lifetime value is initialized from the
      Lifetime field in the Binding Update that created or last modified
      this Binding Cache entry.

   o  A flag indicating whether or not this Binding Cache entry is a
      home registration entry (applicable only on nodes which support
      home agent functionality).

   o  The maximum value of the Sequence Number field received in
      previous Binding Updates for this home address.  The Sequence
      Number field is 16 bits long.  Sequence Number values MUST be
      compared modulo 2**16 as explained in Section 9.5.1.

   o  Usage information for this Binding Cache entry.  This is needed to
      implement the cache replacement policy in use in the Binding
      Cache.  Recent use of a cache entry also serves as an indication
      that a Binding Refresh Request should be sent when the lifetime of
      this entry nears expiration.

   Binding Cache entries not marked as home registrations MAY be
   replaced at any time by any reasonable local cache replacement policy
   but SHOULD NOT be unnecessarily deleted.  The Binding Cache for any
   one of a node's IPv6 addresses may contain at most one entry for each
   mobile node home address.  The contents of a node's Binding Cache
   MUST NOT be changed in response to a Home Address option in a
   received packet.

9.2.  Processing Mobility Headers

   Mobility Header processing MUST observe the following rules:

   o  The checksum must be verified as per Section 6.1.  Otherwise, the
      node MUST silently discard the message.

   o  The MH Type field MUST have a known value (Section 6.1.1).
      Otherwise, the node MUST discard the message and issue a Binding
      Error message as described in Section 9.3.3, with Status field set
      to 2 (unrecognized MH Type value).

   o  The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
      Otherwise, the node MUST discard the message and SHOULD send ICMP
      Parameter Problem, Code 0, directly to the Source Address of the
      packet as specified in RFC 2463 [14].  Thus no Binding Cache
      information is used in sending the ICMP message.  The Pointer
      field in the ICMP message SHOULD point at the Payload Proto field.

Top      Up      ToC       Page 76 
   o  The Header Len field in the Mobility Header MUST NOT be less than
      the length specified for this particular type of message in
      Section 6.1.  Otherwise, the node MUST discard the message and
      SHOULD send ICMP Parameter Problem, Code 0, directly to the Source
      Address of the packet as specified in RFC 2463 [14].  (The Binding
      Cache information is again not used.) The Pointer field in the
      ICMP message SHOULD point at the Header Len field.

      Subsequent checks depend on the particular Mobility Header.

9.3.  Packet Processing

   This section describes how the correspondent node sends packets to
   the mobile node, and receives packets from it.

9.3.1.  Receiving Packets with Home Address Option

   Packets containing a Home Address option MUST be dropped if the given
   home address is not a unicast routable address.

   Mobile nodes can include a Home Address destination option in a
   packet if they believe the correspondent node has a Binding Cache
   entry for the home address of a mobile node.  Packets containing a
   Home Address option MUST be dropped if there is no corresponding
   Binding Cache entry.  A corresponding Binding Cache entry MUST have
   the same home address as appears in the Home Address destination
   option, and the currently registered care-of address MUST be equal to
   the source address of the packet.  These tests MUST NOT be done for
   packets that contain a Home Address option and a Binding Update.

   If the packet is dropped due the above tests, the correspondent node
   MUST send the Binding Error message as described in Section 9.3.3.
   The Status field in this message should be set to 1 (unknown binding
   for Home Address destination option).

   The correspondent node MUST process the option in a manner consistent
   with exchanging the Home Address field from the Home Address option
   into the IPv6 header and replacing the original value of the Source
   Address field there.  After all IPv6 options have been processed, it
   MUST be possible for upper layers to process the packet without the
   knowledge that it came originally from a care-of address or that a
   Home Address option was used.

   The use of IPsec Authentication Header (AH) for the Home Address
   option is not required, except that if the IPv6 header of a packet is
   covered by AH, then the authentication MUST also cover the Home
   Address option; this coverage is achieved automatically by the
   definition of the Option Type code for the Home Address option, since

Top      Up      ToC       Page 77 
   it indicates that the data within the option cannot change en route
   to the packet's final destination, and thus the option is included in
   the AH computation.  By requiring that any authentication of the IPv6
   header also cover the Home Address option, the security of the Source
   Address field in the IPv6 header is not compromised by the presence
   of a Home Address option.

   When attempting to verify AH authentication data in a packet that
   contains a Home Address option, the receiving node MUST calculate the
   AH authentication data as if the following were true: The Home
   Address option contains the care-of address, and the source IPv6
   address field of the IPv6 header contains the home address.  This
   conforms with the calculation specified in Section 11.3.2.

9.3.2.  Sending Packets to a Mobile Node

   Before sending any packet, the sending node SHOULD examine its
   Binding Cache for an entry for the destination address to which the
   packet is being sent.  If the sending node has a Binding Cache entry
   for this address, the sending node SHOULD use a type 2 routing header
   to route the packet to this mobile node (the destination node) by way
   of its care-of address.  However, the sending node MUST not do this
   in the following cases:

   o  When sending an IPv6 Neighbor Discovery [12] packet.

   o  Where otherwise noted in Section 6.1.

   When calculating authentication data in a packet that contains a type
   2 routing header, the correspondent node MUST calculate the AH
   authentication data as if the following were true: The routing header
   contains the care-of address, the destination IPv6 address field of
   the IPv6 header contains the home address, and the Segments Left
   field is zero.  The IPsec Security Policy Database lookup MUST based
   on the mobile node's home address.

   For instance, assuming there are no additional routing headers in
   this packet beyond those needed by Mobile IPv6, the correspondent
   node could set the fields in the packet's IPv6 header and routing
   header as follows:

   o  The Destination Address in the packet's IPv6 header is set to the
      mobile node's home address (the original destination address to
      which the packet was being sent).

Top      Up      ToC       Page 78 
   o  The routing header is initialized to contain a single route
      segment, containing the mobile node's care-of address copied from
      the Binding Cache entry.  The Segments Left field is, however,
      temporarily set to zero.

   The IP layer will insert the routing header before performing any
   necessary IPsec processing.  Once all IPsec processing has been
   performed, the node swaps the IPv6 destination field with the Home
   Address field in the routing header, sets the Segments Left field to
   one, and sends the packet.  This ensures the AH calculation is done
   on the packet in the form it will have on the receiver after
   advancing the routing header.

   Following the definition of a type 2 routing header in Section 6.4,
   this packet will be routed to the mobile node's care-of address,
   where it will be delivered to the mobile node (the mobile node has
   associated the care-of address with its network interface).

   Note that following the above conceptual model in an implementation
   creates some additional requirements for path MTU discovery since the
   layer that decides the packet size (e.g., TCP and applications using
   UDP) needs to be aware of the size of the headers added by the IP
   layer on the sending node.

   If, instead, the sending node has no Binding Cache entry for the
   destination address to which the packet is being sent, the sending
   node simply sends the packet normally, with no routing header.  If
   the destination node is not a mobile node (or is a mobile node that
   is currently at home), the packet will be delivered directly to this
   node and processed normally by it.  If, however, the destination node
   is a mobile node that is currently away from home, the packet will be
   intercepted by the mobile node's home agent and tunneled to the
   mobile node's current primary care-of address.

9.3.3.  Sending Binding Error Messages

   Section 9.2 and Section 9.3.1 describe error conditions that lead to
   a need to send a Binding Error message.

   A Binding Error message is sent directly to the address that appeared
   in the IPv6 Source Address field of the offending packet.  If the
   Source Address field does not contain a unicast address, the Binding
   Error message MUST NOT be sent.

   The Home Address field in the Binding Error message MUST be copied
   from the Home Address field in the Home Address destination option of
   the offending packet, or set to the unspecified address if no such
   option appeared in the packet.

Top      Up      ToC       Page 79 
   Note that the IPv6 Source Address and Home Address field values
   discussed above are the values from the wire, i.e., before any
   modifications possibly performed as specified in Section 9.3.1.

   Binding Error messages SHOULD be subject to rate limiting in the same
   manner as is done for ICMPv6 messages [14].

9.3.4.  Receiving ICMP Error Messages

   When the correspondent node has a Binding Cache entry for a mobile
   node, all traffic destined to the mobile node goes directly to the
   current care-of address of the mobile node using a routing header.
   Any ICMP error message caused by packets on their way to the care-of
   address will be returned in the normal manner to the correspondent
   node.

   On the other hand, if the correspondent node has no Binding Cache
   entry for the mobile node, the packet will be routed through the
   mobile node's home link.  Any ICMP error message caused by the packet
   on its way to the mobile node while in the tunnel, will be
   transmitted to the mobile node's home agent.  By the definition of
   IPv6 encapsulation [15], the home agent MUST relay certain ICMP error
   messages back to the original sender of the packet, which in this
   case is the correspondent node.

   Thus, in all cases, any meaningful ICMP error messages caused by
   packets from a correspondent node to a mobile node will be returned
   to the correspondent node.  If the correspondent node receives
   persistent ICMP Destination Unreachable messages after sending
   packets to a mobile node based on an entry in its Binding Cache, the
   correspondent node SHOULD delete this Binding Cache entry.  Note that
   if the mobile node continues to send packets with the Home Address
   destination option to this correspondent node, they will be dropped
   due to the lack of a binding.  For this reason it is important that
   only persistent ICMP messages lead to the deletion of the Binding
   Cache entry.

9.4.  Return Routability Procedure

   This subsection specifies actions taken by a correspondent node
   during the return routability procedure.

Top      Up      ToC       Page 80 
9.4.1.  Receiving Home Test Init Messages

   Upon receiving a Home Test Init message, the correspondent node
   verifies the following:

   o  The packet MUST NOT include a Home Address destination option.

   Any packet carrying a Home Test Init message which fails to satisfy
   all of these tests MUST be silently ignored.

   Otherwise, in preparation for sending the corresponding Home Test
   Message, the correspondent node checks that it has the necessary
   material to engage in a return routability procedure, as specified in
   Section 5.2.  The correspondent node MUST have a secret Kcn and a
   nonce.  If it does not have this material yet, it MUST produce it
   before continuing with the return routability procedure.

   Section 9.4.3 specifies further processing.

9.4.2.  Receiving Care-of Test Init Messages

   Upon receiving a Care-of Test Init message, the correspondent node
   verifies the following:

   o  The packet MUST NOT include a Home Address destination option.

   Any packet carrying a Care-of Test Init message which fails to
   satisfy all of these tests MUST be silently ignored.

   Otherwise, in preparation for sending the corresponding Care-of Test
   Message, the correspondent node checks that it has the necessary
   material to engage in a return routability procedure in the manner
   described in Section 9.4.1.

   Section 9.4.4 specifies further processing.

9.4.3.  Sending Home Test Messages

   The correspondent node creates a home keygen token and uses the
   current nonce index as the Home Nonce Index.  It then creates a Home
   Test message (Section 6.1.5) and sends it to the mobile node at the
   latter's home address.

Top      Up      ToC       Page 81 
9.4.4.  Sending Care-of Test Messages

   The correspondent node creates a care-of keygen token and uses the
   current nonce index as the Care-of Nonce Index.  It then creates a
   Care-of Test message (Section 6.1.6) and sends it to the mobile node
   at the latter's care-of address.

9.5.  Processing Bindings

   This section explains how the correspondent node processes messages
   related to bindings.  These messages are:

   o  Binding Update

   o  Binding Refresh Request

   o  Binding Acknowledgement

   o  Binding Error

9.5.1.  Receiving Binding Updates

   Before accepting a Binding Update, the receiving node MUST validate
   the Binding Update according to the following tests:

   o  The packet MUST contain a unicast routable home address, either in
      the Home Address option or in the Source Address, if the Home
      Address option is not present.

   o  The Sequence Number field in the Binding Update is greater than
      the Sequence Number received in the previous valid Binding Update
      for this home address, if any.

   If the receiving node has no Binding Cache entry for the indicated
   home address, it MUST accept any Sequence Number value in a received
   Binding Update from this mobile node.

   This Sequence Number comparison MUST be performed modulo 2**16, i.e.,
   the number is a free running counter represented modulo 65536.  A
   Sequence Number in a received Binding Update is considered less than
   or equal to the last received number if its value lies in the range
   of the last received number and the preceding 32768 values,
   inclusive.  For example, if the last received sequence number was 15,
   then messages with sequence numbers 0 through 15, as well as 32783
   through 65535, would be considered less than or equal.

Top      Up      ToC       Page 82 
   When the Home Registration (H) bit is not set, the following are also
   required:

   o  A Nonce Indices mobility option MUST be present, and the Home and
      Care-of Nonce Index values in this option MUST be recent enough to
      be recognized by the correspondent node.  (Care-of Nonce Index
      values are not inspected for requests to delete a binding.)

   o  The correspondent node MUST re-generate the home keygen token and
      the care-of keygen token from the information contained in the
      packet.  It then generates the binding management key Kbm and uses
      it to verify the authenticator field in the Binding Update as
      specified in Section 6.1.7.

   o  The Binding Authorization Data mobility option MUST be present,
      and its contents MUST satisfy rules presented in Section 5.2.6.
      Note that a care-of address different from the Source Address MAY
      have been specified by including an Alternate Care-of Address
      mobility option in the Binding Update.  When such a message is
      received and the return routability procedure is used as an
      authorization method, the correspondent node MUST verify the
      authenticator by using the address within the Alternate Care-of
      Address in the calculations.

   o  The Binding Authorization Data mobility option MUST be the last
      option and MUST NOT have trailing padding.

   If the Home Registration (H) bit is set, the Nonce Indices mobility
   option MUST NOT be present.

   If the mobile node sends a sequence number which is not greater than
   the sequence number from the last valid Binding Update for this home
   address, then the receiving node MUST send back a Binding
   Acknowledgement with status code 135, and the last accepted sequence
   number in the Sequence Number field of the Binding Acknowledgement.

   If a binding already exists for the given home address and the home
   registration flag has a different value than the Home Registration
   (H) bit in the Binding Update, then the receiving node MUST send back
   a Binding Acknowledgement with status code 139 (registration type
   change disallowed).  The home registration flag stored in the Binding
   Cache entry MUST NOT be changed.

   If the receiving node no longer recognizes the Home Nonce Index
   value, Care-of Nonce Index value, or both values from the Binding
   Update, then the receiving node MUST send back a Binding
   Acknowledgement with status code 136, 137, or 138, respectively.

Top      Up      ToC       Page 83 
   Packets carrying Binding Updates that fail to satisfy all of these
   tests for any reason other than insufficiency of the Sequence Number,
   registration type change, or expired nonce index values, MUST be
   silently discarded.

   If the Binding Update is valid according to the tests above, then the
   Binding Update is processed further as follows:

   o  The Sequence Number value received from a mobile node in a Binding
      Update is stored by the receiving node in its Binding Cache entry
      for the given home address.

   o  If the Lifetime specified in the Binding Update is nonzero and the
      specified care-of address is not equal to the home address for the
      binding, then this is a request to cache a binding for the home
      address.  If the Home Registration (H) bit is set in the Binding
      Update, the Binding Update is processed according to the procedure
      specified in Section 10.3.1; otherwise, it is processed according
      to the procedure specified in Section 9.5.2.

   o  If the Lifetime specified in the Binding Update is zero or the
      specified care-of address matches the home address for the
      binding, then this is a request to delete the cached binding for
      the home address.  In this case, the Binding Update MUST include a
      valid home nonce index, and the care-of nonce index MUST be
      ignored by the correspondent node.  The generation of the binding
      management key depends then exclusively on the home keygen token
      (Section 5.2.5).  If the Home Registration (H) bit is set in the
      Binding Update, the Binding Update is processed according to the
      procedure specified in Section 10.3.2; otherwise, it is processed
      according to the procedure specified in Section 9.5.3.

   The specified care-of address MUST be determined as follows:

   o  If the Alternate Care-of Address option is present, the care-of
      address is the address in that option.

   o  Otherwise, the care-of address is the Source Address field in the
      packet's IPv6 header.

   The home address for the binding MUST be determined as follows:

   o  If the Home Address destination option is present, the home
      address is the address in that option.

   o  Otherwise, the home address is the Source Address field in the
      packet's IPv6 header.

Top      Up      ToC       Page 84 
9.5.2.  Requests to Cache a Binding

   This section describes the processing of a valid Binding Update that
   requests a node to cache a binding, for which the Home Registration
   (H) bit is not set in the Binding Update.

   In this case, the receiving node SHOULD create a new entry in its
   Binding Cache for this home address, or update its existing Binding
   Cache entry for this home address, if such an entry already exists.
   The lifetime for the Binding Cache entry is initialized from the
   Lifetime field specified in the Binding Update, although this
   lifetime MAY be reduced by the node caching the binding; the lifetime
   for the Binding Cache entry MUST NOT be greater than the Lifetime
   value specified in the Binding Update.  Any Binding Cache entry MUST
   be deleted after the expiration of its lifetime.

   Note that if the mobile node did not request a Binding
   Acknowledgement, then it is not aware of the selected shorter
   lifetime.  The mobile node may thus use route optimization and send
   packets with the Home Address destination option.  As discussed in
   Section 9.3.1, such packets will be dropped if there is no binding.
   This situation is recoverable, but can cause temporary packet loss.

   The correspondent node MAY refuse to accept a new Binding Cache entry
   if it does not have sufficient resources.  A new entry MAY also be
   refused if the correspondent node believes its resources are utilized
   more efficiently in some other purpose, such as serving another
   mobile node with higher amount of traffic.  In both cases the
   correspondent node SHOULD return a Binding Acknowledgement with
   status value 130.

9.5.3 Requests to Delete a Binding

   This section describes the processing of a valid Binding Update that
   requests a node to delete a binding when the Home Registration (H)
   bit is not set in the Binding Update.

   Any existing binding for the given home address MUST be deleted.  A
   Binding Cache entry for the home address MUST NOT be created in
   response to receiving the Binding Update.

   If the Binding Cache entry was created by use of return routability
   nonces, the correspondent node MUST ensure that the same nonces are
   not used again with the particular home and care-of address.  If both
   nonces are still valid, the correspondent node has to remember the
   particular combination of nonce indexes, addresses, and sequence
   number as illegal until at least one of the nonces has become too
   old.

Top      Up      ToC       Page 85 
9.5.4.  Sending Binding Acknowledgements

   A Binding Acknowledgement may be sent to indicate receipt of a
   Binding Update as follows:

   o  If the Binding Update was discarded as described in Section 9.2 or
      Section 9.5.1, a Binding Acknowledgement MUST NOT be sent.
      Otherwise the treatment depends on the following rules.

   o  If the Acknowledge (A) bit set is set in the Binding Update, a
      Binding Acknowledgement MUST be sent.  Otherwise, the treatment
      depends on the below rule.

   o  If the node rejects the Binding Update due to an expired nonce
      index, sequence number being out of window (Section 9.5.1), or
      insufficiency of resources (Section 9.5.2), a Binding
      Acknowledgement MUST be sent.  If the node accepts the Binding
      Update, the Binding Acknowledgement SHOULD NOT be sent.

   If the node accepts the Binding Update and creates or updates an
   entry for this binding, the Status field in the Binding
   Acknowledgement MUST be set to a value less than 128.  Otherwise, the
   Status field MUST be set to a value greater than or equal to 128.
   Values for the Status field are described in Section 6.1.8 and in the
   IANA registry of assigned numbers [19].

   If the Status field in the Binding Acknowledgement contains the value
   136 (expired home nonce index), 137 (expired care-of nonce index), or
   138 (expired nonces) then the message MUST NOT include the Binding
   Authorization Data mobility option.  Otherwise, the Binding
   Authorization Data mobility option MUST be included, and MUST meet
   the specific authentication requirements for Binding Acknowledgements
   as defined in Section 5.2.

   If the Source Address field of the IPv6 header that carried the
   Binding Update does not contain a unicast address, the Binding
   Acknowledgement MUST NOT be sent and the Binding Update packet MUST
   be silently discarded.  Otherwise, the acknowledgement MUST be sent
   to the Source Address.  Unlike the treatment of regular packets, this
   addressing procedure does not use information from the Binding Cache.
   However, a routing header is needed in some cases.  If the Source
   Address is the home address of the mobile node, i.e., the Binding
   Update did not contain a Home Address destination option, then the
   Binding Acknowledgement MUST be sent to that address and the routing
   header MUST NOT be used.  Otherwise, the Binding Acknowledgement MUST
   be sent using a type 2 routing header which contains the mobile
   node's home address.

Top      Up      ToC       Page 86 
9.5.5.  Sending Binding Refresh Requests

   If a Binding Cache entry being deleted is still in active use when
   sending packets to a mobile node, then the next packet sent to the
   mobile node will be routed normally to the mobile node's home link.
   Communication with the mobile node continues, but the tunneling from
   the home network creates additional overhead and latency in
   delivering packets to the mobile node.

   If the sender knows that the Binding Cache entry is still in active
   use, it MAY send a Binding Refresh Request message to the mobile node
   in an attempt to avoid this overhead and latency due to deleting and
   recreating the Binding Cache entry.  This message is always sent to
   the home address of the mobile node.

   The correspondent node MAY retransmit Binding Refresh Request
   messages as long as the rate limitation is applied.  The
   correspondent node MUST stop retransmitting when it receives a
   Binding Update.

9.6.  Cache Replacement Policy

   Conceptually, a node maintains a separate timer for each entry in its
   Binding Cache.  When creating or updating a Binding Cache entry in
   response to a received and accepted Binding Update, the node sets the
   timer for this entry to the specified Lifetime period.  Any entry in
   a node's Binding Cache MUST be deleted after the expiration of the
   Lifetime specified in the Binding Update from which the entry was
   created or last updated.

   Each node's Binding Cache will, by necessity, have a finite size.  A
   node MAY use any reasonable local policy for managing the space
   within its Binding Cache.

   A node MAY choose to drop any entry already in its Binding Cache in
   order to make space for a new entry.  For example, a "least-recently
   used" (LRU) strategy for cache entry replacement among entries should
   work well, unless the size of the Binding Cache is substantially
   insufficient.  When entries are deleted, the correspondent node MUST
   follow the rules in Section 5.2.8 in order to guard the return
   routability procedure against replay attacks.

   If the node sends a packet to a destination for which it has dropped
   the entry from its Binding Cache, the packet will be routed through
   the mobile node's home link.  The mobile node can detect this and
   establish a new binding if necessary.

Top      Up      ToC       Page 87 
   However, if the mobile node believes that the binding still exists,
   it may use route optimization and send packets with the Home Address
   destination option.  This can create temporary packet loss, as
   discussed earlier, in the context of binding lifetime reductions
   performed by the correspondent node (Section 9.5.2).

10.  Home Agent Operation

10.1.  Conceptual Data Structures

   Each home agent MUST maintain a Binding Cache and Home Agents List.

   The rules for maintaining a Binding Cache are the same for home
   agents and correspondent nodes and have already been described in
   Section 9.1.

   The Home Agents List is maintained by each home agent, recording
   information about each router on the same link that is acting as a
   home agent.  This list is used by the dynamic home agent address
   discovery mechanism.  A router is known to be acting as a home agent,
   if it sends a Router Advertisement in which the Home Agent (H) bit is
   set.  When the lifetime for a list entry (defined below) expires,
   that entry is removed from the Home Agents List.  The Home Agents
   List is similar to the Default Router List conceptual data structure
   maintained by each host for Neighbor Discovery [12].  The Home Agents
   List MAY be implemented in any manner consistent with the external
   behavior described in this document.

   Each home agent maintains a separate Home Agents List for each link
   on which it is serving as a home agent.  A new entry is created or an
   existing entry is updated in response to receipt of a valid Router
   Advertisement in which the Home Agent (H) bit is set.  Each Home
   Agents List entry conceptually contains the following fields:

   o  The link-local IP address of a home agent on the link.  This
      address is learned through the Source Address of the Router
      Advertisements [12] received from the router.

   o  One or more global IP addresses for this home agent.  Global
      addresses are learned through Prefix Information options with the
      Router Address (R) bit set and received in Router Advertisements
      from this link-local address.  Global addresses for the router in
      a Home Agents List entry MUST be deleted once the prefix
      associated with that address is no longer valid [12].

Top      Up      ToC       Page 88 
   o  The remaining lifetime of this Home Agents List entry.  If a Home
      Agent Information Option is present in a Router Advertisement
      received from a home agent, the lifetime of the Home Agents List
      entry representing that home agent is initialized from the Home
      Agent Lifetime field in the option (if present); otherwise, the
      lifetime is initialized from the Router Lifetime field in the
      received Router Advertisement.  If Home Agents List entry lifetime
      reaches zero, the entry MUST be deleted from the Home Agents List.

   o  The preference for this home agent; higher values indicate a more
      preferable home agent.  The preference value is taken from the
      Home Agent Preference field in the received Router Advertisement,
      if the Router Advertisement contains a Home Agent Information
      Option and is otherwise set to the default value of 0.  A home
      agent uses this preference in ordering the Home Agents List when
      it sends an ICMP Home Agent Address Discovery message.

10.2.  Processing Mobility Headers

   All IPv6 home agents MUST observe the rules described in Section 9.2
   when processing Mobility Headers.

10.3.  Processing Bindings

10.3.1.  Primary Care-of Address Registration

   When a node receives a Binding Update, it MUST validate it and
   determine the type of Binding Update according to the steps described
   in Section 9.5.1.  Furthermore, it MUST authenticate the Binding
   Update as described in Section 5.1.  An authorization step specific
   for the home agent is also needed to ensure that only the right node
   can control a particular home address.  This is provided through the
   home address unequivocally identifying the security association that
   must be used.

   This section describes the processing of a valid and authorized
   Binding Update when it requests the registration of the mobile node's
   primary care-of address.

   To begin processing the Binding Update, the home agent MUST perform
   the following sequence of tests:

   o  If the node implements only correspondent node functionality, or
      has not been configured to act as a home agent, then the node MUST
      reject the Binding Update.  The node MUST also return a Binding
      Acknowledgement to the mobile node, in which the Status field is
      set to 131 (home registration not supported).

Top      Up      ToC       Page 89 
   o  Else, if the home address for the binding (the Home Address field
      in the packet's Home Address option) is not an on-link IPv6
      address with respect to the home agent's current Prefix List, then
      the home agent MUST reject the Binding Update and SHOULD return a
      Binding Acknowledgement to the mobile node, in which the Status
      field is set to 132 (not home subnet).

   o  Else, if the home agent chooses to reject the Binding Update for
      any other reason (e.g., insufficient resources to serve another
      mobile node as a home agent), then the home agent SHOULD return a
      Binding Acknowledgement to the mobile node, in which the Status
      field is set to an appropriate value to indicate the reason for
      the rejection.

   o  A Home Address destination option MUST be present in the message.
      It MUST be validated as described in Section 9.3.1 with the
      following additional rule.  The Binding Cache entry existence test
      MUST NOT be done for IPsec packets when the Home Address option
      contains an address for which the receiving node could act as a
      home agent.

   If home agent accepts the Binding Update, it MUST then create a new
   entry in its Binding Cache for this mobile node or update its
   existing Binding Cache entry, if such an entry already exists.  The
   Home Address field as received in the Home Address option provides
   the home address of the mobile node.

   The home agent MUST mark this Binding Cache entry as a home
   registration to indicate that the node is serving as a home agent for
   this binding.  Binding Cache entries marked as a home registration
   MUST be excluded from the normal cache replacement policy used for
   the Binding Cache (Section 9.6) and MUST NOT be removed from the
   Binding Cache until the expiration of the Lifetime period.

   Unless this home agent already has a binding for the given home
   address, the home agent MUST perform Duplicate Address Detection [13]
   on the mobile node's home link before returning the Binding
   Acknowledgement.  This ensures that no other node on the home link
   was using the mobile node's home address when the Binding Update
   arrived.  If this Duplicate Address Detection fails for the given
   home address or an associated link local address, then the home agent
   MUST reject the complete Binding Update and MUST return a Binding
   Acknowledgement to the mobile node, in which the Status field is set
   to 134 (Duplicate Address Detection failed).  When the home agent
   sends a successful Binding Acknowledgement to the mobile node, the
   home agent assures to the mobile node that its address(es) will be
   kept unique by the home agent for as long as the lifetime was granted
   for the binding.

Top      Up      ToC       Page 90 
   The specific addresses, which are to be tested before accepting the
   Binding Update and later to be defended by performing Duplicate
   Address Detection, depend on the setting of the Link-Local Address
   Compatibility (L) bit, as follows:

   o  L=0: Defend only the given address.  Do not derive a link-local
      address.

   o  L=1: Defend both the given non link-local unicast (home) address
      and the derived link-local.  The link-local address is derived by
      replacing the subnet prefix in the mobile node's home address with
      the link-local prefix.

   The lifetime of the Binding Cache entry depends on a number of
   factors:

   o  The lifetime for the Binding Cache entry MUST NOT be greater than
      the Lifetime value specified in the Binding Update.

   o  The lifetime for the Binding Cache entry MUST NOT be greater than
      the remaining valid lifetime for the subnet prefix in the mobile
      node's home address specified with the Binding Update.  The
      remaining valid lifetime for this prefix is determined by the home
      agent based on its own Prefix List entry [12].

      The remaining preferred lifetime SHOULD NOT have any impact on the
      lifetime for the binding cache entry.

      The home agent MUST remove a binding when the valid lifetime of
      the prefix associated with it expires.

   o  The home agent MAY further decrease the specified lifetime for the
      binding, for example based on a local policy.  The resulting
      lifetime is stored by the home agent in the Binding Cache entry,
      and this Binding Cache entry MUST be deleted by the home agent
      after the expiration of this lifetime.

   Regardless of the setting of the Acknowledge (A) bit in the Binding
   Update, the home agent MUST return a Binding Acknowledgement to the
   mobile node constructed as follows:

   o  The Status field MUST be set to a value indicating success.  The
      value 1 (accepted but prefix discovery necessary) MUST be used if
      the subnet prefix of the specified home address is deprecated, or
      becomes deprecated during the lifetime of the binding, or becomes
      invalid at the end of the lifetime.  The value 0 MUST be used

Top      Up      ToC       Page 91 
      otherwise.  For the purposes of comparing the binding and prefix
      lifetimes, the prefix lifetimes are first converted into units of
      four seconds by ignoring the two least significant bits.

   o  The Key Management Mobility Capability (K) bit is set if the
      following conditions are all fulfilled, and cleared otherwise:

      *  The Key Management Mobility Capability (K) bit was set in the
         Binding Update.

      *  The IPsec security associations between the mobile node and the
         home agent have been established dynamically.

      *  The home agent has the capability to update its endpoint in the
         used key management protocol to the new care-of address every
         time it moves.

      Depending on the final value of the bit in the Binding
      Acknowledgement, the home agent SHOULD perform the following
      actions:

      K = 0

         Discard key management connections, if any, to the old care-of
         address.  If the mobile node did not have a binding before
         sending this Binding Update, discard the connections to the
         home address.

      K = 1

         Move the peer endpoint of the key management protocol
         connection, if any, to the new care-of address.  For an IKE
         phase 1 connection, this means that any IKE packets sent to the
         peer are sent to this address, and packets from this address
         with the original ISAKMP cookies are accepted.

         Note that RFC 2408 [8] Section 2.5.3 gives specific rules that
         ISAKMP cookies must satisfy: they must depend on specific
         parties and can only be generated by the entity itself.  Then
         it recommends a particular way to do this, namely a hash of IP
         addresses.  With the K bit set to 1, the recommended
         implementation technique does not work directly.  To satisfy
         the two rules, the specific parties must be treated as the
         original IP addresses, not the ones in use at the specific
         moment.

   o  The Sequence Number field MUST be copied from the Sequence Number
      given in the Binding Update.

Top      Up      ToC       Page 92 
   o  The Lifetime field MUST be set to the remaining lifetime for the
      binding as set by the home agent in its home registration Binding
      Cache entry for the mobile node, as described above.

   o  If the home agent stores the Binding Cache entry in nonvolatile
      storage, then the Binding Refresh Advice mobility option MUST be
      omitted.  Otherwise, the home agent MAY include this option to
      suggest that the mobile node refreshes its binding before the
      actual lifetime of the binding ends.

      If the Binding Refresh Advice mobility option is present, the
      Refresh Interval field in the option MUST be set to a value less
      than the Lifetime value being returned in the Binding
      Acknowledgement.  This indicates that the mobile node SHOULD
      attempt to refresh its home registration at the indicated shorter
      interval.  The home agent MUST still retain the registration for
      the Lifetime period, even if the mobile node does not refresh its
      registration within the Refresh period.

   The rules for selecting the Destination IP address (and possibly
   routing header construction) for the Binding Acknowledgement to the
   mobile node are the same as in Section 9.5.4.

   In addition, the home agent MUST follow the procedure defined in
   Section 10.4.1 to intercept packets on the mobile node's home link
   addressed to the mobile node, while the home agent is serving as the
   home agent for this mobile node.  The home agent MUST also be
   prepared to accept reverse tunneled packets from the new care-of
   address of the mobile node, as described in Section 10.4.5.  Finally,
   the home agent MUST also propagate new home network prefixes, as
   described in Section 10.6.

10.3.2.  Primary Care-of Address De-Registration

   A binding may need to be de-registered when the mobile node returns
   home or when the mobile node knows that it will not have any care-of
   addresses in the visited network.

   A Binding Update is validated and authorized in the manner described
   in the previous section; note that when the mobile node de-registers
   when it is at home, it may not include the Home Address destination
   option, in which case the mobile node's home address is the source IP
   address of the de-registration Binding Update.  This section
   describes the processing of a valid Binding Update that requests the
   receiving node to no longer serve as its home agent, de-registering
   its primary care-of address.

Top      Up      ToC       Page 93 
   To begin processing the Binding Update, the home agent MUST perform
   the following test:

   o  If the receiving node has no entry marked as a home registration
      in its Binding Cache for this mobile node, then this node MUST
      reject the Binding Update and SHOULD return a Binding
      Acknowledgement to the mobile node, in which the Status field is
      set to 133 (not home agent for this mobile node).

   If the home agent does not reject the Binding Update as described
   above, then it MUST delete any existing entry in its Binding Cache
   for this mobile node.  Then, the home agent MUST return a Binding
   Acknowledgement to the mobile node, constructed as follows:

   o  The Status field MUST be set to a value 0, indicating success.

   o  The Key Management Mobility Capability (K) bit is set or cleared
      and actions based on its value are performed as described in the
      previous section.  The mobile node's home address is used as its
      new care-of address for the purposes of moving the key management
      connection to a new endpoint.

   o  The Sequence Number field MUST be copied from the Sequence Number
      given in the Binding Update.

   o  The Lifetime field MUST be set to zero.

   o  The Binding Refresh Advice mobility option MUST be omitted.

   In addition, the home agent MUST stop intercepting packets on the
   mobile node's home link that are addressed to the mobile node
   (Section 10.4.1).

   The rules for selecting the Destination IP address (and, if required,
   routing header construction) for the Binding Acknowledgement to the
   mobile node are the same as in the previous section.  When the Status
   field in the Binding Acknowledgement is greater than or equal to 128
   and the Source Address of the Binding Update is on the home link, the
   home agent MUST send it to the mobile node's link layer address
   (retrieved either from the Binding Update or through Neighbor
   Solicitation).

Top      Up      ToC       Page 94 
10.4.  Packet Processing

10.4.1.  Intercepting Packets for a Mobile Node

   While a node is serving as the home agent for mobile node it MUST
   attempt to intercept packets on the mobile node's home link that are
   addressed to the mobile node.

   In order to do this, when a node begins serving as the home agent it
   MUST multicast onto the home link a Neighbor Advertisement message
   [12] on behalf of the mobile node.  For the home address specified in
   the Binding Update, the home agent sends a Neighbor Advertisement
   message [12] to the all-nodes multicast address on the home link to
   advertise the home agent's own link-layer address for this IP address
   on behalf of the mobile node.  If the Link-Layer Address
   Compatibility (L) flag has been specified in the Binding Update, the
   home agent MUST do the same for the link-local address of the mobile
   node.

   All fields in each Neighbor Advertisement message SHOULD be set in
   the same way they would be set by the mobile node if it was sending
   this Neighbor Advertisement [12] while at home, with the following
   exceptions:

   o  The Target Address in the Neighbor Advertisement MUST be set to
      the specific IP address for the mobile node.

   o  The Advertisement MUST include a Target Link-layer Address option
      specifying the home agent's link-layer address.

   o  The Router (R) bit in the Advertisement MUST be set to zero.

   o  The Solicited Flag (S) in the Advertisement MUST NOT be set, since
      it was not solicited by any Neighbor Solicitation.

   o  The Override Flag (O) in the Advertisement MUST be set, indicating
      that the Advertisement SHOULD override any existing Neighbor Cache
      entry at any node receiving it.

   o  The Source Address in the IPv6 header MUST be set to the home
      agent's IP address on the interface used to send the
      advertisement.

   Any node on the home link that receives one of the Neighbor
   Advertisement messages (described above) will update its Neighbor
   Cache to associate the mobile node's address with the home agent's
   link layer address, causing it to transmit any future packets
   normally destined to the mobile node to the mobile node's home agent.

Top      Up      ToC       Page 95 
   Since multicasting on the local link (such as Ethernet) is typically
   not guaranteed to be reliable, the home agent MAY retransmit this
   Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see
   [12]) times to increase its reliability.  It is still possible that
   some nodes on the home link will not receive any of the Neighbor
   Advertisements, but these nodes will eventually be able to detect the
   link-layer address change for the mobile node's address through use
   of Neighbor Unreachability Detection [12].

   While a node is serving as a home agent for some mobile node, the
   home agent uses IPv6 Neighbor Discovery [12] to intercept unicast
   packets on the home link addressed to the mobile node.  In order to
   intercept packets in this way, the home agent MUST act as a proxy for
   this mobile node and reply to any received Neighbor Solicitations for
   it.  When a home agent receives a Neighbor Solicitation, it MUST
   check if the Target Address specified in the message matches the
   address of any mobile node for which it has a Binding Cache entry
   marked as a home registration.

   If such an entry exists in the home agent's Binding Cache, the home
   agent MUST reply to the Neighbor Solicitation with a Neighbor
   Advertisement giving the home agent's own link-layer address as the
   link-layer address for the specified Target Address.  In addition,
   the Router (R) bit in the Advertisement MUST be set to zero.  Acting
   as a proxy in this way allows other nodes on the mobile node's home
   link to resolve the mobile node's address and for the home agent to
   defend these addresses on the home link for Duplicate Address
   Detection [12].

10.4.2.  Processing Intercepted Packets

   For any packet sent to a mobile node from the mobile node's home
   agent (in which the home agent is the original sender of the packet),
   the home agent is operating as a correspondent node of the mobile
   node for this packet and the procedures described in Section 9.3.2
   apply.  The home agent then uses a routing header to route the packet
   to the mobile node by way of the primary care-of address in the home
   agent's Binding Cache.

   While the mobile node is away from home, the home agent intercepts
   any packets on the home link addressed to the mobile node's home
   address, as described in Section 10.4.1.  In order to forward each
   intercepted packet to the mobile node, the home agent MUST tunnel the
   packet to the mobile node using IPv6 encapsulation [15].  When a home
   agent encapsulates an intercepted packet for forwarding to the mobile
   node, the home agent sets the Source Address in the new tunnel IP
   header to the home agent's own IP address and sets the Destination
   Address in the tunnel IP header to the mobile node's primary care-of

Top      Up      ToC       Page 96 
   address.  When received by the mobile node, normal processing of the
   tunnel header [15] will result in decapsulation and processing of the
   original packet by the mobile node.

   However, packets addressed to the mobile node's link-local address
   MUST NOT be tunneled to the mobile node.  Instead, these packets MUST
   be discarded and the home agent SHOULD return an ICMP Destination
   Unreachable, Code 3, message to the packet's Source Address (unless
   this Source Address is a multicast address).  Packets addressed to
   the mobile node's site-local address SHOULD NOT be tunneled to the
   mobile node by default.

   Interception and tunneling of the following multicast addressed
   packets on the home network are only done if the home agent supports
   multicast group membership control messages from the mobile node as
   described in the next section.  Tunneling of multicast packets to a
   mobile node follows similar limitations to those defined above for
   unicast packets addressed to the mobile node's link-local and site-
   local addresses.  Multicast packets addressed to a multicast address
   with link-local scope [3], to which the mobile node is subscribed,
   MUST NOT be tunneled to the mobile node.  These packets SHOULD be
   silently discarded (after delivering to other local multicast
   recipients).  Multicast packets addressed to a multicast address with
   a scope larger than link-local, but smaller than global (e.g., site-
   local and organization-local [3], to which the mobile node is
   subscribed, SHOULD NOT be tunneled to the mobile node.  Multicast
   packets addressed with a global scope, to which the mobile node has
   successfully subscribed, MUST be tunneled to the mobile node.

   Before tunneling a packet to the mobile node, the home agent MUST
   perform any IPsec processing as indicated by the security policy data
   base.

10.4.3.  Multicast Membership Control

   This section is a prerequisite for the multicast data packet
   forwarding, described in the previous section.  If this support is
   not provided, multicast group membership control messages are
   silently ignored.

   In order to forward multicast data packets from the home network to
   all the proper mobile nodes, the home agent SHOULD be capable of
   receiving tunneled multicast group membership control information
   from the mobile node in order to determine which groups the mobile
   node has subscribed to.  These multicast group membership messages
   are Listener Report messages specified in MLD [17] or in other
   protocols such as [37].

Top      Up      ToC       Page 97 
   The messages are issued by the mobile node, but sent through the
   reverse tunnel to the home agent.  These messages are issued whenever
   the mobile node decides to enable reception of packets for a
   multicast group or in response to an MLD Query from the home agent.
   The mobile node will also issue multicast group control messages to
   disable reception of multicast packets when it is no longer
   interested in receiving multicasts for a particular group.

   To obtain the mobile node's current multicast group membership the
   home agent must periodically transmit MLD Query messages through the
   tunnel to the mobile node.  These MLD periodic transmissions will
   ensure the home agent has an accurate record of the groups in which
   the mobile node is interested despite packet losses of the mobile
   node's MLD group membership messages.

   All MLD packets are sent directly between the mobile node and the
   home agent.  Since all of these packets are destined to a link-scope
   multicast address and have a hop limit of 1, there is no direct
   forwarding of such packets between the home network and the mobile
   node.  The MLD packets between the mobile node and the home agent are
   encapsulated within the same tunnel header used for other packet
   flows between the mobile node and home agent.

   Note that at this time, even though a link-local source is used on
   MLD packets, no functionality depends on these addresses being
   unique, nor do they elicit direct responses.  All MLD messages are
   sent to multicast destinations.  To avoid ambiguity on the home
   agent, due to mobile nodes which may choose identical link-local
   source addresses for their MLD function, it is necessary for the home
   agent to identify which mobile node was actually the issuer of a
   particular MLD message.  This may be accomplished by noting which
   tunnel such an MLD arrived by, which IPsec SA was used, or by other
   distinguishing means.

   This specification puts no requirement on how the functions in this
   section and the multicast forwarding in Section 10.4.2 are to be
   achieved.  At the time of this writing it was thought that a full
   IPv6 multicast router function would be necessary on the home agent,
   but it may be possible to achieve the same effects through a "proxy
   MLD" application coupled with kernel multicast forwarding.  This may
   be the subject of future specifications.

Top      Up      ToC       Page 98 
10.4.4.  Stateful Address Autoconfiguration

   This section describes how home agents support the use of stateful
   address autoconfiguration mechanisms such as DHCPv6 [29] from the
   mobile nodes.  If this support is not provided, then the M and O bits
   must remain cleared on the Mobile Prefix Advertisement Messages.  Any
   mobile node which sends DHCPv6 messages to the home agent without
   this support will not receive a response.

   If DHCPv6 is used, packets are sent with link-local source addresses
   either to a link-scope multicast address or a link-local address.
   Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel
   standard DHCPv6 packets to the home agent.  Since these link-scope
   packets cannot be forwarded onto the home network, it is necessary
   for the home agent to either implement a DHCPv6 relay agent or a
   DHCPv6 server function itself.  The arriving tunnel or IPsec SA of
   DHCPv6 link-scope messages from the mobile node must be noted so that
   DHCPv6 responses may be sent back to the appropriate mobile node.
   DHCPv6 messages sent to the mobile node with a link-local destination
   must be tunneled within the same tunnel header used for other packet
   flows.

10.4.5.  Handling Reverse Tunneled Packets

   Unless a binding has been established between the mobile node and a
   correspondent node, traffic from the mobile node to the correspondent
   node goes through a reverse tunnel.  Home agents MUST support reverse
   tunneling as follows:

   o  The tunneled traffic arrives to the home agent's address using
      IPv6 encapsulation [15].

   o  Depending on the security policies used by the home agent, reverse
      tunneled packets MAY be discarded unless accompanied by a valid
      ESP header.  The support for authenticated reverse tunneling
      allows the home agent to protect the home network and
      correspondent nodes from malicious nodes masquerading as a mobile
      node.

   o  Otherwise, when a home agent decapsulates a tunneled packet from
      the mobile node, the home agent MUST verify that the Source
      Address in the tunnel IP header is the mobile node's primary
      care-of address.  Otherwise, any node in the Internet could send
      traffic through the home agent and escape ingress filtering
      limitations.  This simple check forces the attacker to know the
      current location of the real mobile node and be able to defeat
      ingress filtering. This check is not necessary if the reverse-
      tunneled packet is protected by ESP in tunnel mode.

Top      Up      ToC       Page 99 
10.4.6.  Protecting Return Routability Packets

   The return routability procedure, described in Section 5.2.5, assumes
   that the confidentiality of the Home Test Init and Home Test messages
   is protected as they are tunneled between the home agent and the
   mobile node.  Therefore, the home agent MUST support tunnel mode
   IPsec ESP for the protection of packets belonging to the return
   routability procedure.  Support for a non-null encryption transform
   and authentication algorithm MUST be available.  It is not necessary
   to distinguish between different kinds of packets during the return
   routability procedure.

   Security associations are needed to provide this protection.  When
   the care-of address for the mobile node changes as a result of an
   accepted Binding Update, special treatment is needed for the next
   packets sent using these security associations.  The home agent MUST
   set the new care-of address as the destination address of these
   packets, as if the outer header destination address in the security
   association had changed [21].

   The above protection SHOULD be used with all mobile nodes.  The use
   is controlled by configuration of the IPsec security policy database
   both at the mobile node and at the home agent.

   As described earlier, the Binding Update and Binding Acknowledgement
   messages require protection between the home agent and the mobile
   node.  The Mobility Header protocol carries both these messages as
   well as the return routability messages.  From the point of view of
   the security policy database these messages are indistinguishable.
   When IPsec is used to protect return routability signaling or payload
   packets, this protection MUST only be applied to the return
   routability packets entering the IPv6 encapsulated tunnel interface
   between the mobile node and the home agent.  This can be achieved,
   for instance, by defining the security policy database entries
   specifically for the tunnel interface.  That is, the policy entries
   are not generally applied on all traffic on the physical interface(s)
   of the nodes, but rather only on traffic that enters the tunnel.
   This makes use of per-interface security policy database entries [4]
   specific to the tunnel interface (the node's attachment to the tunnel
   [11]).

10.5.  Dynamic Home Agent Address Discovery

   This section describes how a home agent can help mobile nodes to
   discover the addresses of the home agents.  The home agent keeps
   track of the other home agents on the same link and responds to
   queries sent by the mobile node.

Top      Up      ToC       Page 100 
10.5.1.  Receiving Router Advertisement Messages

   For each link on which a router provides service as a home agent, the
   router maintains a Home Agents List recording information about all
   other home agents on that link.  This list is used in the dynamic
   home agent address discovery mechanism, described in Section 10.5.
   The information for the list is learned through receipt of the
   periodic unsolicited multicast Router Advertisements, in a manner
   similar to the Default Router List conceptual data structure
   maintained by each host for Neighbor Discovery [12].  In the
   construction of the Home Agents List, the Router Advertisements are
   from each (other) home agent on the link and the Home Agent (H) bit
   is set in them.

   On receipt of a valid Router Advertisement, as defined in the
   processing algorithm specified for Neighbor Discovery [12], the home
   agent performs the following steps in addition to any steps already
   required of it by Neighbor Discovery:

   o  If the Home Agent (H) bit in the Router Advertisement is not set,
      delete the sending node's entry in the current Home Agents List
      (if one exists).  Skip all the following steps.

   o  Otherwise, extract the Source Address from the IP header of the
      Router Advertisement.  This is the link-local IP address on this
      link of the home agent sending this Advertisement [12].

   o  Determine the preference for this home agent.  If the Router
      Advertisement contains a Home Agent Information Option, then the
      preference is taken from the Home Agent Preference field in the
      option; otherwise, the default preference of 0 MUST be used.

   o  Determine the lifetime for this home agent.  If the Router
      Advertisement contains a Home Agent Information Option, then the
      lifetime is taken from the Home Agent Lifetime field in the
      option; otherwise, the lifetime specified by the Router Lifetime
      field in the Router Advertisement SHOULD be used.

   o  If the link-local address of the home agent sending this
      Advertisement is already present in this home agent's Home Agents
      List and the received home agent lifetime value is zero,
      immediately delete this entry in the Home Agents List.

   o  Otherwise, if the link-local address of the home agent sending
      this Advertisement is already present in the receiving home
      agent's Home Agents List, reset its lifetime and preference to the
      values determined above.

Top      Up      ToC       Page 101 
   o  If the link-local address of the home agent sending this
      Advertisement is not already present in the Home Agents List
      maintained by the receiving home agent, and the lifetime for the
      sending home agent is non-zero, create a new entry in the list,
      and initialize its lifetime and preference to the values
      determined above.

   o  If the Home Agents List entry for the link-local address of the
      home agent sending this Advertisement was not deleted as described
      above, determine any global address(es) of the home agent based on
      each Prefix Information option received in this Advertisement in
      which the Router Address (R) bit is set (Section 7.2).  Add all
      such global addresses to the list of global addresses in this Home
      Agents List entry.

   A home agent SHOULD maintain an entry in its Home Agents List for
   each valid home agent address until that entry's lifetime expires,
   after which time the entry MUST be deleted.

   As described in Section 11.4.1, a mobile node attempts dynamic home
   agent address discovery by sending an ICMP Home Agent Address
   Discovery Request message to the Mobile IPv6 Home-Agents anycast
   address [16] for its home IP subnet prefix.  A home agent receiving a
   Home Agent Address Discovery Request message that serves this subnet
   SHOULD return an ICMP Home Agent Address Discovery Reply message to
   the mobile node with the Source Address of the Reply packet set to
   one of the global unicast addresses of the home agent.  The Home
   Agent Addresses field in the Reply message is constructed as follows:

   o  The Home Agent Addresses field SHOULD contain all global IP
      addresses for each home agent currently listed in this home
      agent's own Home Agents List (Section 10.1).

   o  The IP addresses in the Home Agent Addresses field SHOULD be
      listed in order of decreasing preference values, based either on
      the respective advertised preference from a Home Agent Information
      option or on the default preference of 0 if no preference is
      advertised (or on the configured home agent preference for this
      home agent itself).

   o  Among home agents with equal preference, their IP addresses in the
      Home Agent Addresses field SHOULD be listed in an order randomized
      with respect to other home agents with equal preference every time
      a Home Agent Address Discovery Reply message is returned by this
      home agent.

   o  If more than one global IP address is associated with a home
      agent, these addresses SHOULD be listed in a randomized order.

Top      Up      ToC       Page 102 
   o  The home agent SHOULD reduce the number of home agent IP addresses
      so that the packet fits within the minimum IPv6 MTU [11].  The
      home agent addresses selected for inclusion in the packet SHOULD
      be those from the complete list with the highest preference.  This
      limitation avoids the danger of the Reply message packet being
      fragmented (or rejected by an intermediate router with an ICMP
      Packet Too Big message [14]).

10.6.  Sending Prefix Information to the Mobile Node

10.6.1.  List of Home Network Prefixes

   Mobile IPv6 arranges to propagate relevant prefix information to the
   mobile node when it is away from home, so that it may be used in
   mobile node home address configuration and in network renumbering.
   In this mechanism, mobile nodes away from home receive Mobile Prefix
   Advertisements messages.  These messages include Prefix Information
   Options for the prefixes configured on the home subnet interface(s)
   of the home agent.

   If there are multiple home agents, differences in the advertisements
   sent by different home agents can lead to an inability to use a
   particular home address when changing to another home agent.  In
   order to ensure that the mobile nodes get the same information from
   different home agents, it is preferred that all of the home agents on
   the same link be configured in the same manner.

   To support this, the home agent monitors prefixes advertised by
   itself and other home agents on the home link.  In RFC 2461 [12] it
   is acceptable for two routers to advertise different sets of prefixes
   on the same link.  For home agents, the differences should be
   detected for a given home address because the mobile node
   communicates only with one home agent at a time and the mobile node
   needs to know the full set of prefixes assigned to the home link.
   All other comparisons of Router Advertisements are as specified in
   Section 6.2.7 of RFC 2461.

10.6.2.  Scheduling Prefix Deliveries

   A home agent serving a mobile node will schedule the delivery of the
   new prefix information to that mobile node when any of the following
   conditions occur:

   MUST:

   o  The state of the flags changes for the prefix of the mobile node's
      registered home address.

Top      Up      ToC       Page 103 
   o  The valid or preferred lifetime is reconfigured or changes for any
      reason other than advancing real time.

   o  The mobile node requests the information with a Mobile Prefix
      Solicitation (see Section 11.4.2).

   SHOULD:

   o  A new prefix is added to the home subnet interface(s) of the home
      agent.

   MAY:

   o  The valid or preferred lifetime or the state of the flags changes
      for a prefix which is not used in any Binding Cache entry for this
      mobile node.

   The home agent uses the following algorithm to determine when to send
   prefix information to the mobile node.

   o  If a mobile node sends a solicitation, answer right away.

   o  If no Mobile Prefix Advertisement has been sent to the mobile node
      in the last MaxMobPfxAdvInterval seconds (see Section 13), then
      ensure that a transmission is scheduled.  The actual transmission
      time is randomized as described below.

   o  If a prefix matching the mobile node's home registration is added
      on the home subnet interface or if its information changes in any
      way that does not deprecate the mobile node's address, ensure that
      a transmission is scheduled.  The actual transmission time is
      randomized as described below.

   o  If a home registration expires, cancel any scheduled
      advertisements to the mobile node.

   The list of prefixes is sent in its entirety in all cases.

   If the home agent has already scheduled the transmission of a Mobile
   Prefix Advertisement to the mobile node, then the home agent will
   replace the advertisement with a new one to be sent at the scheduled
   time.

   Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY
   which offsets from the current time for the scheduled transmission.
   First calculate the maximum delay for the scheduled Advertisement:

Top      Up      ToC       Page 104 
      MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),

   where MaxMobPfxAdvInterval is as defined in Section 12.  Then compute
   the final delay for the advertisement:

      RAND_ADV_DELAY = MinMobPfxAdvInterval +
            (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))

   Here rand() returns a random integer value in the range of 0 to the
   maximum possible integer value.  This computation is expected to
   alleviate bursts of advertisements when prefix information changes.
   In addition, a home agent MAY further reduce the rate of packet
   transmission by further delaying individual advertisements, when
   necessary to avoid overwhelming local network resources.  The home
   agent SHOULD periodically continue to retransmit an unsolicited
   Advertisement to the mobile node, until it is acknowledged by the
   receipt of a Mobile Prefix Solicitation from the mobile node.

   The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12) before
   the first retransmission and double the retransmission wait time for
   every succeeding retransmission until a maximum number of
   PREFIX_ADV_RETRIES attempts (see Section 12) has been tried.  If the
   mobile node's bindings expire before the matching Binding Update has
   been received, then the home agent MUST NOT attempt any more
   retransmissions, even if not all PREFIX_ADV_RETRIES have been
   retransmitted.  In the meantime, if the mobile node sends another
   Binding Update without returning home, then the home agent SHOULD
   begin transmitting the unsolicited Advertisement again.

   If some condition, as described above, occurs on the home link and
   causes another Prefix Advertisement to be sent to the mobile node,
   before the mobile node acknowledges a previous transmission, the home
   agent SHOULD combine any Prefix Information options in the
   unacknowledged Mobile Prefix Advertisement into a new Advertisement.
   The home agent then discards the old Advertisement.

10.6.3.  Sending Advertisements

   When sending a Mobile Prefix Advertisement to the mobile node, the
   home agent MUST construct the packet as follows:

   o  The Source Address in the packet's IPv6 header MUST be set to the
      home agent's IP address to which the mobile node addressed its
      current home registration or its default global home agent address
      if no binding exists.

Top      Up      ToC       Page 105 
   o  If the advertisement was solicited, it MUST be destined to the
      source address of the solicitation.  If it was triggered by prefix
      changes or renumbering, the advertisement's destination will be
      the mobile node's home address in the binding which triggered the
      rule.

   o  A type 2 routing header MUST be included with the mobile node's
      home address.

   o  IPsec headers MUST be supported and SHOULD be used.

   o  The home agent MUST send the packet as it would any other unicast
      IPv6 packet that it originates.

   o  Set the Managed Address Configuration (M) flag if the
      corresponding flag has been set in any of the Router
      Advertisements from which the prefix information has been learned
      (including the ones sent by this home agent).

   o  Set the Other Stateful Configuration (O) flag if the corresponding
      flag has been set in any of the Router Advertisements from which
      the prefix information has been learned (including the ones sent
      by this home agent).

10.6.4.  Lifetimes for Changed Prefixes

   As described in Section 10.3.1, the lifetime returned by the home
   agent in a Binding Acknowledgement MUST not be greater than the
   remaining valid lifetime for the subnet prefix in the mobile node's
   home address.  This limit on the binding lifetime serves to prohibit
   use of a mobile node's home address after it becomes invalid.



(page 105 continued on part 4)

Next RFC Part