tech-invite   World Map     

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

RFC 6275

 
 
 

Mobility Support in IPv6

Part 4 of 8, p. 64 to 89
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 64 
7.  Modifications to IPv6 Neighbor Discovery

7.1.  Modified Router Advertisement Message Format

   Mobile IPv6 modifies the format of the Router Advertisement message
   [18] by the addition of a single flag bit to indicate that the router
   sending the Advertisement message is serving as a home agent on this
   link.  The format of the Router Advertisement message is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cur Hop Limit |M|O|H| Reserved|       Router Lifetime         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reachable Time                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Retrans Timer                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

   This format represents the following changes over that originally
   specified for Neighbor Discovery [18]:

   Home Agent (H)

      The Home Agent (H) bit is set in a Router Advertisement to
      indicate that the router sending this Router Advertisement is also
      functioning as a Mobile IPv6 home agent on this link.

   Reserved

      Reduced from a 6-bit field to a 5-bit field to account for the
      addition of the above bit.

Top      Up      ToC       Page 65 
7.2.  Modified Prefix Information Option Format

   Mobile IPv6 requires knowledge of a router's global address in
   building a Home Agents List as part of the dynamic home agent address
   discovery mechanism.

   However, Neighbor Discovery [18] only advertises a router's link-
   local address, by requiring this address to be used as the IP Source
   Address of each Router Advertisement.

   Mobile IPv6 extends Neighbor Discovery to allow a router to advertise
   its global address, by the addition of a single flag bit in the
   format of a Prefix Information option for use in Router Advertisement
   messages.  The format of the Prefix Information option is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A|R|Reserved1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This format represents the following changes over that originally
   specified for Neighbor Discovery [18]:

   Router Address (R)

      1-bit router address flag.  When set, indicates that the Prefix
      field contains a complete IP address assigned to the sending
      router.  The indicated prefix is given by the first Prefix Length
      bits of the Prefix field.  The router IP address has the same
      scope and conforms to the same lifetime values as the advertised
      prefix.  This use of the Prefix field is compatible with its use
      in advertising the prefix itself, since Prefix Advertisement uses

Top      Up      ToC       Page 66 
      only the leading bits.  Interpretation of this flag bit is thus
      independent of the processing required for the On-Link (L) and
      Autonomous Address-Configuration (A) flag bits.

   Reserved1

      Reduced from a 6-bit field to a 5-bit field to account for the
      addition of the above bit.

   In a Router Advertisement, a home agent MUST, and all other routers
   MAY, include at least one Prefix Information option with the Router
   Address (R) bit set.  Neighbor Discovery (RFC 4861 [18]) specifies
   that, when including all options in a Router Advertisement causes the
   size of the Advertisement to exceed the link MTU, multiple
   Advertisements can be sent, each containing a subset of the Neighbor
   Discovery options.  Also, when sending unsolicited multicast Router
   Advertisements more frequently than the limit specified in RFC 4861,
   the sending router need not include all options in each of these
   Advertisements.  However, in both of these cases the router SHOULD
   include at least one Prefix Information option with the Router
   Address (R) bit set in each such advertisement, if this bit is set in
   some advertisement sent by the router.

   In addition, the following requirement can assist mobile nodes in
   movement detection.  Barring changes in the prefixes for the link,
   routers that send multiple Router Advertisements with the Router
   Address (R) bit set in some of the included Prefix Information
   options SHOULD provide at least one option and router address that
   stays the same in all of the Advertisements.

7.3.  New Advertisement Interval Option Format

   Mobile IPv6 defines a new Advertisement Interval option, used in
   Router Advertisement messages to advertise the interval at which the
   sending router sends unsolicited multicast Router Advertisements.
   The format of the Advertisement Interval option is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Advertisement Interval                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 67 
   Type

      7

   Length

      8-bit unsigned integer.  The length of the option (including the
      type and length fields) is in units of 8 octets.  The value of
      this field MUST be 1.

   Reserved

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

   Advertisement Interval

      32-bit unsigned integer.  The maximum time, in milliseconds,
      between successive unsolicited Router Advertisement messages sent
      by this router on this network interface.  Using the conceptual
      router configuration variables defined by Neighbor Discovery [18],
      this field MUST be equal to the value MaxRtrAdvInterval, expressed
      in milliseconds.

   Routers MAY include this option in their Router Advertisements.  A
   mobile node receiving a Router Advertisement containing this option
   SHOULD utilize the specified Advertisement Interval for that router
   in its movement detection algorithm, as described in Section 11.5.1.

   This option MUST be silently ignored for other Neighbor Discovery
   messages.

