tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5213

 
 
 

Proxy Mobile IPv6

Part 2 of 4, p. 17 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
5.  Local Mobility Anchor Operation

   The local mobility anchor MUST support the home agent function as
   defined in [RFC3775] and the extensions defined in this
   specification.  A home agent with these modifications and enhanced
   capabilities for supporting the Proxy Mobile IPv6 protocol is
   referred to as a local mobility anchor.

   This section describes the operational details of the local mobility
   anchor.

Top      Up      ToC       Page 18 
5.1.  Extensions to Binding Cache Entry Data Structure

   Every local mobility anchor MUST maintain a Binding Cache entry for
   each currently registered mobile node.  A Binding Cache entry is a
   conceptual data structure, described in Section 9.1 of [RFC3775].

   For supporting this specification, the Binding Cache Entry data
   structure needs to be extended with the following additional fields.

   o  A flag indicating whether or not this Binding Cache entry is
      created due to a proxy registration.  This flag is set to value 1
      for Binding Cache entries that are proxy registrations and is set
      to value 0 for all other entries.

   o  The identifier of the registered mobile node, MN-Identifier.  This
      identifier is obtained from the Mobile Node Identifier Option
      [RFC4283] present in the received Proxy Binding Update message.

   o  The link-layer identifier of the mobile node's connected interface
      on the access link.  This identifier can be acquired from the
      Mobile Node Link-layer Identifier option, present in the received
      Proxy Binding Update message.  If the option was not present in
      the request, this variable length field MUST be set to two
      (octets) and MUST be initialized to a value of ALL_ZERO.

   o  The link-local address of the mobile access gateway on the point-
      to-point link shared with the mobile node.  This is generated by
      the local mobility anchor after accepting the initial Proxy
      Binding Update message.

   o  A list of IPv6 home network prefixes assigned to the mobile node's
      connected interface.  The home network prefix(es) may have been
      statically configured in the mobile node's policy profile, or,
      they may have been dynamically allocated by the local mobility
      anchor.  Each one of these prefix entries will also include the
      corresponding prefix length.

   o  The tunnel interface identifier (tunnel-if-id) of the bi-
      directional tunnel between the local mobility anchor and the
      mobile access gateway where the mobile node is currently anchored.
      This is internal to the local mobility anchor.  The tunnel
      interface identifier is acquired during the tunnel creation.

   o  The access technology type, by which the mobile node is currently
      attached.  This is obtained from the Access Technology Type
      option, present in the Proxy Binding Update message.

Top      Up      ToC       Page 19 
   o  The 64-bit timestamp value of the most recently accepted Proxy
      Binding Update message sent for this mobile node.  This is the
      time of day on the local mobility anchor, when the message was
      received.  If the Timestamp option is not present in the Proxy
      Binding Update message (i.e., when the sequence-number-based
      scheme is in use), the value MUST be set to ALL_ZERO.

   Typically, any one of the mobile node's home network prefixes from
   its mobility session may be used as a key for locating its Binding
   Cache entry in all cases except when there has been a handoff of the
   mobile node's session to a new mobile access gateway, and that mobile
   access gateway is unaware of the home network prefix(es) assigned to
   that mobility session.  In such handoff cases, the Binding Cache
   entry can be located under the considerations specified in Section
   5.4.1.

5.2.  Supported Home Network Prefix Models

   This specification supports the Per-MN-Prefix model and does not
   support the Shared-Prefix model.  According to the Per-MN-Prefix
   model, home network prefix(es) assigned to a mobile node are for that
   mobile node's exclusive use and no other node shares an address from
   that prefix (other than the Subnet-Router anycast address [RFC4291]
   that is used by the mobile access gateway hosting that prefix on that
   link).

   There may be more than one prefix assigned to a given interface of
   the mobile node; all of those assigned prefixes MUST be unique to
   that mobile node, and all are part of exactly one mobility session.
   If the mobile node simultaneously attaches to the Proxy Mobile IPv6
   domain through multiple interfaces, each of the attached interfaces
   MUST be assigned one or more unique prefixes.  Prefixes that are not
   assigned to the same interface MUST NOT be managed under the same
   mobility session.

   The mobile node's home network prefix(es) assigned to a given
   interface of a mobile node (part of a mobility session) will be
   hosted on the access link where the mobile node is attached (using
   that interface).  The local mobility anchor is not required to
   perform any proxy Neighbor Discovery (ND) operations [RFC4861] for
   defending the mobile node's home address(es), as the prefixes are not
   locally hosted on the local mobility anchor.  However, from the
   routing perspective, the home network prefix(es) is topologically
   anchored on the local mobility anchor.

Top      Up      ToC       Page 20 
5.3.  Signaling Considerations

   This section provides the rules for processing the signaling
   messages.  The processing rules specified in this section and other
   related sections are chained and are in a specific order.  When
   applying these considerations for processing the signaling messages,
   the specified order MUST be maintained.

5.3.1.  Processing Proxy Binding Updates

   1.   The received Proxy Binding Update message (a Binding Update
        message with the (P) flag set to value of 1, format specified in
        Section 8.1) MUST be authenticated as described in Section 4.
        When IPsec is used for message authentication, the Security
        Parameter Index (SPI) in the IPsec header [RFC4306] of the
        received packet is needed for locating the security association,
        for authenticating the Proxy Binding Update message.

   2.   The local mobility anchor MUST observe the rules described in
        Section 9.2 of [RFC3775] when processing the Mobility Header in
        the received Proxy Binding Update message.

   3.   The local mobility anchor MUST ignore the check, specified in
        Section 10.3.1 of [RFC3775], related to the presence of the Home
        Address destination option in the Proxy Binding Update message.

   4.   The local mobility anchor MUST identify the mobile node from the
        identifier present in the Mobile Node Identifier option
        [RFC4283] of the Proxy Binding Update message.  If the Mobile
        Node Identifier option is not present in the Proxy Binding
        Update message, the local mobility anchor MUST reject the
        request and send a Proxy Binding Acknowledgement message with
        Status field set to MISSING_MN_IDENTIFIER_OPTION (Missing Mobile
        Node Identifier option) and the identifier in the Mobile Node
        Identifier option carried in the message MUST be set to a zero
        length identifier.

   5.   The local mobility anchor MUST apply the required policy checks,
        as explained in Section 4, to verify that the sender is a
        trusted mobile access gateway authorized to send Proxy Binding
        Update messages on behalf of this mobile node.

   6.   If the local mobility anchor determines that the requesting node
        is not authorized to send Proxy Binding Update messages for the
        identified mobile node, it MUST reject the request and send a
        Proxy Binding Acknowledgement message with the Status field set
        to MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send
        proxy binding updates).

