Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 6275

Mobility Support in IPv6

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

Top   ToC   RFC6275 - Page 89   prevText

10. Home Agent Operation

10.1. Conceptual Data Structures

Each home agent MUST maintain a Binding Cache and Home Agents List. The rules for maintaining a Binding Cache are the same for home agents and correspondent nodes and have already been described in Section 9.1. The Home Agents List is maintained by each home agent, recording information about each router on the same link that is acting as a home agent. This list is used by the dynamic home agent address discovery mechanism. A router is known to be acting as a home agent, if it sends a Router Advertisement in which the Home Agent (H) bit is set. When the lifetime for a list entry (defined below) expires, that entry is removed from the Home Agents List. The Home Agents List is similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [18]. The Home Agents List MAY be implemented in any manner consistent with the external behavior described in this document. Each home agent maintains a separate Home Agents List for each link on which it is serving as a home agent. A new entry is created or an existing entry is updated in response to receipt of a valid Router Advertisement in which the Home Agent (H) bit is set. Each Home Agents List entry conceptually contains the following fields:
Top   ToC   RFC6275 - Page 90
   o  The link-local IP address of a home agent on the link.  This
      address is learned through the Source Address of the Router
      Advertisements [18] received from the router.

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

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

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

10.2. Processing Mobility Headers

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

10.3. Processing Bindings

10.3.1. Primary Care-of Address Registration

When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 9.5.1. Furthermore, it MUST authenticate the Binding Update as described in Section 5.1. An authorization step specific for the home agent is also needed to ensure that only the right node can control a particular home address. This is provided through the home address unequivocally identifying the security association that must be used.
Top   ToC   RFC6275 - Page 91
   This section describes the processing of a valid and authorized
   Binding Update when it requests the registration of the mobile node's
   primary care-of address.

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

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

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

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

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

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

   The home agent MUST mark this Binding Cache entry as a home
   registration to indicate that the node is serving as a home agent for
   this binding.  Binding Cache entries marked as a home registration
   MUST be excluded from the normal cache replacement policy used for
   the Binding Cache (Section 9.6) and MUST NOT be removed from the
   Binding Cache until the expiration of the Lifetime period.
Top   ToC   RFC6275 - Page 92
   Unless this home agent already has a binding for the given home
   address, the home agent MUST perform Duplicate Address Detection [19]
   on the mobile node's home link before returning the Binding
   Acknowledgement.  This ensures that no other node on the home link
   was using the mobile node's home address when the Binding Update
   arrived.  If this Duplicate Address Detection fails for the given
   home address or an associated link local address, then the home agent
   MUST reject the complete Binding Update and MUST return a Binding
   Acknowledgement to the mobile node, in which the Status field is set
   to 134 (Duplicate Address Detection failed).  When the home agent
   sends a successful Binding Acknowledgement to the mobile node, the
   home agent assures to the mobile node that its address(es) will be
   kept unique by the home agent for as long as the lifetime was granted
   for the binding.

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

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

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

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

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

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

      The remaining preferred lifetime SHOULD NOT have any impact on the
      lifetime for the Binding Cache entry.

      The home agent MUST remove a binding when the valid lifetime of
      the prefix associated with it expires.
Top   ToC   RFC6275 - Page 93
   o  The home agent MAY further decrease the specified lifetime for the
      binding, for example, based on a local policy.  The resulting
      lifetime is stored by the home agent in the Binding Cache entry,
      and this Binding Cache entry MUST be deleted by the home agent
      after the expiration of this lifetime.

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

   o  The Status field MUST be set to a value indicating success.  The
      value 1 (accepted but prefix discovery necessary) MUST be used if
      the subnet prefix of the specified home address is deprecated, or
      becomes deprecated during the lifetime of the binding, or becomes
      invalid at the end of the lifetime.  The value 0 MUST be used
      otherwise.  For the purposes of comparing the binding and prefix
      lifetimes, the prefix lifetimes are first converted into units of
      four seconds by ignoring the two least significant bits.

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

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

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

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

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

      K = 0

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

      K = 1

         Move the peer endpoint of the key management protocol
         connection, if any, to the new care-of address.
Top   ToC   RFC6275 - Page 94
   o  The Sequence Number field MUST be copied from the Sequence Number
      given in the Binding Update.

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

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

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

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

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