7.4.  New Home Agent Information Option Format

   Mobile IPv6 defines a new Home Agent Information option, used in
   Router Advertisements sent by a home agent to advertise information
   specific to this router's functionality as a home agent.  The format
   of the Home Agent Information option is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Home Agent Preference     |      Home Agent Lifetime      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 68 
   Type

      8

   Length

      8-bit unsigned integer.  The length of the option (including the
      type and length fields) in units of 8 octets.  The value of this
      field MUST be 1.

   Reserved

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

   Home Agent Preference

      16-bit unsigned integer.  The preference for the home agent
      sending this Router Advertisement, for use in ordering the
      addresses returned to a mobile node in the Home Agent Addresses
      field of a Home Agent Address Discovery Reply message.  Higher
      values mean more preferable.  If this option is not included in a
      Router Advertisement in which the Home Agent (H) bit is set, the
      preference value for this home agent MUST be considered to be 0.
      Greater values indicate a more preferable home agent than lower
      values.

      The manual configuration of the Home Agent Preference value is
      described in Section 8.4.  In addition, the sending home agent MAY
      dynamically set the Home Agent Preference value, for example,
      basing it on the number of mobile nodes it is currently serving or
      on its remaining resources for serving additional mobile nodes;
      such dynamic settings are beyond the scope of this document.  Any
      such dynamic setting of the Home Agent Preference, however, MUST
      set the preference appropriately, relative to the default Home
      Agent Preference value of 0 that may be in use by some home agents
      on this link (i.e., a home agent not including a Home Agent
      Information option in its Router Advertisements will be considered
      to have a Home Agent Preference value of 0).

   Home Agent Lifetime

      16-bit unsigned integer.  The lifetime associated with the home
      agent in units of seconds.  The default value is the same as the
      Router Lifetime, as specified in the main body of the Router
      Advertisement.  The maximum value corresponds to 18.2 hours.  A

Top      Up      ToC       Page 69 
      value of 0 MUST NOT be used.  The Home Agent Lifetime applies only
      to this router's usefulness as a home agent; it does not apply to
      information contained in other message fields or options.

   Home agents MAY include this option in their Router Advertisements.
   This option MUST NOT be included in a Router Advertisement in which
   the Home Agent (H) bit (see Section 7.1) is not set.  If this option
   is not included in a Router Advertisement in which the Home Agent (H)
   bit is set, the lifetime for this home agent MUST be considered to be
   the same as the Router Lifetime in the Router Advertisement.  If
   multiple Advertisements are being sent instead of a single larger
   unsolicited multicast Router Advertisement, all of the multiple
   Advertisements with the Router Address (R) bit set MUST include this
   option with the same contents; otherwise, this option MUST be omitted
   from all Advertisements.

   This option MUST be silently ignored for other Neighbor Discovery
   messages.

   If both the Home Agent Preference and Home Agent Lifetime are set to
   their default values specified above, this option SHOULD NOT be
   included in the Router Advertisement messages sent by this home
   agent.