Top      Up      ToC       Page 21 
   7.   If the local mobility anchor cannot identify the mobile node
        based on the identifier present in the Mobile Node Identifier
        option [RFC4283] of the Proxy Binding Update message, it MUST
        reject the request and send a Proxy Binding Acknowledgement
        message with the Status field set to
        NOT_LMA_FOR_THIS_MOBILE_NODE (Not a local mobility anchor for
        this mobile node).

   8.   If the local mobility anchor determines that the mobile node is
        not authorized for the network-based mobility management
        service, it MUST reject the request and send a Proxy Binding
        Acknowledgement message with the Status field set to
        PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).

   9.   The local mobility anchor MUST apply the considerations
        specified in Section 5.5 for processing the Sequence Number
        field and the Timestamp option (if present) in the Proxy Binding
        Update message.

   10.  If there is no Home Network Prefix option(s) (with any value)
        present in the Proxy Binding Update message, the local mobility
        anchor MUST reject the request and send a Proxy Binding
        Acknowledgement message with the Status field set to
        MISSING_HOME_NETWORK_PREFIX_OPTION (Missing Home Network Prefix
        option).

   11.  If the Handoff Indicator option is not present in the Proxy
        Binding Update message, the local mobility anchor MUST reject
        the request and send a Proxy Binding Acknowledgement message
        with the Status field set to MISSING_HANDOFF_INDICATOR_OPTION
        (Missing Handoff Indicator option).

   12.  If the Access Technology Type option is not present in the Proxy
        Binding Update message, the local mobility anchor MUST reject
        the request and send a Proxy Binding Acknowledgement message
        with the Status field set to MISSING_ACCESS_TECH_TYPE_OPTION
        (Missing Access Technology Type option).

   13.  Considerations specified in Section 5.4.1 MUST be applied for
        performing the Binding Cache entry existence test.  If those
        checks specified in Section 5.4.1 result in associating the
        received Proxy Binding Update message to a new mobility session
        creation request, considerations from Section 5.3.2 (Initial
        Binding Registration - New Mobility Session), MUST be applied.
        If those checks result in associating the request to an existing
        mobility session, the following checks determine the next set of
        processing rules that need to be applied.

Top      Up      ToC       Page 22 
        *  If the received Proxy Binding Update message has the lifetime
           value of zero, considerations from Section 5.3.5 (Binding De-
           Registration) MUST be applied.

        *  If the Proxy-CoA in the Binding Cache entry matches the
           source address of the request (or the address in the
           Alternate Care-of Address option, if the option is present),
           considerations from Section 5.3.3 (Binding LIfetime Extension
           - No handoff) MUST be applied.

        *  For all other cases, considerations from Section 5.3.4
           (Binding Lifetime Extension - After handoff) MUST be applied.

   14.  When sending the Proxy Binding Acknowledgement message with any
        Status field value, the message MUST be constructed as specified
        in Section 5.3.6.

5.3.2.  Initial Binding Registration (New Mobility Session)

   1.  If there is at least one instance of the Home Network Prefix
       option present in the Proxy Binding Update message with the
       prefix value set to ALL_ZERO, the local mobility anchor MUST
       allocate one or more home network prefixes to the mobile node and
       assign it to the new mobility session created for the mobile
       node.  The local mobility anchor MUST ensure the allocated
       prefix(es) is not in use by any other node or mobility session.
       The decision on how many prefixes to be allocated for the
       attached interface can be based on a global policy or a policy
       specific to that mobile node.  However, when stateful address
       autoconfiguration using DHCP is supported on the link,
       considerations from Section 6.11 MUST be applied for the prefix
       assignment.

   2.  If the local mobility anchor is unable to allocate any home
       network prefix for the mobile node, it MUST reject the request
       and send a Proxy Binding Acknowledgement message with the Status
       field set to 130 (Insufficient resources).

   3.  If there are one or more Home Network Prefix options present in
       the Proxy Binding Update message (with each of the prefixes set
       to a NON_ZERO value), the local mobility anchor, before accepting
       that request, MUST ensure each one of those prefixes is owned by
       the local mobility anchor, and further that the mobile node is
       authorized to use these prefixes.  If the mobile node is not
       authorized to use any one or more of those prefixes, the local
       mobility anchor MUST reject the request and send a Proxy Binding

Top      Up      ToC       Page 23 
       Acknowledgement message with the Status field set to
       NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not
       authorized for one or more of the requesting home network
       prefixes).

   4.  Upon accepting the request, the local mobility anchor MUST create
       a Binding Cache entry for the mobile node.  It must set the
       fields in the Binding Cache entry to the accepted values for that
       registration.

   5.  If there is no existing bi-directional tunnel to the mobile
       access gateway that sent the request, the local mobility anchor
       MUST establish a bi-directional tunnel to that mobile access
       gateway.  Considerations from Section 5.6.1 MUST be applied for
       managing the dynamically created bi-directional tunnel.

   6.  The local mobility anchor MUST create a prefix route(s) over the
       tunnel to the mobile access gateway for forwarding any traffic
       received for the mobile node's home network prefix(es) associated
       with this mobility session.  The created tunnel and the routing
       state MUST result in the forwarding behavior on the local
       mobility anchor as specified in Section 5.6.2.

   7.  The local mobility anchor MUST send the Proxy Binding
       Acknowledgement message with the Status field set to 0 (Proxy
       Binding Update Accepted).  The message MUST be constructed as
       specified in Section 5.3.6.

