Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6275

Mobility Support in IPv6

Pages: 169
Proposed Standard
Errata
Obsoletes:  3775
Part 4 of 8 – Pages 64 to 89
First   Prev   Next

Top   ToC   RFC6275 - Page 64   prevText

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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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   ToC   RFC6275 - 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 Section