10.3.2. Primary Care-of Address De-Registration

A binding may need to be de-registered when the mobile node returns home or when the mobile node knows that it will not have any care-of addresses in the visited network. A Binding Update is validated and authorized in the manner described in the previous section; note that when the mobile node de-registers when it is at home, it MAY choose to omit the Home Address destination option, in which case the mobile node's home address is the source IP address of the de-registration Binding Update. This
Top   ToC   RFC6275 - Page 95
   section describes the processing of a valid Binding Update that
   requests the receiving node to no longer serve as its home agent, de-
   registering its primary care-of address.

   To begin processing the Binding Update, the home agent MUST perform
   the following test:

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

   If the home agent does not reject the Binding Update as described
   above, then the home agent MUST return a Binding Acknowledgement to
   the mobile node, constructed as follows:

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

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

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

   o  The Lifetime field MUST be set to zero.

   o  The Binding Refresh Advice mobility option MUST be omitted.

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

   When a mobile node sends a Binding Update to refresh the binding from
   the visited link and soon after moves to the home link and sends a
   de-registration Binding Update, a race condition can happen if the
   first Binding Update gets delayed.  The delayed Binding Update can
   cause the home agent to create a new Binding Cache entry for a mobile
Top   ToC   RFC6275 - Page 96
   node that had just attached to the home link and successfully deleted
   the binding.  This would prevent the mobile node from using its home
   address from the home link.

   In order to prevent this, the home agent SHOULD NOT remove the
   Binding Cache entry immediately after receiving the de-registration
   Binding Update from the mobile node.  It SHOULD mark the Binding
   Cache entry as invalid, and MUST stop intercepting packets on the
   mobile node's home link that are addressed to the mobile node
   (Section 10.4.1).  The home agent should wait for
   MAX_DELETE_BCE_TIMEOUT (Section 12) seconds before removing the
   Binding Cache entry completely.  In the scenario described above, if
   the home agent receives the delayed Binding Update that the mobile
   node sent from the visited link, it would reject the message since
   the sequence number would be less than the last received de-
   registration Binding Update from the home link.  The home agent would
   then send a Binding Acknowledgment with status '135' (Sequence number
   out of window) to the care-of address on the visited link.  The
   mobile node can continue using the home address from the home link.

10.4. Packet Processing

10.4.1. Intercepting Packets for a Mobile Node

While a node is serving as the home agent for a mobile node it MUST attempt to intercept packets on the mobile node's home link that are addressed to the mobile node. In order to do this, when a node begins serving as the home agent it MUST have performed Duplicate Address Detection (as specified in Section 10.3.1), and subsequently it MUST multicast onto the home link a Neighbor Advertisement message [18] on behalf of the mobile node. For the home address specified in the Binding Update, the home agent sends a Neighbor Advertisement message [18] to the all-nodes multicast address on the home link to advertise the home agent's own link-layer address for this IP address on behalf of the mobile node. If the Link-Layer Address Compatibility (L) flag has been specified in the Binding Update, the home agent MUST do the same for the link- local address of the mobile node. All fields in each Neighbor Advertisement message SHOULD be set in the same way they would be set by the mobile node if it was sending this Neighbor Advertisement [18] while at home, with the following exceptions: o The Target Address in the Neighbor Advertisement MUST be set to the specific IP address for the mobile node.
Top   ToC   RFC6275 - Page 97
   o  The Advertisement MUST include a Target Link-layer Address option
      specifying the home agent's link-layer address.

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

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

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

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

   Any node on the home link that receives one of the Neighbor
   Advertisement messages (described above) will update its Neighbor
   Cache to associate the mobile node's address with the home agent's
   link-layer address, causing it to transmit any future packets
   normally destined to the mobile node to the mobile node's home agent.
   Since multicasting on the local link (such as Ethernet) is typically
   not guaranteed to be reliable, the home agent MAY retransmit this
   Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see
   [18]) times to increase its reliability.  It is still possible that
   some nodes on the home link will not receive any of the Neighbor
   Advertisements, but these nodes will eventually be able to detect the
   link-layer address change for the mobile node's address through use
   of Neighbor Unreachability Detection [18].

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

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