5.3.3.  Binding Lifetime Extension (No Handoff)

   1.  Upon accepting the Proxy Binding Update message for extending the
       binding lifetime, received from the same mobile access gateway
       (if the Proxy-CoA in the Binding Cache entry is the same as the
       Proxy-CoA in the request) that last updated the binding, the
       local mobility anchor MUST update the Binding Cache entry with
       the accepted registration values.

   2.  The local mobility anchor MUST send the Proxy Binding
       Acknowledgement message with the Status field set to 0 (Proxy
       Binding Update Accepted).  The message MUST be constructed as
       specified in Section 5.3.6.

Top      Up      ToC       Page 24 
5.3.4.  Binding Lifetime Extension (After Handoff)

   1.  Upon accepting the Proxy Binding Update message for extending the
       binding lifetime, received from a new mobile access gateway (if
       the Proxy-CoA in the Binding Cache entry does not match the
       Proxy-CoA in the request) where the mobile node's mobility
       session is handed off, the local mobility anchor MUST update the
       Binding Cache entry with the accepted registration values.

   2.  The local mobility anchor MUST remove the previously created
       route(s) for the mobile node's home network prefix(es) associated
       with this mobility session.  Additionally, if there are no other
       mobile nodes sharing the dynamically created bi-directional
       tunnel to the previous mobile access gateway, the tunnel SHOULD
       be deleted, applying considerations from section 5.6.1 (if the
       tunnel is a dynamically created tunnel and not a fixed pre-
       established tunnel).

   3.  If there is no existing bi-directional tunnel to the mobile
       access gateway that sent the request, the local mobility anchor
       MUST establish a bi-directional tunnel to that mobile access
       gateway.  Considerations from Section 5.6.1 MUST be applied for
       managing the dynamically created bi-directional tunnel.

   4.  The local mobility anchor MUST create prefix route(s) over the
       tunnel to the mobile access gateway for forwarding any traffic
       received for the mobile node's home network prefix(es) associated
       with that mobility session.  The created tunnel and routing state
       MUST result in the forwarding behavior on the local mobility
       anchor as specified in Section 5.6.2.

   5.  The local mobility anchor MUST send the Proxy Binding
       Acknowledgement message with the Status field set to 0 (Proxy
       Binding Update Accepted).  The message MUST be constructed as
       specified in Section 5.3.6.

5.3.5.  Binding De-Registration

   1.  If the received Proxy Binding Update message with the lifetime
       value of zero, has a Source Address in the IPv6 header (or the
       address in the Alternate Care-of Address option, if the option is
       present) different from what is present in the Proxy-CoA field in
       the Binding Cache entry, the local mobility anchor MUST ignore
       the request.

   2.  Upon accepting the Proxy Binding Update message, with the
       lifetime value of zero, the local mobility anchor MUST wait for
       MinDelayBeforeBCEDelete amount of time, before it deletes the

Top      Up      ToC       Page 25 
       Binding Cache entry.  However, it MUST send the Proxy Binding
       Acknowledgement message with the Status field set to 0 (Proxy
       Binding Update Accepted).  The message MUST be constructed as
       specified in Section 5.3.6.

       *  During this wait period, the local mobility anchor SHOULD drop
          the mobile node's data traffic.

       *  During this wait period, if the local mobility anchor receives
          a valid Proxy Binding Update message for the same mobility
          session with the lifetime value of greater than zero, and if
          that request is accepted, then the Binding Cache entry MUST
          NOT be deleted, but must be updated with the newly accepted
          registration values, and the wait period should be ended.

       *  By the end of this wait period, if the local mobility anchor
          did not receive any valid Proxy Binding Update messages for
          this mobility session, then it MUST delete the Binding Cache
          entry and remove the routing state created for that mobility
          session.  The local mobility anchor can potentially reassign
          the prefix(es) associated with this mobility session to other
          mobile nodes.

5.3.6.  Constructing the Proxy Binding Acknowledgement Message

   o  The local mobility anchor, when sending the Proxy Binding
      Acknowledgement message to the mobile access gateway, MUST
      construct the message as specified below.

          IPv6 header (src=LMAA, dst=Proxy-CoA)
            Mobility header
               - BA    /* P flag must be set to value of 1 */
              Mobility Options
               - Mobile Node Identifier option            (mandatory)
               - Home Network Prefix option(s)            (mandatory)
               - Handoff Indicator option                 (mandatory)
               - Access Technology Type option            (mandatory)
               - Timestamp option                         (optional)
               - Mobile Node Link-layer Identifier option (optional)
               - Link-local Address option                (optional)

            Figure 6: Proxy Binding Acknowledgement Message Format

   o  The Source Address field in the IPv6 header of the message MUST be
      set to the destination address of the received Proxy Binding
      Update message.

