RFC 5213
Proxy Mobile IPv6
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.
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.
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.
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).
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.
* 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
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.
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
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.
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
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.
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
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.
* 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.
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
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.
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
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.
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
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
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.
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].
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.
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.
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)