10.4.2. Processing Intercepted Packets

For any packet sent to a mobile node from the mobile node's home agent (in which the home agent is the original sender of the packet), the home agent is operating as a correspondent node of the mobile node for this packet and the procedures described in Section 9.3.2 apply. The home agent then uses a routing header to route the packet to the mobile node by way of the primary care-of address in the home agent's Binding Cache. While the mobile node is away from home, the home agent intercepts any packets on the home link addressed to the mobile node's home address, as described in Section 10.4.1. In order to forward each intercepted packet to the mobile node, the home agent MUST tunnel the packet to the mobile node using IPv6 encapsulation [7]. When a home agent encapsulates an intercepted packet for forwarding to the mobile node, the home agent sets the Source Address in the new tunnel IP header to the home agent's own IP address and sets the Destination Address in the tunnel IP header to the mobile node's primary care-of address. When received by the mobile node, normal processing of the tunnel header [7] will result in decapsulation and processing of the original packet by the mobile node. However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. Instead, these packets MUST be discarded and the home agent SHOULD return an ICMP Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address). Interception and tunneling of the following multicast addressed packets on the home network are only done if the home agent supports multicast group membership control messages from the mobile node as described in the next section. Tunneling of multicast packets to a mobile node follows similar limitations to those defined above for unicast packets addressed to the mobile node's link-local address. Multicast packets addressed to a multicast address with link-local scope [16], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node. These packets SHOULD be silently discarded (after delivering to other local multicast recipients). Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site-local and organization-local [16]), to which the mobile node is subscribed,
Top   ToC   RFC6275 - Page 99
   SHOULD NOT be tunneled to the mobile node.  Multicast packets
   addressed with a global scope, to which the mobile node has
   successfully subscribed, MUST be tunneled to the mobile node.

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

10.4.3. Multicast Membership Control

This section is a prerequisite for the multicast data packet forwarding, described in the previous section. If this support is not provided, multicast group membership control messages are silently ignored. In order to forward multicast data packets from the home network to all the proper mobile nodes, the home agent SHOULD be capable of receiving tunneled multicast group membership control information from the mobile node in order to determine which groups the mobile node has subscribed to. These multicast group membership messages are Listener Report messages specified in Multicast Listener Discovery (MLD) [9] or in other protocols such as [41]. The messages are issued by the mobile node, but sent through the reverse tunnel to the home agent. These messages are issued whenever the mobile node decides to enable reception of packets for a multicast group or in response to an MLD Query from the home agent. The mobile node will also issue multicast group control messages to disable reception of multicast packets when it is no longer interested in receiving multicasts for a particular group. To obtain the mobile node's current multicast group membership the home agent must periodically transmit MLD Query messages through the tunnel to the mobile node. These MLD periodic transmissions will ensure the home agent has an accurate record of the groups in which the mobile node is interested despite packet losses of the mobile node's MLD group membership messages. All MLD packets are sent directly between the mobile node and the home agent. Since all of these packets are destined to a link-scope multicast address and have a hop limit of 1, there is no direct forwarding of such packets between the home network and the mobile node. The MLD packets between the mobile node and the home agent are encapsulated within the same tunnel header used for other packet flows between the mobile node and home agent.
Top   ToC   RFC6275 - Page 100
   Note that at this time, even though a link-local source is used on
   MLD packets, no functionality depends on these addresses being
   unique, nor do they elicit direct responses.  All MLD messages are
   sent to multicast destinations.  To avoid ambiguity on the home
   agent, due to mobile nodes that may choose identical link-local
   source addresses for their MLD function, it is necessary for the home
   agent to identify which mobile node was actually the issuer of a
   particular MLD message.  This may be accomplished by noting which
   tunnel such an MLD arrived by, which IPsec security association (SA)
   was used, or by other distinguishing means.

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

10.4.4. Stateful Address Autoconfiguration