Top      Up      ToC       Page 26 
   o  The Destination Address field in the IPv6 header of the message
      MUST be set to the source address of the received Proxy Binding
      Update message.  When there is no Alternate Care-of Address option
      present in the request, the destination address is the same as the
      Proxy-CoA; otherwise, the address may not be the same as the
      Proxy-CoA.

   o  The Mobile Node Identifier option [RFC4283] MUST be present.  The
      identifier field in the option MUST be copied from the Mobile Node
      Identifier option in the received Proxy Binding Update message.
      If the option was not present in the request, the identifier in
      the option MUST be set to a zero length identifier.

   o  At least one Home Network Prefix option MUST be present.

      *  If the Status field is set to a value greater than or equal to
         128, i.e., if the Proxy Binding Update is rejected, all the
         Home Network Prefix options that were present in the request
         (along with their prefix values) MUST be present in the reply.
         But, if there was no Home Network Prefix option present in the
         request, then there MUST be only one Home Network Prefix option
         with the value in the option set to ALL_ZERO.

      *  For all other cases, there MUST be a Home Network Prefix option
         for each of the assigned home network prefixes (for that
         mobility session), and with the prefix value in the option set
         to the allocated prefix value.

   o  The Handoff Indicator option MUST be present.  The handoff
      indicator field in the option MUST be copied from the Handoff
      Indicator option in the received Proxy Binding Update message.  If
      the option was not present in the request, the value in the option
      MUST be set to zero.

   o  The Access Technology Type option MUST be present.  The access
      technology type field in the option MUST be copied from the Access
      Technology Type option in the received Proxy Binding Update
      message.  If the option was not present in the request, the value
      in the option MUST be set to zero.

   o  The Timestamp option MUST be present only if the same option was
      present in the received Proxy Binding Update message and MUST NOT
      be present otherwise.  Considerations from Section 5.5 must be
      applied for constructing the Timestamp option.

   o  The Mobile Node Link-layer Identifier option MUST be present only
      if the same option was present in the received Proxy Binding
      Update message and MUST NOT be present otherwise.  The link-layer

Top      Up      ToC       Page 27 
      identifier value MUST be copied from the Mobile Node Link-layer
      Identifier option present in the received Proxy Binding Update
      message.

   o  The Link-local Address option MUST be present only if the same
      option was present in the received Proxy Binding Update message
      and MUST NOT be present otherwise.  If the Status field in the
      reply is set to a value greater than or equal to 128, i.e., if the
      Proxy Binding Update is rejected, then the link-local address from
      the request MUST be copied to the Link-local Address option in the
      reply, otherwise the following considerations apply.

      *  If the received Proxy Binding Update message has the Link-local
         Address option with ALL_ZERO value and if there is an existing
         Binding Cache entry associated with this request, then the
         link-local address from the Binding Cache entry MUST be copied
         to the Link-local Address option in the reply.

      *  If the received Proxy Binding Update message has the Link-local
         Address option with ALL_ZERO value and if there is no existing
         Binding Cache entry associated with this request, then the
         local mobility anchor MUST generate the link-local address that
         the mobile access gateway can use on the point-to-point link
         shared with the mobile node.  This generated address MUST be
         copied to the Link-local Address option in the reply.  The same
         address MUST also be copied to the link-local address field of
         Binding Cache entry created for this mobility session.

      *  If the received Proxy Binding Update message has the Link-local
         Address option with NON_ZERO value, then the link-local address
         from the request MUST be copied to the Link-local Address
         option in the reply.  The same address MUST also be copied to
         the link-local address field of the Binding Cache entry
         associated with this request (after creating the Binding Cache
         entry, if one does not exist).

   o  If IPsec is used for protecting the signaling messages, the
      message MUST be protected using the security association existing
      between the local mobility anchor and the mobile access gateway.

   o  Unlike in Mobile IPv6 [RFC3775], the Type 2 Routing header MUST
      NOT be present in the IPv6 header of the packet.

5.4.  Multihoming Support

   This specification allows mobile nodes to connect to a Proxy Mobile
   IPv6 domain through multiple interfaces for simultaneous access.  The
   following are the key aspects of this multihoming support.

Top      Up      ToC       Page 28 
   o  When a mobile node connects to a Proxy Mobile IPv6 domain through
      multiple interfaces for simultaneous access, the local mobility
      anchor MUST allocate a mobility session for each of the attached
      interfaces.  Each mobility session should be managed under a
      separate Binding Cache entry and with its own lifetime.

   o  The local mobility anchor MAY allocate more than one home network
      prefix for a given interface of the mobile node.  However, all the
      prefixes associated with a given interface MUST be managed as part
      of one mobility session, associated with that interface.

   o  The local mobility anchor MUST allow for a handoff between two
      different interfaces of a mobile node.  In such a scenario, all
      the home network prefixes associated with one interface (part of
      one mobility session) will be associated with a different
      interface of the mobile node.  The decision on when to create a
      new mobility session and when to update an existing mobility
      session MUST be based on the Handover hint present in the Proxy
      Binding Update message and under the considerations specified in
      this section.

5.4.1.  Binding Cache Entry Lookup Considerations

   There can be multiple Binding Cache entries for a given mobile node.
   When doing a lookup for a mobile node's Binding Cache entry for
   processing a received Proxy Binding Update message, the local
   mobility anchor MUST apply the following multihoming considerations
   (in the below specified order, starting with Section 5.4.1.1).  These
   rules are chained with the processing rules specified in Section 5.3.

5.4.1.1.  Home Network Prefix Option (NON_ZERO Value) Present in the
          Request

 +=====================================================================+
 |                Registration/De-Registration Message                 |
 +=====================================================================+
 |             At least one HNP Option with NON_ZERO Value             |
 +=====================================================================+
 |                                 ATT                                 |
 +=====================================================================+
 |   MN-LL-Identifier Opt Present   | MN-LL-Identifier Opt Not Present |
 +=====================================================================+
 |                                 HI                                  |
 +==================================+==================================+
 | BCE Lookup Key: Any of the Home Network Prefixes from the request   |
 +=====================================================================+

   Figure 7: Binding Cache Entry (BCE) Lookup Using Home Network Prefix

