Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5213

Proxy Mobile IPv6

Pages: 92
Proposed Standard
Errata
Updated by:  65437864
Part 2 of 4 – Pages 17 to 41
First   Prev   Next

Top   ToC   RFC5213 - Page 17   prevText

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