This section describes how home agents support the use of stateful address autoconfiguration mechanisms such as DHCPv6 [31] from the mobile nodes. If this support is not provided, then the M and O bits must remain cleared on the Mobile Prefix Advertisement Messages. Any mobile node that sends DHCPv6 messages to the home agent without this support will not receive a response. If DHCPv6 is used, packets are sent with link-local source addresses either to a link-scope multicast address or a link-local address. Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets cannot be forwarded onto the home network, it is necessary for the home agent to implement either a DHCPv6 relay agent or a DHCPv6 server function itself. The arriving tunnel or IPsec SA of DHCPv6 link-scope messages from the mobile node must be noted so that DHCPv6 responses may be sent back to the appropriate mobile node. DHCPv6 messages sent to the mobile node with a link-local destination must be tunneled within the same tunnel header used for other packet flows.

10.4.5. Handling Reverse-Tunneled Packets

Unless a binding has been established between the mobile node and a correspondent node, traffic from the mobile node to the correspondent node goes through a reverse tunnel. Home agents MUST support reverse tunneling as follows:
Top   ToC   RFC6275 - Page 101
   o  The tunneled traffic arrives to the home agent's address using
      IPv6 encapsulation [7].

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

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

10.4.6. Protecting Return Routability Packets

The return routability procedure, described in Section 5.2.5, assumes that the confidentiality of the Home Test Init and Home Test messages is protected as they are tunneled between the home agent and the mobile node. Therefore, the home agent MUST support tunnel mode IPsec ESP for the protection of packets belonging to the return routability procedure. Support for a non-null encryption transform and authentication algorithm MUST be available. It is not necessary to distinguish between different kinds of packets during the return routability procedure. Security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed. The above protection SHOULD be used with all mobile nodes. The use is controlled by configuration of the IPsec security policy database both at the mobile node and at the home agent. As described earlier, the Binding Update and Binding Acknowledgement messages require protection between the home agent and the mobile node. The Mobility Header protocol carries both these messages as well as the return routability messages. From the point of view of
Top   ToC   RFC6275 - Page 102
   the security policy database these messages are indistinguishable.
   When IPsec is used to protect return routability signaling or payload
   packets, this protection MUST only be applied to the return
   routability packets entering the IPv6 encapsulated tunnel interface
   between the mobile node and the home agent.  This can be achieved,
   for instance, by defining the security policy database entries
   specifically for the tunnel interface.  That is, the policy entries
   are not generally applied on all traffic on the physical interface(s)
   of the nodes, but rather only on traffic that enters the tunnel.
   This makes use of per-interface security policy database entries [3]
   specific to the tunnel interface (the node's attachment to the tunnel
   [6]).

10.5. Dynamic Home Agent Address Discovery

This section describes an optional mechanism by which a home agent can help mobile nodes to discover the addresses of other home agents on the mobile node's home network. The home agent keeps track of the other home agents on the same link and responds to queries sent by the mobile node.

10.5.1. Receiving Router Advertisement Messages

For each link on which a router provides service as a home agent, the router maintains a Home Agents List recording information about all other home agents on that link. This list is used in the dynamic home agent address discovery mechanism; the mobile node uses the list as described in Section 11.4.1. The information for the list is learned through receipt of the periodic unsolicited multicast Router Advertisements, in a manner similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [18]. In the construction of the Home Agents List, the Router Advertisements are from each (other) home agent on the link and the Home Agent (H) bit is set in them. On receipt of a valid Router Advertisement, as defined in the processing algorithm specified for Neighbor Discovery [18], the home agent performs the following steps in addition to any steps already required of it by Neighbor Discovery: o If the Home Agent (H) bit in the Router Advertisement is not set, delete the sending node's entry in the current Home Agents List (if one exists). Skip all the following steps. o Otherwise, extract the Source Address from the IP header of the Router Advertisement. This is the link-local IP address on this link of the home agent sending this Advertisement [18].
Top   ToC   RFC6275 - Page 103
   o  Determine the preference for this home agent.  If the Router
      Advertisement contains a Home Agent Information Option, then the
      preference is taken from the Home Agent Preference field in the
      option; otherwise, the default preference of 0 MUST be used.

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

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

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

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

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

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

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

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

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

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

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

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

10.6. Sending Prefix Information to the Mobile Node

10.6.1. List of Home Network Prefixes