Top      Up      ToC       Page 29 
   If there is at least one Home Network Prefix option present in the
   request with a NON_ZERO prefix value and irrespective of the presence
   of the Mobile Node Link-layer Identifier option in the request, the
   following considerations MUST be applied.  If there is more than one
   instance of the Home Network Prefix option, any one of the Home
   Network Prefix options present in the request (with NON_ZERO prefix
   value) can be used for locating the Binding Cache entry.

   1.  The local mobility anchor MUST verify if there is an existing
       Binding Cache entry with one of its home network prefixes
       matching the prefix value in one of the Home Network Prefix
       options of the received Proxy Binding Update message.

   2.  If a Binding Cache entry does not exist (with one of its home
       network prefixes in the Binding Cache entry matching the prefix
       value in one of the Home Network Prefix options of the received
       Proxy Binding Update message), the request MUST be considered as
       a request for creating a new mobility session.

   3.  If there exists a Binding Cache entry (with one of its home
       network prefixes in the Binding Cache entry matching the prefix
       value in one of the Home Network Prefix options of the received
       Proxy Binding Update message), but if the mobile node identifier
       in the entry does not match the mobile node identifier in the
       Mobile Node Identifier option of the received Proxy Binding
       Update message, the local mobility anchor MUST reject the request
       with the Status field value set to
       NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not
       authorized for one or more of the requesting home network
       prefixes).

   4.  If there exists a Binding Cache entry (matching MN-Identifier and
       one of its home network prefixes in the Binding Cache entry
       matching the prefix value in one of the Home Network Prefix
       options of the received Proxy Binding Update message), but if all
       the prefixes in the request do not match all the prefixes in the
       Binding Cache entry, or if they do not match in count, then the
       local mobility anchor MUST reject the request with the Status
       field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home
       network prefixes listed in the BCE do not match all the prefixes
       in the received PBU).

   5.  If there exists a Binding Cache entry (matching MN-Identifier and
       all the home network prefixes in the Binding Cache entry matching
       all the home network prefixes in the received Proxy Binding
       Update message) and if any one or more of these below stated
       conditions are true, the request MUST be considered as a request
       for updating that Binding Cache entry.

Top      Up      ToC       Page 30 
       *  If there is a Mobile Node Link-layer Identifier option present
          in the request and if the link-layer identifier in the option
          matches the link-layer identifier of the Binding Cache entry
          and the access technology type in the Access Technology Type
          option present in the request matches the access technology
          type in the Binding Cache entry.

       *  If the Handoff Indicator field in the Handoff Indicator option
          present in the request is set to a value of 2 (Handoff between
          two different interfaces of the mobile node).

       *  If there is no Mobile Node Link-layer Identifier option
          present in the request, the link-layer identifier value in the
          Binding Cache entry is set to ALL_ZERO, the access technology
          type field in the Access Technology Type option present in the
          request matches the access technology type in the Binding
          Cache entry, and if the Handoff Indicator field in the Handoff
          Indicator option present in the request is set to a value of 3
          (Handoff between mobile access gateways for the same
          interface).

       *  If the Proxy-CoA in the Binding Cache entry matches the source
          address of the request (or the address in the Alternate
          Care-of Address option, if the option is present) and if the
          access technology type field in the Access Technology Type
          option present in the request matches the access technology
          type in the Binding Cache entry.

   6.  For all other cases, the message MUST be considered as a request
       for creating a new mobility session.  However, if the received
       Proxy Binding Update message has the lifetime value of zero and
       if the request cannot be associated with any existing mobility
       session, the message MUST be silently ignored.

Top      Up      ToC       Page 31 
5.4.1.2.  Mobile Node Link-layer Identifier Option Present in the
          Request

 +=====================================================================+
 |                   Registration/De-Registration Message              |
 +=====================================================================+
 |                  No HNP option with a NON_ZERO Value                |
 +=====================================================================+
 |                                 ATT                                 |
 +=====================================================================+
 |         MN-LL-Identifier Option Present (NON_ZERO Value)            |
 +=====================================================================+
 |                                 HI                                  |
 +==================================+==================================+
 |  BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier)          |
 +=====================================================================+

             Figure 8: BCE Lookup Using Link-layer Identifier

   If there is no Home Network Prefix option present in the request with
   a NON_ZERO prefix value, but if there is a Mobile Node Link-layer
   Identifier option present in the request, then the following
   considerations MUST be applied for locating the Binding Cache entry.

   1.  The local mobility anchor MUST verify if there is an existing
       Binding Cache entry, with the mobile node identifier matching the
       identifier in the received Mobile Node Identifier option, access
       technology type matching the value in the received Access
       Technology Type option, and the link-layer identifier value
       matching the identifier in the received Mobile Node Link-layer
       Identifier option.

   2.  If there exists a Binding Cache entry (matching MN-Identifier,
       Access Technology Type (ATT), and MN-LL-Identifier), the request
       MUST be considered as a request for updating that Binding Cache
       entry.

   3.  If there does not exist a Binding Cache entry (matching MN-
       Identifier, ATT, and MN-LL-Identifier) and the Handoff Indicator
       field in the Handoff Indicator option present in the request is
       set to a value of 2 (Handoff between two different interfaces of
       the mobile node).  The local mobility anchor MUST apply the
       following additional considerations.

       *  The local mobility anchor MUST verify if there exists one and
          only one Binding Cache entry with the mobile node identifier
          matching the identifier in the Mobile Node Identifier option
          present in the request and for any link-layer identifier

Top      Up      ToC       Page 32 
          value.  If there exists only one such entry (matching the MN-
          Identifier), the request MUST be considered as a request for
          updating that Binding Cache entry.

   4.  If there does not exist a Binding Cache entry (matching MN-
       Identifier, ATT, and MN-LL-Identifier) and if the Handoff
       Indicator field in the Handoff Indicator option present in the
       request is set to a value of 4 (Handoff state unknown), the local
       mobility anchor MUST apply the following additional
       considerations.

       *  The local mobility anchor MUST verify if there exists one and
          only one Binding Cache entry with the mobile node identifier
          matching the identifier in the Mobile Node Identifier option
          present in the request and for any link-layer identifier
          value.  If there exists only one such entry (matching the MN-
          Identifier), the local mobility anchor SHOULD wait until the
          existing Binding Cache entry is de-registered by the
          previously serving mobile access gateway, before the request
          can be considered as a request for updating that Binding Cache
          entry.  However, if there is no de-registration message that
          is received within MaxDelayBeforeNewBCEAssign amount of time,
          the local mobility anchor, upon accepting the request, MUST
          consider the request as a request for creating a new mobility
          session.  The local mobility anchor MAY also choose to create
          a new mobility session without waiting for a de-registration
          message, and this should be configurable on the local mobility
          anchor.

   5.  For all other cases, the message MUST be considered as a request
       for creating a new mobility session.  However, if the received
       Proxy Binding Update message has the lifetime value of zero and
       if the request cannot be associated with any existing mobility
       session, the message MUST be silently ignored.

