tech-invite   World Map     

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

RFC 6275

 
 
 

Mobility Support in IPv6

Part 5 of 8, p. 89 to 110
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 89 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part