7.5.  Changes to Sending Router Advertisements

   The Neighbor Discovery protocol specification [18] limits routers to
   a minimum interval of 3 seconds between sending unsolicited multicast
   Router Advertisement messages from any given network interface
   (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:

      Routers generate Router Advertisements frequently enough that
      hosts will learn of their presence within a few minutes, but not
      frequently enough to rely on an absence of advertisements to
      detect router failure; a separate Neighbor Unreachability
      Detection algorithm provides failure detection.

   This limitation, however, is not suitable to providing timely
   movement detection for mobile nodes.  Mobile nodes detect their own
   movement by learning the presence of new routers as the mobile node
   moves into wireless transmission range of them (or physically
   connects to a new wired network), and by learning that previous
   routers are no longer reachable.  Mobile nodes MUST be able to
   quickly detect when they move to a link served by a new router, so
   that they can acquire a new care-of address and send Binding Updates
   to register this care-of address with their home agent and to notify
   correspondent nodes as needed.

Top      Up      ToC       Page 70 
   One method that can provide for faster movement detection is to
   increase the rate at which unsolicited Router Advertisements are
   sent.  Mobile IPv6 relaxes this limit such that routers MAY send
   unsolicited multicast Router Advertisements more frequently.  This
   method can be applied where the router is expecting to provide
   service to visiting mobile nodes (e.g., wireless network interfaces),
   or on which it is serving as a home agent to one or more mobile nodes
   (who may return home and need to hear its Advertisements).

   Routers supporting mobility SHOULD be able to be configured with a
   smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow
   sending of unsolicited multicast Router Advertisements more often.
   The minimum allowed values are:

   o  MinRtrAdvInterval 0.03 seconds

   o  MaxRtrAdvInterval 0.07 seconds

   In the case where the minimum intervals and delays are used, the mean
   time between unsolicited multicast Router Advertisements is 50 ms.
   Use of these modified limits MUST be configurable (see also the
   configuration variable MinDelayBetweenRas in Section 13 that may also
   have to be modified accordingly).  Systems where these values are
   available MUST NOT default to them, and SHOULD default to values
   specified in Neighbor Discovery (RFC 4861 [18]).  Knowledge of the
   type of network interface and operating environment SHOULD be taken
   into account in configuring these limits for each network interface.
   This is important with some wireless links, where increasing the
   frequency of multicast beacons can cause considerable overhead.
   Routers SHOULD adhere to the intervals specified in RFC 4861 [18], if
   this overhead is likely to cause service degradation.

   Additionally, the possible low values of MaxRtrAdvInterval may cause
   some problems with movement detection in some mobile nodes.  To
   ensure that this is not a problem, Routers SHOULD add 20 ms to any
   Advertisement Intervals sent in RAs that are below 200 ms, in order
   to account for scheduling granularities on both the MN and the
   router.

   Note that multicast Router Advertisements are not always required in
   certain wireless networks that have limited bandwidth.  Mobility
   detection or link changes in such networks may be done at lower
   layers.  Router advertisements in such networks SHOULD be sent only
   when solicited.  In such networks it SHOULD be possible to disable
   unsolicited multicast Router Advertisements on specific interfaces.
   The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set
   to some high values.

Top      Up      ToC       Page 71 
   Home agents MUST include the Source Link-Layer Address option in all
   Router Advertisements they send.  This simplifies the process of
   returning home, as discussed in Section 11.5.5.

   Note that according to Neighbor Discovery (RFC 4861 [18]),
   AdvDefaultLifetime is by default based on the value of
   MaxRtrAdvInterval.  AdvDefaultLifetime is used in the Router Lifetime
   field of Router Advertisements.  Given that this field is expressed
   in seconds, a small MaxRtrAdvInterval value can result in a zero
   value for this field.  To prevent this, routers SHOULD keep
   AdvDefaultLifetime in at least one second, even if the use of
   MaxRtrAdvInterval would result in a smaller value.

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.

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

   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 Quality of Service (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 round-trip 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.

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

   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 Sections 9.1
      and 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 [18], 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).

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

   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 (Sections 10.1 and 10.3.1).

   o  Every home agent MUST be able to intercept packets (using proxy
      Neighbor Discovery [18]) 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 [7] 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 [7] 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
      Sections 10.1 and 10.5.1.

   o  Every home agent MUST be able to accept packets addressed to the
      Mobile IPv6 Home-Agents anycast address [8] 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).

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

   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 [7].

   o  The node MUST be able to process type 2 routing header as defined
      in Sections 6.4 and 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).

Top      Up      ToC       Page 76 
   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
      Sections 11.7.1 and 11.7.2.

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

   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 [31] 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

Top      Up      ToC       Page 77 
   maintained by Neighbor Discovery [18].  When sending a packet, the
   Binding Cache is searched before the Neighbor Discovery conceptual
   Destination Cache [18].

   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.

   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.  A correspondent node MAY select a
      smaller lifetime for the Binding Cache entry, and supply that
      value to the mobile node in the Binding Acknowledgment message.

   o  A flag indicating whether or not this Binding Cache entry is a
      home registration entry (applicable only on nodes that 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.

Top      Up      ToC       Page 78 
9.2.  Processing Mobility Headers

   Mobility Header processing MUST observe the following rules:

   o  The checksum must be verified as per Section 6.1.  If invalid, 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 the 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 4443 [17].  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.

   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 4443 [17].  (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.  If the Next Header
   value of the Destination Option is one of the following: {50 (ESP),
   51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
   normally.  Otherwise, the packet MUST be dropped if there is no
   corresponding Binding Cache entry.  A corresponding Binding Cache

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

   If the packet is dropped due to 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
   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 [18] packet.

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

   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 determines 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

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

   Sections 9.2 and 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.

   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 [17].

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 [7], 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

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

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 that fails to satisfy
   this test 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 that fails to satisfy
   this test 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.

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

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.

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

   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 that 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.

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

   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 not zero, 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, 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.

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

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.

Top      Up      ToC       Page 87 
   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 indices, addresses, and sequence
   number as illegal until at least one of the nonces has become too
   old.

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 Sections 9.2
      or 9.5.1, a Binding Acknowledgement MUST NOT be sent.  Otherwise,
      the treatment depends on the following rules.

   o  If the Acknowledge (A) bit is set in the Binding Update, a Binding
      Acknowledgement MUST be sent.  Otherwise, the treatment depends on
      the next 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 [30].

   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.

Top      Up      ToC       Page 88 
   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 that contains the mobile node's
   home address.

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.

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

   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).



(page 89 continued on part 5)

Next RFC Part