Top      Up      ToC       Page 33 
5.4.1.3.  Mobile Node Link-layer Identifier Option Not Present in the
          Request

 +=====================================================================+
 |                 Registration/De-Registration Message                |
 +=====================================================================+
 |                 No HNP option with a NON_ZERO Value                 |
 +=====================================================================+
 |                                 ATT                                 |
 +=====================================================================+
 |                 MN-LL-Identifier Option Not Present                 |
 +=====================================================================+
 |                                 HI                                  |
 +==================================+==================================+
 |                   BCE Lookup Key: (MN-Identifier)                   |
 +=====================================================================+

             Figure 9: BCE Lookup Using Mobile Node Identifier

   If there is no Home Network Prefix option present in the request with
   a NON_ZERO prefix value and if there is also no Mobile Node Link-
   layer Identifier option present in the request, then the following
   considerations MUST be applied for locating the Binding Cache entry.

   1.  The local mobility anchor MUST verify if there exists one and
       only one Binding Cache entry with the mobile node identifier
       matching the identifier in the Mobile Node Identifier option
       present in the request.

   2.  If there exists only one such entry (matching the MN-Identifier)
       and the Handoff Indicator field in the Handoff Indicator option
       present in the request is set to a value of 2 (Handoff between
       two different interfaces of the mobile node) or set to a value of
       3 (Handoff between mobile access gateways for the same
       interface), then the request MUST be considered as a request for
       updating that Binding Cache entry.

   3.  If there exists only one such entry (matching the MN-Identifier)
       and the Handoff Indicator field in the Handoff Indicator option
       present in the request is set to a value of 4 (Handoff state
       unknown), the local mobility anchor SHOULD wait until the
       existing Binding Cache entry is de-registered by the previously
       serving mobile access gateway before the request can be
       considered as a request for updating that Binding Cache entry.
       However, if there is no de-registration message that is received
       within MaxDelayBeforeNewBCEAssign amount of time, the local
       mobility anchor, upon accepting the request, MUST consider the
       request as a request for creating a new mobility session.  The

Top      Up      ToC       Page 34 
       local mobility anchor MAY also choose to create a new mobility
       session without waiting for a de-registration message, and this
       should be configurable on the local mobility anchor.

   4.  For all other cases, the message MUST be considered as a request
       for creating a new mobility session.  However, if the received
       Proxy Binding Update message has the lifetime value of zero and
       if the request cannot be associated with any existing mobility
       session, the message MUST be silently ignored.

5.5.  Timestamp Option for Message Ordering

   Mobile IPv6 [RFC3775] uses the Sequence Number field in binding
   registration messages as a way for the home agent to process the
   binding updates in the order they were sent by a mobile node.  The
   home agent and the mobile node are required to manage this counter
   over the lifetime of a binding.  However, in Proxy Mobile IPv6, as
   the mobile node moves from one mobile access gateway to another and
   in the absence of mechanisms such as context transfer between the
   mobile access gateways, the serving mobile access gateway will be
   unable to determine the sequence number that it needs to use in the
   signaling messages.  Hence, the sequence number scheme, as specified
   in [RFC3775], will be insufficient for Proxy Mobile IPv6.

   If the local mobility anchor cannot determine the sending order of
   the received Proxy Binding Update messages, it may potentially
   process an older message sent by a mobile access gateway where the
   mobile node was previously anchored, but delivered out of order,
   resulting in incorrectly updating the mobile node's Binding Cache
   entry and creating a routing state for tunneling the mobile node's
   traffic to the previous mobile access gateway.

   For solving this problem, this specification adopts two alternative
   solutions.  One is based on timestamps and the other based on
   sequence numbers, as defined in [RFC3775].

   The basic principle behind the use of timestamps in binding
   registration messages is that the node generating the message inserts
   the current time of day, and the node receiving the message checks
   that this timestamp is greater than all previously accepted
   timestamps.  The timestamp-based solution may be used when the
   serving mobile access gateways in a Proxy Mobile IPv6 domain do not
   have the ability to obtain the last sequence number that was sent in
   a Proxy Binding Update message for updating a given mobile node's
   binding.

Top      Up      ToC       Page 35 
   Clock drift reduces the effectiveness of the timestamp mechanism.
   The time required for reconnection is the total of the time required
   for the mobile node to roam between two mobile access gateways and
   the time required for the serving mobile access gateway to detect the
   mobile node on its access link and construct the Proxy Binding Update
   message.  If the clock skew on any one of these two neighboring
   mobile access gateways (relative to the common time source used for
   clock synchronization) is more than half this reconnection time, the
   timestamp solution will not predictably work in all cases and hence
   SHOULD NOT be used.

   As an alternative to the Timestamp-based approach, the specification
   also allows the use of Sequence-Number-based scheme, as specified in
   [RFC3775].  However, for this scheme to work, the serving mobile
   access gateway in a Proxy Mobile IPv6 domain MUST have the ability to
   obtain the last sequence number that was sent in a binding
   registration message for that mobility session.  The sequence number
   MUST be maintained on a mobile node's per mobility session basis and
   MUST be available to the serving mobile access gateway.  This may be
   achieved by using context transfer schemes or by maintaining the
   sequence number in a policy store.  However, the specific details on
   how the mobile node's sequence number is made available to the
   serving mobile access gateway prior to sending the Proxy Binding
   Update message is outside the scope of this document.

   Using the Timestamp-Based Approach:

   1.  A local mobility anchor implementation MUST support the Timestamp
       option.  If the Timestamp option is present in the received Proxy
       Binding Update message, then the local mobility anchor MUST
       include a valid Timestamp option in the Proxy Binding
       Acknowledgement message that it sends to the mobile access
       gateway.

   2.  All the mobility entities in a Proxy Mobile IPv6 domain that are
       exchanging binding registration messages using the Timestamp
       option MUST have adequately synchronized time-of-day clocks.
       This is the essential requirement for this solution to work.  If
       this requirement is not met, the solution will not predictably
       work in all cases.

   3.  The mobility entities in a Proxy Mobile IPv6 domain SHOULD
       synchronize their clocks to a common time source.  For
       synchronizing the clocks, the nodes MAY use the Network Time
       Protocol [RFC4330].  Deployments MAY also adopt other approaches
       suitable for that specific deployment.  Alternatively, if there
       is a mobile node generated timestamp that is increasing at every
       attachment to the access link and if that timestamp is available