Mobile IPv6 arranges to propagate relevant prefix information to the mobile node when it is away from home, so that it may be used in mobile node home address configuration and in network renumbering. In this mechanism, mobile nodes away from home receive Mobile Prefix Advertisement messages. These messages include Prefix Information Options for the prefixes configured on the home subnet interface(s) of the home agent. If there are multiple home agents, differences in the advertisements sent by different home agents can lead to an inability to use a particular home address when changing to another home agent. In
Top   ToC   RFC6275 - Page 105
   order to ensure that the mobile nodes get the same information from
   different home agents, it is preferred that all of the home agents on
   the same link be configured in the same manner.

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

10.6.2. Scheduling Prefix Deliveries

A home agent serving a mobile node will schedule the delivery of the new prefix information to that mobile node when any of the following conditions occur: MUST: o The state of the flags changes for the prefix of the mobile node's registered home address. o The valid or preferred lifetime is reconfigured or changes for any reason other than advancing real time. o The mobile node requests the information with a Mobile Prefix Solicitation (see Section 11.4.2). SHOULD: o A new prefix is added to the home subnet interface(s) of the home agent. MAY: o The valid or preferred lifetime or the state of the flags changes for a prefix that is not used in any Binding Cache entry for this mobile node. The home agent uses the following algorithm to determine when to send prefix information to the mobile node. o If a mobile node sends a solicitation, answer right away.
Top   ToC   RFC6275 - Page 106
   o  If no Mobile Prefix Advertisement has been sent to the mobile node
      in the last MaxMobPfxAdvInterval seconds (see Section 13), then
      ensure that a transmission is scheduled.  The actual transmission
      time is randomized as described below.

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

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

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

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

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


     MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),

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


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

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

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

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

10.6.3. Sending Advertisements

When sending a Mobile Prefix Advertisement to the mobile node, the home agent MUST construct the packet as follows: o The Source Address in the packet's IPv6 header MUST be set to the home agent's IP address to which the mobile node addressed its current home registration or its default global home agent address if no binding exists. o If the advertisement was solicited, it MUST be destined to the source address of the solicitation. If it was triggered by prefix changes or renumbering, the advertisement's destination will be the mobile node's home address in the binding that triggered the rule. o A type 2 routing header MUST be included with the mobile node's home address. o IPsec headers MUST be supported and SHOULD be used. o The home agent MUST send the packet as it would any other unicast IPv6 packet that it originates. o Set the Managed Address Configuration (M) flag if the corresponding flag has been set in any of the Router Advertisements from which the prefix information has been learned (including the ones sent by this home agent). o Set the Other Stateful Configuration (O) flag if the corresponding flag has been set in any of the Router Advertisements from which the prefix information has been learned (including the ones sent by this home agent).
Top   ToC   RFC6275 - Page 108

10.6.4. Lifetimes for Changed Prefixes

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

11. Mobile Node Operation

11.1. Conceptual Data Structures

Each mobile node MUST maintain a Binding Update List. The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. The Binding Update List includes all bindings sent by the mobile node to either its home agent or correspondent nodes. It also contains Binding Updates that are waiting for the completion of the return routability procedure before they can be sent. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. The Binding Update List MAY be implemented in any manner consistent with the external behavior described in this document. Each Binding Update List entry conceptually contains the following fields: o The IP address of the node to which a Binding Update was sent. o The home address for which that Binding Update was sent. o The care-of address sent in that Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update while giving its new care-of address to this destination after changing its care-of address. o The initial value of the Lifetime field sent in that Binding Update. o The remaining lifetime of that binding. This lifetime is initialized from the Lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update List.
Top   ToC   RFC6275 - Page 109
   o  The maximum value of the Sequence Number field sent in previous
      Binding Updates to this destination.  The Sequence Number field is
      16 bits long and all comparisons between Sequence Number values
      MUST be performed modulo 2**16 (see Section 9.5.1).

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

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

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

   The Binding Update List is used to determine whether a particular
   packet is sent directly to the correspondent node or tunneled via the
   home agent (see Section 11.3.1).

   The Binding Update list also conceptually contains the following data
   related to running the return routability procedure.  This data is
   relevant only for Binding Updates sent to correspondent nodes.

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

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

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

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

   o  Home and care-of nonce indices received from the correspondent
      node.
Top   ToC   RFC6275 - Page 110
   o  The time at which each of the tokens and nonces were received from
      the correspondent node, as needed to implement reuse while moving.

11.2. Processing Mobility Headers

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


(page 110 continued on part 6)

Next Section