Top      Up      ToC       Page 36 
       to the mobile access gateway (e.g., the Timestamp option in the
       SEND [RFC3971] messages that the mobile node sends), the mobile
       access gateway can use this timestamp or sequence number in the
       Proxy Binding Update messages and does not have to depend on any
       external clock source.  However, the specific details on how this
       is achieved are outside the scope of this document.

   4.  When generating the timestamp value for building the Timestamp
       option, the mobility entities MUST ensure that the generated
       timestamp is the elapsed time past the same reference epoch, as
       specified in the format for the Timestamp option (Section 8.8).

   5.  If the Timestamp option is present in the received Proxy Binding
       Update message, the local mobility anchor MUST ignore the
       sequence number field in the message.  However, it MUST copy the
       sequence number from the received Proxy Binding Update message to
       the Proxy Binding Acknowledgement message.

   6.  Upon receipt of a Proxy Binding Update message with the Timestamp
       option, the local mobility anchor MUST check the timestamp field
       for validity.  In order for it to be considered valid, the
       following MUST be true.

       *  The timestamp value contained in the Timestamp option MUST be
          close enough (within TimestampValidityWindow amount of time
          difference) to the local mobility anchor's time-of-day clock.
          However, if the flag MobileNodeGeneratedTimestampInUse is set
          to a value of 1, the local mobility anchor MUST ignore this
          check and perform only the following check.

       *  The timestamp MUST be greater than all previously accepted
          timestamps in the Proxy Binding Update messages sent for that
          mobile node.

   7.  If the timestamp value in the received Proxy Binding Update is
       valid (validity as specified in the above considerations) or if
       the flag MobileNodeGeneratedTimestampInUse is set to value of 1,
       the local mobility anchor MUST return the same timestamp value in
       the Timestamp option included in the Proxy Binding
       Acknowledgement message that it sends to the mobile access
       gateway.

   8.  If the timestamp value in the received Proxy Binding Update is
       lower than the previously accepted timestamp in the Proxy Binding
       Update messages sent for that mobility binding, the local
       mobility anchor MUST reject the Proxy Binding Update message and
       send a Proxy Binding Acknowledgement message with the Status
       field set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower

Top      Up      ToC       Page 37 
       than previously accepted timestamp).  The message MUST also
       include the Timestamp option with the value set to the current
       time of day on the local mobility anchor.

   9.  If the timestamp value in the received Proxy Binding Update is
       not valid (validity as specified in the above considerations),
       the local mobility anchor MUST reject the Proxy Binding Update
       and send a Proxy Binding Acknowledgement message with the Status
       field set to TIMESTAMP_MISMATCH (Timestamp mismatch).  The
       message MUST also include the Timestamp option with the value set
       to the current time of day on the local mobility anchor.

   Using the Sequence-Number-Based Approach:

   1.  If the Timestamp option is not present in the received Proxy
       Binding Update message, the local mobility anchor MUST fall back
       to the Sequence-Number-based scheme.  It MUST process the
       sequence number field as specified in [RFC3775].  Also, it MUST
       NOT include the Timestamp option in the Proxy Binding
       Acknowledgement messages that it sends to the mobile access
       gateway.

   2.  An implementation MUST support the Sequence-Number-based scheme,
       as specified in [RFC3775].

   3.  The Sequence-Number-based approach can be used only when there is
       some mechanism (such as context transfer procedure between mobile
       access gateways) that allows the serving mobile access gateway to
       obtain the last sequence number that was sent in a Proxy Binding
       Update message for updating a given mobile node's binding.

5.6.  Routing Considerations

5.6.1.  Bi-Directional Tunnel Management

   The bi-directional tunnel MUST be used for routing the mobile node's
   data traffic between the mobile access gateway and the local mobility
   anchor.  A tunnel hides the topology and enables a mobile node to use
   address(es) from its home network prefix(es) from any access link in
   that Proxy Mobile IPv6 domain.  A tunnel may be created dynamically
   when needed and removed when not needed.  However, implementations
   MAY choose to use static pre-established tunnels instead of
   dynamically creating and tearing them down on a need basis.  The
   following considerations MUST be applied when using dynamically
   created tunnels.

Top      Up      ToC       Page 38 
   o  A bi-directional tunnel MUST be established between the local
      mobility anchor and the mobile access gateway and the local
      mobility anchor with IPv6-in-IPv6 encapsulation, as described in
      [RFC2473].  The tunnel endpoints are the Proxy-CoA and LMAA.
      However, when using IPv4 transport, the endpoints of the tunnel
      are IPv4-LMAA and IPv4-Proxy-CoA with the encapsulation mode as
      specified in [IPV4-PMIP6].

   o  Implementations MAY use a software timer for managing the tunnel
      lifetime and a counter for keeping a count of all the mobile nodes
      that are sharing the tunnel.  The timer value can be set to the
      accepted binding lifetime and can be updated after each periodic
      re-registration for extending the lifetime.  If the tunnel is
      shared for multiple mobile nodes, the tunnel lifetime must be set
      to the highest binding lifetime that is granted to any one of
      those mobile nodes sharing that tunnel.

   o  The tunnel SHOULD be deleted when either the tunnel lifetime
      expires or when there are no mobile nodes sharing the tunnel.

5.6.2.  Forwarding Considerations

   Intercepting Packets Sent to the Mobile Node's Home Network:

   o  When the local mobility anchor is serving a mobile node, it MUST
      be able to receive packets that are sent to the mobile node's home
      network.  In order for it to receive those packets, it MUST
      advertise a connected route in to the Routing Infrastructure for
      the mobile node's home network prefix(es) or for an aggregated
      prefix with a larger scope.  This essentially enables IPv6 routers
      in that network to detect the local mobility anchor as the last-
      hop router for the mobile node's home network prefix(es).

   Forwarding Packets to the Mobile Node:

   o  On receiving a packet from a correspondent node with the
      destination address matching a mobile node's home network
      prefix(es), the local mobility anchor MUST forward the packet
      through the bi-directional tunnel set up for that mobile node.

   o  The format of the tunneled packet is shown below.  Considerations
      from [RFC2473] MUST be applied for IPv6 encapsulation.  However,
      when using IPv4 transport, the format of the packet is as
      described in [IPV4-PMIP6].

Top      Up      ToC       Page 39 
        IPv6 header (src= LMAA, dst= Proxy-CoA  /* Tunnel Header */
           IPv6 header (src= CN, dst= MN-HOA )  /* Packet Header */
              Upper layer protocols             /* Packet Content*/

                  Figure 10: Tunneled Packet from LMA to MAG

   o  The format of the tunneled packet is shown below, when payload
      protection using IPsec is enabled for the mobile node's data
      traffic.  However, when using IPv4 transport, the format of the
      packet is as described in [IPV4-PMIP6].

        IPv6 header (src= LMAA, dst= Proxy-CoA     /* Tunnel Header */
           ESP Header in tunnel mode               /* ESP Header */
              IPv6 header (src= CN, dst= MN-HoA )  /* Packet Header */
                 Upper layer protocols             /* Packet Content*/

      Figure 11: Tunneled Packet from LMA to MAG with Payload Protection

   Forwarding Packets Sent by the Mobile Node:

   o  All the reverse tunneled packets that the local mobility anchor
      received from the mobile access gateway, after removing the tunnel
      header MUST be routed to the destination specified in the inner
      packet header.  These routed packets will have the Source Address
      field set to the mobile node's home address.  Considerations from
      [RFC2473] MUST be applied for IPv6 decapsulation.

5.6.3.  Explicit Congestion Notification (ECN) Considerations for Proxy
        Mobile IPv6 Tunnels

   This section describes how the ECN information needs to be handled by
   the mobility agents at the tunnel entry and exit points.  The ECN
   considerations for IP tunnels are specified in [RFC3168], and the
   same considerations apply to Proxy Mobile IPv6 tunnels (using IPv6-
   in-IPv6 encapsulation mode).  Specifically, the full-functionality
   option MUST be supported.  The relevant ECN considerations from
   [RFC3168] are summarized here for convenience.

   Encapsulation Considerations:

   o  If the Explicit Congestion Notification (ECN) field in the inner
      header is set to ECT(0) or ECT(1), where ECT stands for ECN-
      Capable Transport (ECT), the ECN field from the inner header MUST
      be copied to the outer header.  Additionally, when payload
      protection using IPsec is enabled for the mobile node's data
      traffic, the ECN considerations from [RFC4301] MUST be applied.

Top      Up      ToC       Page 40 
   Decapsulation Considerations:

   o  If the Explicit Congestion Notification (ECN) field in the inner
      header is set to ECT(0) or ECT(1), and if the ECN field in the
      outer header is set to Congestion Experienced (CE), then the ECN
      field in the inner header MUST be set to CE.  Otherwise, the ECN
      field in the inner header MUST NOT be modified.  Additionally,
      when payload protection using IPsec is enabled for the mobile
      node's data traffic, the ECN considerations from [RFC4301] MUST be
      applied.

5.7.  Local Mobility Anchor Address Discovery

   Dynamic Home Agent Address Discovery (DHAAD), as explained in Section
   10.5 of [RFC3775], allows a mobile node to discover all the home
   agents on its home link by sending an ICMP Home Agent Address
   Discovery Request message to the Mobile IPv6 Home Agent's anycast
   address, derived from its home network prefix.

   The DHAAD message in the current form cannot be used in Proxy Mobile
   IPv6 for discovering the address of the mobile node's local mobility
   anchor.  In Proxy Mobile IPv6, the local mobility anchor will not be
   able to receive any messages sent to the Mobile IPv6 Home Agent's
   anycast address corresponding to the mobile node's home network
   prefix(es), as the prefix(es) is not hosted on any of its interfaces.
   Further, the mobile access gateway will not predictably be able to
   locate the serving local mobility anchor that has the mobile node's
   binding cache entry.  Hence, this specification does not support
   Dynamic Home Agent Address Discovery protocol.

   In Proxy Mobile IPv6, the address of the local mobility anchor
   configured to serve a mobile node can be discovered by the mobility
   access gateway entity via other means.  The LMA to be assigned to a
   mobile node may be a configured entry in the mobile node's policy
   profile, or it may be obtained through mechanisms outside the scope
   of this document.

5.8.  Mobile Prefix Discovery Considerations

   This specification does not support mobile prefix discovery.  The
   mobile prefix discovery mechanism as specified in [RFC3775] is not
   applicable to Proxy Mobile IPv6.

Top      Up      ToC       Page 41 
5.9.  Route Optimization Considerations

   The Route Optimization in Mobile IPv6, as defined in [RFC3775],
   enables a mobile node to communicate with a correspondent node
   directly using its care-of address and further the Return Routability
   procedure enables the correspondent node to have reasonable trust
   that the mobile node is reachable at both its home address and
   care-of address.

   This specification does not support the Route Optimization specified
   in Mobile IPv6 [RFC3775].  However, this specification does support
   another form of route optimization, as specified in Section 6.10.3.



(page 41 continued on part 3)

Next RFC Part