< draft-ietf-netlmm-proxymip6-17.txt   draft-ietf-netlmm-proxymip6-18.txt >
NETLMM WG S. Gundavelli (Editor) NETLMM WG S. Gundavelli (Editor)
Internet-Draft K. Leung Internet-Draft K. Leung
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: November 28, 2008 V. Devarapalli Expires: December 1, 2008 V. Devarapalli
Wichorus Wichorus
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
B. Patil B. Patil
Nokia Siemens Networks Nokia Siemens Networks
May 27, 2008 May 30, 2008
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-17.txt draft-ietf-netlmm-proxymip6-18.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 28, 2008. This Internet-Draft will expire on December 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Network-based mobility management enables IP mobility for a host Network-based mobility management enables IP mobility for a host
without requiring its participation in any mobility related without requiring its participation in any mobility related
signaling. The Network is responsible for managing IP mobility on signaling. The Network is responsible for managing IP mobility on
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.1. Conventions used in this document . . . . . . . . . . . . 5 2.1. Conventions used in this document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 9 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 9
4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 15 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 15
4.1. Peer Authorization Database (PAD) Example Entries . . . . 16 4.1. Peer Authorization Database (PAD) Example Entries . . . . 16
4.2. Security Policy Database (SPD) Example Entries . . . . . . 17 4.2. Security Policy Database (SPD) Example Entries . . . . . . 17
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 18 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 18
5.1. Extensions to Binding Cache Entry Data Structure . . . . . 18 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 18
5.2. Supported Home Network Prefix Models . . . . . . . . . . . 19 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 19
5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 20 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 20
5.3.1. Processing Binding Registrations . . . . . . . . . . . 20 5.3.1. Processing Proxy Binding Updates . . . . . . . . . . . 20
5.3.2. Initial Binding Registration (New Mobility Session) . 22 5.3.2. Initial Binding Registration (New Mobility Session) . 22
5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 23 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 23
5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 24 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 24
5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 25 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 25
5.3.6. Constructing the Proxy Binding Acknowledgement 5.3.6. Constructing the Proxy Binding Acknowledgement
Message . . . . . . . . . . . . . . . . . . . . . . . 25 Message . . . . . . . . . . . . . . . . . . . . . . . 25
5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 28 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 28
5.4.1. Binding Cache entry lookup considerations . . . . . . 28 5.4.1. Binding Cache entry lookup considerations . . . . . . 28
5.5. Timestamp Option for Message Ordering . . . . . . . . . . 34 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 34
5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 37 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 37
skipping to change at page 3, line 40 skipping to change at page 3, line 40
8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 76 8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 76
8.7. Link-local Address Option . . . . . . . . . . . . . . . . 77 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 77
8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 78 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 78
8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 78 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 78
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 80 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 80
9.1. Local Mobility Anchor - Configuration Variables . . . . . 80 9.1. Local Mobility Anchor - Configuration Variables . . . . . 80
9.2. Mobile Access Gateway - Configuration Variables . . . . . 81 9.2. Mobile Access Gateway - Configuration Variables . . . . . 81
9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 82 9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 82
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
11. Security Considerations . . . . . . . . . . . . . . . . . . . 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 84
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 84
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.1. Normative References . . . . . . . . . . . . . . . . . . . 85 13.1. Normative References . . . . . . . . . . . . . . . . . . . 85
13.2. Informative References . . . . . . . . . . . . . . . . . . 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 86
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 87 Infrastructure . . . . . . . . . . . . . . . . . . . 87
Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 88 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89
Intellectual Property and Copyright Statements . . . . . . . . . . 91 Intellectual Property and Copyright Statements . . . . . . . . . . 91
1. Introduction 1. Introduction
skipping to change at page 8, line 30 skipping to change at page 8, line 30
Policy Profile is an abstract term for referring to a set of Policy Profile is an abstract term for referring to a set of
configuration parameters that are configured for a given mobile configuration parameters that are configured for a given mobile
node. The mobility entities in the Proxy Mobile IPv6 domain node. The mobility entities in the Proxy Mobile IPv6 domain
require access to these parameters for providing the mobility require access to these parameters for providing the mobility
management to a given mobile node. The specific details on how management to a given mobile node. The specific details on how
the network entities obtain this policy profile is outside the the network entities obtain this policy profile is outside the
scope of this document. scope of this document.
Proxy Binding Update (PBU) Proxy Binding Update (PBU)
A binding registration request message sent by a mobile access A request message sent by a mobile access gateway to a mobile
gateway to a mobile node's local mobility anchor for establishing node's local mobility anchor for establishing a binding between
a binding between the mobile node's home network prefix(es) the mobile node's home network prefix(es) assigned to a given
assigned to a given interface of a mobile node and its current interface of a mobile node and its current care-of address (Proxy-
care-of address (Proxy-CoA). CoA).
Proxy Binding Acknowledgement (PBA) Proxy Binding Acknowledgement (PBA)
A binding registration reply message sent by a local mobility A reply message sent by a local mobility anchor in response to a
anchor in response to a Proxy Binding Update request message that Proxy Binding Update message that it received from a mobile access
it received from a mobile access gateway. gateway.
Per-MN-Prefix & Shared-Prefix Models Per-MN-Prefix & Shared-Prefix Models
The term, Per-MN-Prefix model, is used to refer to an addressing The term, Per-MN-Prefix model, is used to refer to an addressing
model where there is a unique network prefix or prefixes assigned model where there is a unique network prefix or prefixes assigned
for each node. The term, Shared-Prefix model, is used to refer to for each node. The term, Shared-Prefix model, is used to refer to
an addressing model where the prefix(es) are shared by more than an addressing model where the prefix(es) are shared by more than
one node. This specification supports the Per-MN-Prefix model and one node. This specification supports the Per-MN-Prefix model and
does not support the Shared-Prefix model. does not support the Shared-Prefix model.
skipping to change at page 13, line 21 skipping to change at page 13, line 21
mobile node's home link. It sends Router Advertisement messages to mobile node's home link. It sends Router Advertisement messages to
the mobile node on the access link advertising the mobile node's home the mobile node on the access link advertising the mobile node's home
network prefix(es) as the hosted on-link-prefix(es). network prefix(es) as the hosted on-link-prefix(es).
The mobile node on receiving these Router Advertisement messages on The mobile node on receiving these Router Advertisement messages on
the access link will attempt to configure its interface either using the access link will attempt to configure its interface either using
stateful or stateless address configuration modes, based on the modes stateful or stateless address configuration modes, based on the modes
that are permitted on that access link as indicated in Router that are permitted on that access link as indicated in Router
Advertisement messages. At the end of a successful address Advertisement messages. At the end of a successful address
configuration procedure, the mobile node will end up with one or more configuration procedure, the mobile node will end up with one or more
addresses from its home network prefixes(es). addresses from its home network prefix(es).
Once the address configuration is complete, the mobile node has one Once the address configuration is complete, the mobile node has one
or more valid addresses from its home network prefix(es) at the or more valid addresses from its home network prefix(es) at the
current point of attachment. The serving mobile access gateway and current point of attachment. The serving mobile access gateway and
the local mobility anchor also have proper routing states for the local mobility anchor also have proper routing states for
handling the traffic sent to and from the mobile node using any one handling the traffic sent to and from the mobile node using any one
or more of the addresses from its home network prefix(es). or more of the addresses from its home network prefix(es).
The local mobility anchor, being the topological anchor point for the The local mobility anchor, being the topological anchor point for the
mobile node's home network prefix(es), receives any packets that are mobile node's home network prefix(es), receives any packets that are
skipping to change at page 15, line 11 skipping to change at page 15, line 11
a specific message ordering, it is possible the registration message a specific message ordering, it is possible the registration message
from the n-MAG may arrive before the de-registration message from the from the n-MAG may arrive before the de-registration message from the
p-MAG arrives. p-MAG arrives.
After obtaining the initial address configuration in the Proxy Mobile After obtaining the initial address configuration in the Proxy Mobile
IPv6 domain, if the mobile node changes its point of attachment, the IPv6 domain, if the mobile node changes its point of attachment, the
mobile access gateway on the previous link will detect the mobile mobile access gateway on the previous link will detect the mobile
node's detachment from the link and will signal the local mobility node's detachment from the link and will signal the local mobility
anchor and will remove the binding and routing state for that mobile anchor and will remove the binding and routing state for that mobile
node. The local mobility anchor upon receiving this request will node. The local mobility anchor upon receiving this request will
identify the corresponding mobility session for which the binding identify the corresponding mobility session for which the request was
update request was received and once it accepts the request will wait received and once it accepts the request will wait for certain amount
for certain amount of time for allowing the mobile access gateway on of time for allowing the mobile access gateway on the new link to
the new link to update the binding. However, if it does not receive update the binding. However, if it does not receive any Proxy
any binding update request within that given amount of time, it will Binding Update message within that given amount of time, it will
delete the binding cache entry. delete the binding cache entry.
The mobile access gateway on the new access link upon detecting the The mobile access gateway on the new access link upon detecting the
mobile node on its access link will signal the local mobility anchor mobile node on its access link will signal the local mobility anchor
for updating the binding state. Once that signaling is complete, the for updating the binding state. Once that signaling is complete, the
serving mobile access gateway will send the Router Advertisements serving mobile access gateway will send the Router Advertisements
containing the mobile node's home network prefix(es) and this will containing the mobile node's home network prefix(es) and this will
ensure the mobile node will not detect any change with respect to its ensure the mobile node will not detect any change with respect to its
layer-3 attachment of its interface. layer-3 attachment of its interface.
skipping to change at page 16, line 42 skipping to change at page 16, line 42
This section describes PAD entries [RFC-4301] on the mobile access This section describes PAD entries [RFC-4301] on the mobile access
gateway and the local mobility anchor. The PAD entries are only gateway and the local mobility anchor. The PAD entries are only
example configurations. Note that the PAD is a logical concept and a example configurations. Note that the PAD is a logical concept and a
particular mobile access gateway or a local mobility anchor particular mobile access gateway or a local mobility anchor
implementation can implement the PAD in any implementation specific implementation can implement the PAD in any implementation specific
manner. The PAD state may also be distributed across various manner. The PAD state may also be distributed across various
databases in a specific implementation. databases in a specific implementation.
In the example shown below, the identity of the local mobility anchor In the example shown below, the identity of the local mobility anchor
is assumed to lma_identity_1 and the identity of the mobile access is assumed to be lma_identity_1 and the identity of the mobile access
gateway is assumed to be mag_identity_1. gateway is assumed to be mag_identity_1.
mobile access gateway PAD: mobile access gateway PAD:
- IF remote_identity = lma_identity_1 - IF remote_identity = lma_identity_1
Then authenticate (shared secret/certificate/EAP) Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SAs for remote address lma_address_1 and authorize CHILD_SAs for remote address lma_address_1
local mobility anchor PAD: local mobility anchor PAD:
- IF remote_identity = mag_identity_1 - IF remote_identity = mag_identity_1
Then authenticate (shared secret/certificate/EAP) Then authenticate (shared secret/certificate/EAP)
skipping to change at page 18, line 33 skipping to change at page 18, line 33
For supporting this specification, the Binding Cache Entry data For supporting this specification, the Binding Cache Entry data
structure needs to be extended with the following additional fields. structure needs to be extended with the following additional fields.
o A flag indicating whether or not this Binding Cache entry is 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 created due to a proxy registration. This flag is set to value 1
for Binding Cache entries that are proxy registrations and is set for Binding Cache entries that are proxy registrations and is set
to value 0 for all other entries. to value 0 for all other entries.
o The identifier of the registered mobile node, MN-Identifier. This o The identifier of the registered mobile node, MN-Identifier. This
identifier is obtained from the Mobile Node Identifier Option identifier is obtained from the Mobile Node Identifier Option
[RFC-4283] present in the received Proxy Binding Update request. [RFC-4283] present in the received Proxy Binding Update message.
o The link-layer identifier of the mobile node's connected interface o The link-layer identifier of the mobile node's connected interface
on the access link. This identifier can be acquired from the on the access link. This identifier can be acquired from the
Mobile Node Link-layer Identifier option, present in the received Mobile Node Link-layer Identifier option, present in the received
Proxy Binding Update request. If the option was not present in Proxy Binding Update message. If the option was not present in
the request, this variable length field MUST be set to two the request, this variable length field MUST be set to two
(octets) and MUST be initialized to a value of ALL_ZERO. (octets) and MUST be initialized to a value of ALL_ZERO.
o The link-local address of the mobile access gateway on the point- 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 to-point link shared with the mobile node. This is generated by
the local mobility anchor after accepting the initial Proxy the local mobility anchor after accepting the initial Proxy
Binding Update request. Binding Update message.
o List of IPv6 home network prefixes assigned to the mobile node's o List of IPv6 home network prefixes assigned to the mobile node's
connected interface. The home network prefix(es) may have been connected interface. The home network prefix(es) may have been
statically configured in the mobile node's policy profile, or, statically configured in the mobile node's policy profile, or,
they may have been dynamically allocated by the local mobility they may have been dynamically allocated by the local mobility
anchor. Each one of these prefix entries will also includes the anchor. Each one of these prefix entries will also includes the
corresponding prefix length. corresponding prefix length.
o The tunnel interface identifier (tunnel-if-id) of the bi- o The tunnel interface identifier (tunnel-if-id) of the bi-
directional tunnel between the local mobility anchor and the directional tunnel between the local mobility anchor and the
mobile access gateway where the mobile node is currently anchored. mobile access gateway where the mobile node is currently anchored.
This is internal to the local mobility anchor. The tunnel This is internal to the local mobility anchor. The tunnel
interface identifier is acquired during the tunnel creation. interface identifier is acquired during the tunnel creation.
o The access technology type, using which the mobile node is o The access technology type, by which the mobile node is currently
currently attached. This is obtained from the Access Technology attached. This is obtained from the Access Technology Type
Type option, present in the Proxy Binding Update request. option, present in the Proxy Binding Update message.
o The 64-bit timestamp value of the most recently accepted Proxy o The 64-bit timestamp value of the most recently accepted Proxy
Binding Update request sent for this mobile node. This is the Binding Update message sent for this mobile node. This is the
time-of-day on the local mobility anchor, when the message was time-of-day on the local mobility anchor, when the message was
received. If the Timestamp option is not present in the Proxy received. If the Timestamp option is not present in the Proxy
Binding Update request (i.e., when the sequence number based Binding Update message (i.e., when the sequence number based
scheme is in use), the value MUST be set to ALL_ZERO. scheme is in use), the value MUST be set to ALL_ZERO.
Typically, any one of the mobile node's home network prefixes from 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 its mobility session may be used as a key for locating its Binding
Cache entry in all cases except when there has been an handoff of the Cache entry in all cases except when there has been an handoff of the
mobile node's session to a new mobile access gateway and that mobile 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 access gateway is unaware of the home network prefix(es) assigned to
that mobility session. In such handoff cases, the Binding Cache that mobility session. In such handoff cases, the Binding Cache
entry can be located under the considerations specified in Section entry can be located under the considerations specified in Section
5.4.1. 5.4.1.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
mobility anchor. mobility anchor.
5.3. Signaling Considerations 5.3. Signaling Considerations
This section provides the rules for processing the signaling This section provides the rules for processing the signaling
messages. The processing rules specified in this section and other messages. The processing rules specified in this section and other
related sections are chained and are in a specific order. When related sections are chained and are in a specific order. When
applying these considerations for processing the signaling messages, applying these considerations for processing the signaling messages,
the specified order MUST be maintained. the specified order MUST be maintained.
5.3.1. Processing Binding Registrations 5.3.1. Processing Proxy Binding Updates
1. The received Proxy Binding Update message (a Binding Update 1. The received Proxy Binding Update message (a Binding Update
message with the 'P' flag set to value of 1, format specified in message with the 'P' flag set to value of 1, format specified in
Section 8.1) MUST be authenticated as described in Section 4. Section 8.1) MUST be authenticated as described in Section 4.
When IPsec is used for message authentication, the SPI in the When IPsec is used for message authentication, the SPI in the
IPsec header [RFC-4306] of the received packet is needed for IPsec header [RFC-4306] of the received packet is needed for
locating the security association, for authenticating the Proxy locating the security association, for authenticating the Proxy
Binding Update message. Binding Update message.
2. The local mobility anchor MUST observe the rules described in 2. The local mobility anchor MUST observe the rules described in
Section 9.2 of [RFC-3775] when processing the Mobility Header in Section 9.2 of [RFC-3775] when processing the Mobility Header in
the received Proxy Binding Update request. the received Proxy Binding Update message.
3. The local mobility anchor MUST ignore the check, specified in 3. The local mobility anchor MUST ignore the check, specified in
Section 10.3.1 of [RFC-3775], related to the presence of Home Section 10.3.1 of [RFC-3775], related to the presence of Home
Address destination option in the Proxy Binding Update request. Address destination option in the Proxy Binding Update message.
4. The local mobility anchor MUST identify the mobile node from the 4. The local mobility anchor MUST identify the mobile node from the
identifier present in the Mobile Node Identifier option [RFC- identifier present in the Mobile Node Identifier option [RFC-
4283] of the Proxy Binding Update request. If the Mobile Node 4283] of the Proxy Binding Update message. If the Mobile Node
Identifier option is not present in the Proxy Binding Update Identifier option is not present in the Proxy Binding Update
request, the local mobility anchor MUST reject the request and message, the local mobility anchor MUST reject the request and
send a Proxy Binding Acknowledgement message with Status field send a Proxy Binding Acknowledgement message with Status field
set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node
identifier option) and the identifier in the Mobile Node identifier option) and the identifier in the Mobile Node
Identifier Option carried in the message MUST be set to a zero Identifier Option carried in the message MUST be set to a zero
length identifier. length identifier.
5. The local mobility anchor MUST apply the required policy checks, 5. The local mobility anchor MUST apply the required policy checks,
as explained in Section 4, to verify the sender is a trusted as explained in Section 4, to verify the sender is a trusted
mobile access gateway, authorized to send Proxy Binding Update mobile access gateway, authorized to send Proxy Binding Update
requests on behalf of this mobile node. messages on behalf of this mobile node.
6. If the local mobility anchor determines that the requesting node 6. If the local mobility anchor determines that the requesting node
is not authorized to send Proxy Binding Update requests for the is not authorized to send Proxy Binding Update messages for the
identified mobile node, it MUST reject the request and send a identified mobile node, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to Proxy Binding Acknowledgement message with Status field set to
MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy
binding registrations). binding updates).
7. If the local mobility anchor cannot identify the mobile node 7. If the local mobility anchor cannot identify the mobile node
based on the identifier present in the Mobile Node Identifier based on the identifier present in the Mobile Node Identifier
option [RFC-4283] of Proxy Binding Update request, it MUST option [RFC-4283] of Proxy Binding Update message, it MUST
reject the request and send a Proxy Binding Acknowledgement reject the request and send a Proxy Binding Acknowledgement
message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE
(Not local mobility anchor for this mobile node). (Not local mobility anchor for this mobile node).
8. If the local mobility anchor determines that the mobile node is 8. If the local mobility anchor determines that the mobile node is
not authorized for the network-based mobility management not authorized for the network-based mobility management
service, it MUST reject the request and send a Proxy Binding service, it MUST reject the request and send a Proxy Binding
Acknowledgement message with Status field set to Acknowledgement message with Status field set to
PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).
9. The local mobility anchor MUST apply the considerations 9. The local mobility anchor MUST apply the considerations
specified in Section 5.5, for processing the Sequence Number specified in Section 5.5, for processing the Sequence Number
field and the Timestamp option (if present), in the Proxy field and the Timestamp option (if present), in the Proxy
Binding Update request. Binding Update message.
10. If there is no Home Network Prefix option(s) (with any value) 10. If there is no Home Network Prefix option(s) (with any value)
present in the Proxy Binding Update request, the local mobility present in the Proxy Binding Update message, the local mobility
anchor MUST reject the request and send a Proxy Binding anchor MUST reject the request and send a Proxy Binding
Acknowledgement message with Status field set to Acknowledgement message with Status field set to
MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network prefix MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network prefix
option). option).
11. If the Handoff Indicator option is not present in the Proxy 11. If the Handoff Indicator option is not present in the Proxy
Binding Update request, the local mobility anchor MUST reject Binding Update message, the local mobility anchor MUST reject
the request and send a Proxy Binding Acknowledgement message the request and send a Proxy Binding Acknowledgement message
with Status field set to MISSING_HANDOFF_INDICATOR_OPTION with Status field set to MISSING_HANDOFF_INDICATOR_OPTION
(Missing handoff indicator option). (Missing handoff indicator option).
12. If the Access Technology Type option is not present in the Proxy 12. If the Access Technology Type option is not present in the Proxy
Binding Update request, the local mobility anchor MUST reject Binding Update message, the local mobility anchor MUST reject
the request and send a Proxy Binding Acknowledgement message the request and send a Proxy Binding Acknowledgement message
with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION
(Missing access technology type option). (Missing access technology type option).
13. Considerations specified in Section 5.4.1 MUST be applied for 13. Considerations specified in Section 5.4.1 MUST be applied for
performing the Binding Cache entry existence test. If those performing the Binding Cache entry existence test. If those
checks specified in Section 5.4.1, result in associating the checks specified in Section 5.4.1, result in associating the
received Proxy Binding Update request to a new mobility session received Proxy Binding Update message to a new mobility session
creation request, considerations from Section 5.3.2 (Initial creation request, considerations from Section 5.3.2 (Initial
Binding Registration - New Mobility Session), MUST be applied. Binding Registration - New Mobility Session), MUST be applied.
If those checks result in associating the request to an existing If those checks result in associating the request to an existing
mobility session, the following checks determine the next set of mobility session, the following checks determine the next set of
processing rules that needs to be applied. processing rules that needs to be applied.
* If the Handoff Indicator field in the Handoff Indicator * If the Handoff Indicator field in the Handoff Indicator
option present in the request is set to a value of 5 (Handoff option present in the request is set to a value of 5 (Handoff
state not changed), considerations from Section 5.3.3 state not changed), considerations from Section 5.3.3
(Binding Lifetime Extension- No handoff) MUST be applied. (Binding Lifetime Extension- No handoff) MUST be applied.
* If the received Proxy Binding Update request has the lifetime * If the received Proxy Binding Update message has the lifetime
value of zero, considerations from Section 5.3.5 (Binding De- value of zero, considerations from Section 5.3.5 (Binding De-
Registration) MUST be applied. Registration) MUST be applied.
* For all other cases, considerations from Section 5.3.4 * For all other cases, considerations from Section 5.3.4
(Binding Lifetime Extension - After handoff) MUST be applied. (Binding Lifetime Extension - After handoff) MUST be applied.
14. When sending the Proxy Binding Acknowledgement message with any 14. When sending the Proxy Binding Acknowledgement message with any
Status field value, the message MUST be constructed as specified Status field value, the message MUST be constructed as specified
in Section 5.3.6. in Section 5.3.6.
5.3.2. Initial Binding Registration (New Mobility Session) 5.3.2. Initial Binding Registration (New Mobility Session)
1. If there is at least one instance of Home Network Prefix option 1. If there is at least one instance of Home Network Prefix option
present in the Proxy Binding Update request with the prefix value present in the Proxy Binding Update message with the prefix value
set to ALL_ZERO, the local mobility anchor MUST allocate one or set to ALL_ZERO, the local mobility anchor MUST allocate one or
more home network prefix(es) to the mobile node and assign it to more home network prefix(es) to the mobile node and assign it to
the new mobility session created for the mobile node. The local the new mobility session created for the mobile node. The local
mobility anchor MUST ensure the allocated prefix(es) is not in mobility anchor MUST ensure the allocated prefix(es) is not in
use by any other node or mobility session. The decision on how use by any other node or mobility session. The decision on how
many prefixes to be allocated for the attached interface, can be many prefixes to be allocated for the attached interface, can be
based on a global policy or a policy specific to that mobile based on a global policy or a policy specific to that mobile
node. However, when stateful address autoconfiguration using node. However, when stateful address autoconfiguration using
DHCP is supported on the link, considerations from Section 6.11 DHCP is supported on the link, considerations from Section 6.11
MUST be applied for the prefix assignment. MUST be applied for the prefix assignment.
2. If the local mobility anchor is unable to allocate any home 2. If the local mobility anchor is unable to allocate any home
network prefix for the mobile node, it MUST reject the request network prefix for the mobile node, it MUST reject the request
and send a Proxy Binding Acknowledgement message with Status and send a Proxy Binding Acknowledgement message with Status
field set to 130 (Insufficient resources). field set to 130 (Insufficient resources).
3. If there are one or more Home Network Prefix options present in 3. If there are one or more Home Network Prefix options present in
the Proxy Binding Update request (with each of the prefixes set the Proxy Binding Update message (with each of the prefixes set
to a NON_ZERO value), the local mobility anchor before accepting to a NON_ZERO value), the local mobility anchor before accepting
that request, MUST ensure each one of those prefixes is owned by that request, MUST ensure each one of those prefixes is owned by
the local mobility anchor and further the mobile node is the local mobility anchor and further the mobile node is
authorized to use these prefixes. If the mobile node is not authorized to use these prefixes. If the mobile node is not
authorized to use any one or more of those prefixes, the local authorized to use any one or more of those prefixes, the local
mobility anchor MUST reject the request and send a Proxy Binding mobility anchor MUST reject the request and send a Proxy Binding
Acknowledgement message with Status field set to Acknowledgement message with Status field set to
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not
authorized for one or more of the requesting home network authorized for one or more of the requesting home network
prefixes). prefixes).
skipping to change at page 23, line 48 skipping to change at page 23, line 48
state MUST result in the forwarding behavior on the local state MUST result in the forwarding behavior on the local
mobility anchor as specified in Section 5.6.2. mobility anchor as specified in Section 5.6.2.
7. The local mobility anchor MUST send the Proxy Binding 7. The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field set to 0 (Proxy Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6. specified in Section 5.3.6.
5.3.3. Binding Lifetime Extension (No handoff) 5.3.3. Binding Lifetime Extension (No handoff)
1. Upon accepting the Proxy Binding Update request for extending the 1. Upon accepting the Proxy Binding Update message for extending the
binding lifetime, received from the same mobile access gateway binding lifetime, received from the same mobile access gateway
(if the Proxy-CoA address in the Binding Cache entry is the same (if the Proxy-CoA address in the Binding Cache entry is the same
as the Proxy-CoA address in the request) that last updated the as the Proxy-CoA address in the request) that last updated the
binding, the local mobility anchor MUST update the Binding Cache binding, the local mobility anchor MUST update the Binding Cache
entry with the accepted registration values. entry with the accepted registration values.
2. The local mobility anchor MUST send the Proxy Binding 2. The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field set to 0 (Proxy Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6. specified in Section 5.3.6.
5.3.4. Binding Lifetime Extension (After handoff) 5.3.4. Binding Lifetime Extension (After handoff)
1. Upon accepting the Proxy Binding Update request for extending the 1. Upon accepting the Proxy Binding Update message for extending the
binding lifetime, received from a new mobile access gateway (if binding lifetime, received from a new mobile access gateway (if
the Proxy-CoA address in the Binding Cache entry does not match the Proxy-CoA address in the Binding Cache entry does not match
the Proxy-CoA address in the request) where the mobile node's the Proxy-CoA address in the request) where the mobile node's
session is handed off, the local mobility anchor MUST update the mobility session is handed off, the local mobility anchor MUST
Binding Cache entry with the accepted registration values. update the Binding Cache entry with the accepted registration
values.
2. The local mobility anchor MUST remove the previously created 2. The local mobility anchor MUST remove the previously created
route(s) for the mobile node's home network prefix(es) associated route(s) for the mobile node's home network prefix(es) associated
with this mobility session. Additionally, if there are no other with this mobility session. Additionally, if there are no other
mobile node sessions sharing the dynamically created bi- mobile node sharing the dynamically created bi-directional tunnel
directional tunnel to the previous mobile access gateway, the to the previous mobile access gateway, the tunnel SHOULD be
tunnel SHOULD be deleted applying considerations from section deleted applying considerations from section 5.6.1 (if the tunnel
5.6.1 (if the tunnel is a dynamically created tunnel and not a is a dynamically created tunnel and not a fixed pre-established
fixed pre-established tunnel). tunnel).
3. If there is no existing bi-directional tunnel to the mobile 3. If there is no existing bi-directional tunnel to the mobile
access gateway that sent the request, the local mobility anchor access gateway that sent the request, the local mobility anchor
MUST establish a bi-directional tunnel to that mobile access MUST establish a bi-directional tunnel to that mobile access
gateway. Considerations from Section 5.6.1 MUST be applied for gateway. Considerations from Section 5.6.1 MUST be applied for
managing the dynamically created bi-directional tunnel. managing the dynamically created bi-directional tunnel.
4. The local mobility anchor MUST create prefix route(s) over the 4. The local mobility anchor MUST create prefix route(s) over the
tunnel to the mobile access gateway for forwarding any traffic tunnel to the mobile access gateway for forwarding any traffic
received for the mobile node's home network prefix(es) associated received for the mobile node's home network prefix(es) associated
skipping to change at page 25, line 7 skipping to change at page 25, line 7
MUST result in the forwarding behavior on the local mobility MUST result in the forwarding behavior on the local mobility
anchor as specified in Section 5.6.2. anchor as specified in Section 5.6.2.
5. The local mobility anchor MUST send the Proxy Binding 5. The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field set to 0 (Proxy Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6. specified in Section 5.3.6.
5.3.5. Binding De-Registration 5.3.5. Binding De-Registration
1. If the received Proxy Binding Update request with the lifetime 1. If the received Proxy Binding Update message with the lifetime
value of zero, has a Source Address in the IPv6 header (or the 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 address in the Alternate Care-of Address option, if the option is
present) different from what is present in the Proxy-CoA address present) different from what is present in the Proxy-CoA address
field in the Binding Cache entry, the local mobility anchor MUST field in the Binding Cache entry, the local mobility anchor MUST
ignore the request. ignore the request.
2. Upon accepting the Proxy Binding Update request with the lifetime 2. Upon accepting the Proxy Binding Update message with the lifetime
value of zero, the local mobility anchor MUST wait for value of zero, the local mobility anchor MUST wait for
MinDelayBeforeBCEDelete amount of time, before it deletes the MinDelayBeforeBCEDelete amount of time, before it deletes the
Binding Cache entry. However, it MUST send the Proxy Binding Binding Cache entry. However, it MUST send the Proxy Binding
Acknowledgement message with the Status field set to 0 (Proxy Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6. specified in Section 5.3.6.
* During this wait period, the local mobility anchor SHOULD drop * During this wait period, the local mobility anchor SHOULD drop
the mobile node's data traffic. the mobile node's data traffic.
* During this wait period, if the local mobility anchor receives * During this wait period, if the local mobility anchor receives
a valid Proxy Binding Update request for the same mobility a valid Proxy Binding Update message for the same mobility
session with the lifetime value of greater than zero, and if session with the lifetime value of greater than zero, and if
that request is accepted, then the Binding Cache entry MUST that request is accepted, then the Binding Cache entry MUST
NOT be deleted, but must be updated with the newly accepted NOT be deleted, but must be updated with the newly accepted
registration values and additionally the wait period should be registration values and additionally the wait period should be
ended. ended.
* By the end of this wait period, if the local mobility anchor * By the end of this wait period, if the local mobility anchor
did not receive any valid Proxy Binding Update request for did not receive any valid Proxy Binding Update message for
this mobility session, then it MUST delete the Binding Cache this mobility session, then it MUST delete the Binding Cache
entry and remove the routing state created for that mobility entry and remove the routing state created for that mobility
session. The local mobility anchor can potentially reassign session. The local mobility anchor can potentially reassign
the prefix(es) associated with this mobility session to other the prefix(es) associated with this mobility session to other
mobile nodes. mobile nodes.
5.3.6. Constructing the Proxy Binding Acknowledgement Message 5.3.6. Constructing the Proxy Binding Acknowledgement Message
o The local mobility anchor when sending the Proxy Binding o The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST Acknowledgement message to the mobile access gateway MUST
skipping to change at page 26, line 21 skipping to change at page 26, line 21
- Handoff Indicator option (mandatory) - Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory) - Access Technology Type option (mandatory)
- Timestamp Option (optional) - Timestamp Option (optional)
- Mobile Node Link-layer Identifier option (optional) - Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional) - Link-local Address option (optional)
Figure 6: Proxy Binding Acknowledgement message format Figure 6: Proxy Binding Acknowledgement message format
o The Source Address field in the IPv6 header of the message MUST be o The Source Address field in the IPv6 header of the message MUST be
set to the destination address of the received Proxy Binding set to the destination address of the received Proxy Binding
Update request. Update message.
o The Destination Address field in the IPv6 header of the 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 MUST be set to the source address of the received Proxy Binding
Update request. When there is no Alternate Care-of Address option Update message. When there is no Alternate Care-of Address option
present in the request, the destination address is the same as the present in the request, the destination address is the same as the
Proxy-CoA address, otherwise, the address may not be the same as Proxy-CoA address, otherwise, the address may not be the same as
the Proxy-CoA. the Proxy-CoA.
o The Mobile Node Identifier option [RFC-4283] MUST be present. The o The Mobile Node Identifier option [RFC-4283] MUST be present. The
identifier field in the option MUST be copied from the Mobile Node identifier field in the option MUST be copied from the Mobile Node
Identifier option in the received Proxy Binding Update request. Identifier option in the received Proxy Binding Update message.
If the option was not present in the request, the identifier in If the option was not present in the request, the identifier in
the option MUST be set to a zero length identifier. the option MUST be set to a zero length identifier.
o At least one Home Network Prefix option MUST be present. 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 * If the Status field is set to a value greater than or equal to
128, i.e., if the binding request is rejected, all the Home 128, i.e., if the Proxy Binding Update is rejected, all the
Network Prefix options that were present in the request (along Home Network Prefix options that were present in the request
with their prefix values) MUST be present in the reply. But, (along with their prefix values) MUST be present in the reply.
if there was no Home Network Prefix option present in the But, if there was no Home Network Prefix option present in the
request, then there MUST be only one Home Network Prefix option request, then there MUST be only one Home Network Prefix option
and with the value in the option set to ALL_ZERO. and with the value in the option set to ALL_ZERO.
* For all other cases, there MUST be a Home Network Prefix option * For all other cases, there MUST be a Home Network Prefix option
for each of the assigned home network prefixes (for that for each of the assigned home network prefixes (for that
mobility session) and with the prefix value in the option set mobility session) and with the prefix value in the option set
to the allocated prefix value. to the allocated prefix value.
o The Handoff Indicator option MUST be present. The handoff o The Handoff Indicator option MUST be present. The handoff
indicator field in the option MUST be copied from the Handoff indicator field in the option MUST be copied from the Handoff
Indicator option in the received Proxy Binding Update request. If Indicator option in the received Proxy Binding Update message. If
the option was not present in the request, the value in the option the option was not present in the request, the value in the option
MUST be set to zero. MUST be set to zero.
o The Access Technology Type option MUST be present. The access 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 field in the option MUST be copied from the Access
Technology Type option in the received Proxy Binding Update Technology Type option in the received Proxy Binding Update
request. If the option was not present in the request, the value message. If the option was not present in the request, the value
in the option MUST be set to zero. in the option MUST be set to zero.
o The Timestamp option MUST be present only if the same option was o The Timestamp option MUST be present only if the same option was
present in the received Proxy Binding Update request and MUST NOT present in the received Proxy Binding Update message and MUST NOT
be present otherwise. Considerations from Section 5.5 must be be present otherwise. Considerations from Section 5.5 must be
applied for constructing the Timestamp option. applied for constructing the Timestamp option.
o The Mobile Node Link-layer Identifier option MUST be present only o The Mobile Node Link-layer Identifier option MUST be present only
if the same option was present in the received Proxy Binding if the same option was present in the received Proxy Binding
Update request and MUST NOT be present otherwise. The link-layer Update message and MUST NOT be present otherwise. The link-layer
identifier value MUST be copied from the Mobile Node Link-layer identifier value MUST be copied from the Mobile Node Link-layer
Identifier option present in the received Proxy Binding Update Identifier option present in the received Proxy Binding Update
request. message.
o The Link-local Address option MUST be present only if the same o The Link-local Address option MUST be present only if the same
option was present in the received Proxy Binding Update request option was present in the received Proxy Binding Update message
and MUST NOT be present otherwise. If the Status field in the 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 reply is set to a value greater than or equal to 128, i.e., if the
binding request is rejected, then the link-local address from the Proxy Binding Update is rejected, then the link-local address from
request MUST be copied to the Link-local Address option in the the request MUST be copied to the Link-local Address option in the
reply, otherwise the following considerations apply. reply, otherwise the following considerations apply.
* If the received Proxy Binding Update request has the Link-local * If the received Proxy Binding Update message has the Link-local
Address option with ALL_ZERO value and if there is an existing Address option with ALL_ZERO value and if there is an existing
Binding Cache entry associated with this request, then the Binding Cache entry associated with this request, then the
link-local address from the Binding Cache entry MUST be copied link-local address from the Binding Cache entry MUST be copied
to the Link-local Address option in the reply. to the Link-local Address option in the reply.
* If the received Proxy Binding Update request has the Link-local * If the received Proxy Binding Update message has the Link-local
Address option with ALL_ZERO value and if there is no existing Address option with ALL_ZERO value and if there is no existing
Binding Cache entry associated with this request, then the Binding Cache entry associated with this request, then the
local mobility anchor MUST generate the link-local address that local mobility anchor MUST generate the link-local address that
the mobile access gateway can use on the point-to-point link the mobile access gateway can use on the point-to-point link
shared with the mobile node. This generated address MUST be shared with the mobile node. This generated address MUST be
copied to the Link-local Address option in the reply. The same copied to the Link-local Address option in the reply. The same
address MUST also be copied to the link-local address field of address MUST also be copied to the link-local address field of
Binding Cache entry created for this mobility session. Binding Cache entry created for this mobility session.
* If the received Proxy Binding Update request has the Link-local * If the received Proxy Binding Update message has the Link-local
Address option with NON_ZERO value, then the link-local address Address option with NON_ZERO value, then the link-local address
from the request MUST be copied to 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 option in the reply. The same address MUST also be copied to
the link-local address field of the Binding Cache entry the link-local address field of the Binding Cache entry
associated with this request (after creating the Binding Cache associated with this request (after creating the Binding Cache
entry, if there does not exist one). entry, if there does not exist one).
o If IPsec is used for protecting the signaling messages, the o If IPsec is used for protecting the signaling messages, the
message MUST be protected, using the security association existing message MUST be protected, using the security association existing
between the local mobility anchor and the mobile access gateway. between the local mobility anchor and the mobile access gateway.
skipping to change at page 28, line 51 skipping to change at page 28, line 51
interface of the mobile node). The decision on when to create a interface of the mobile node). The decision on when to create a
new mobility session and when to update an existing mobility new mobility session and when to update an existing mobility
session MUST be based on the Handover hint present in the Proxy session MUST be based on the Handover hint present in the Proxy
Binding Update message and under the considerations specified in Binding Update message and under the considerations specified in
this section 5.4. this section 5.4.
5.4.1. Binding Cache entry lookup considerations 5.4.1. Binding Cache entry lookup considerations
There can be multiple Binding Cache entries for a given mobile node. 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 When doing a lookup for a mobile node's Binding Cache entry for
processing a received Proxy Binding Update request message, the local processing a received Proxy Binding Update message, the local
mobility anchor MUST apply the following multihoming considerations mobility anchor MUST apply the following multihoming considerations
(in the below specified order, starting with Section 5.4.1.1). These (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. 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 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
skipping to change at page 29, line 38 skipping to change at page 29, line 38
request with a NON_ZERO prefix value and irrespective of the presence request with a NON_ZERO prefix value and irrespective of the presence
of the Mobile Node Link-layer Identifier option in the request, the of the Mobile Node Link-layer Identifier option in the request, the
following considerations MUST be applied. If there are more than one following considerations MUST be applied. If there are more than one
instances of the Home Network Prefix option, any one of the Home instances of the Home Network Prefix option, any one of the Home
Network Prefix options present in the request (with NON_ZERO prefix Network Prefix options present in the request (with NON_ZERO prefix
value) can be used for locating the Binding Cache entry. value) can be used for locating the Binding Cache entry.
1. The local mobility anchor MUST verify if there is an existing 1. The local mobility anchor MUST verify if there is an existing
Binding Cache entry with one of its home network prefixes Binding Cache entry with one of its home network prefixes
matching the prefix value in one of the Home Network Prefix matching the prefix value in one of the Home Network Prefix
options of the received Proxy Binding Update request. options of the received Proxy Binding Update message.
2. If there does not exist a Binding Cache entry (with one of its 2. If there does not exist a Binding Cache entry (with one of its
home network prefixes in the Binding Cache entry matching the home network prefixes in the Binding Cache entry matching the
prefix value in one of the Home Network Prefix options of the prefix value in one of the Home Network Prefix options of the
received Proxy Binding Update request), the request MUST be received Proxy Binding Update message), the request MUST be
considered as a request for creating a new mobility session. considered as a request for creating a new mobility session.
3. If there exists a Binding Cache entry (with one of its home 3. If there exists a Binding Cache entry (with one of its home
network prefixes in the Binding Cache entry matching the prefix network prefixes in the Binding Cache entry matching the prefix
value in one of the Home Network Prefix options of the received value in one of the Home Network Prefix options of the received
Proxy Binding Update request) but if the mobile node identifier Proxy Binding Update message) but if the mobile node identifier
in the entry does not match the mobile node identifier in the in the entry does not match the mobile node identifier in the
Mobile Node Identifier option of the received Proxy Binding Mobile Node Identifier option of the received Proxy Binding
Update request, the local mobility anchor MUST reject the request Update message, the local mobility anchor MUST reject the request
with the Status field value set to with the Status field value set to
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not
authorized for one or more of the requesting home network authorized for one or more of the requesting home network
prefixes). prefixes).
4. If there exists a Binding Cache entry (matching MN-Identifier and 4. If there exists a Binding Cache entry (matching MN-Identifier and
one of its home network prefixes in the Binding Cache entry one of its home network prefixes in the Binding Cache entry
matching the prefix value in one of the Home Network Prefix matching the prefix value in one of the Home Network Prefix
options of the received Proxy Binding Update request), but if all options of the received Proxy Binding Update message), but if all
the prefixes in the request do not match all the prefixes in the 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 Binding Cache entry, or if they do not match in count, then the
local mobility anchor MUST reject the request with the Status local mobility anchor MUST reject the request with the Status
field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home 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 network prefixes listed in the BCE do not match all the prefixes
in the received PBU). in the received PBU).
5. If there exists a Binding Cache entry (matching MN-Identifier and 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 Binding Cache entry matching
all the home network prefixes in the received Proxy Binding all the home network prefixes in the received Proxy Binding
Update request) and if any one or more of these below stated Update message) and if any one or more of these below stated
conditions match, the request MUST be considered as a request for conditions match, the request MUST be considered as a request for
updating that Binding Cache entry. updating that Binding Cache entry.
* If the Handoff Indicator field in the Handoff Indicator option * If the Handoff Indicator field in the Handoff Indicator option
present in the request is set to a value of 2 (Handoff between present in the request is set to a value of 2 (Handoff between
two different interfaces of the mobile node). two different interfaces of the mobile node).
* If there is no Mobile Node Link-layer Identifier option * If there is no Mobile Node Link-layer Identifier option
present in the request, the link-layer identifier value in the present in the request, the link-layer identifier value in the
Binding Cache entry is set to ALL_ZERO, the access technology Binding Cache entry is set to ALL_ZERO, the access technology
skipping to change at page 31, line 7 skipping to change at page 31, line 7
* If the Proxy-CoA address in the Binding Cache entry matches * If the Proxy-CoA address in the Binding Cache entry matches
the source address of the request (or the address in the the source address of the request (or the address in the
alternate Care-of Address option, if the option is present) alternate Care-of Address option, if the option is present)
and if the access technology type field in the Access and if the access technology type field in the Access
Technology Type option present in the request matches the Technology Type option present in the request matches the
access technology type in the Binding Cache entry. access technology type in the Binding Cache entry.
6. For all other cases, the message MUST be considered as a request 6. For all other cases, the message MUST be considered as a request
for creating a new mobility session. However, if the received for creating a new mobility session. However, if the received
Proxy Binding Update request has the lifetime value of zero and Proxy Binding Update message has the lifetime value of zero and
if the request cannot be associated with any existing mobility if the request cannot be associated with any existing mobility
session, the message MUST be silently ignored. session, the message MUST be silently ignored.
5.4.1.2. Mobile Node Link-layer Identifier Option present in the 5.4.1.2. Mobile Node Link-layer Identifier Option present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| No HNP option with a NON_ZERO Value | | No HNP option with a NON_ZERO Value |
skipping to change at page 32, line 38 skipping to change at page 32, line 38
value. If there exists only one such entry (matching the MN- value. If there exists only one such entry (matching the MN-
Identifier), the local mobility anchor SHOULD wait till the Identifier), the local mobility anchor SHOULD wait till the
existing Binding Cache entry is de-registered by the existing Binding Cache entry is de-registered by the
previously serving mobile access gateway, before the request previously serving mobile access gateway, before the request
can be considered as a request for updating that Binding Cache can be considered as a request for updating that Binding Cache
entry. However, if there is no de-registration message that entry. However, if there is no de-registration message that
is received within MaxDelayBeforeNewBCEAssign amount of time, is received within MaxDelayBeforeNewBCEAssign amount of time,
the local mobility anchor upon accepting the request MUST the local mobility anchor upon accepting the request MUST
consider the request as a request for creating a new mobility consider the request as a request for creating a new mobility
session. The local mobility anchor MAY also choose to create session. The local mobility anchor MAY also choose to create
a new mobility session and without waiting for a de- a new mobility session without waiting for a de-registration
registration message and this should be configurable on the message and this should be configurable on the local mobility
local mobility anchor. anchor.
5. For all other cases, the message MUST be considered as a request 5. For all other cases, the message MUST be considered as a request
for creating a new mobility session. However, if the received for creating a new mobility session. However, if the received
Proxy Binding Update request has the lifetime value of zero and Proxy Binding Update message has the lifetime value of zero and
if the request cannot be associated with any existing mobility if the request cannot be associated with any existing mobility
session, the message MUST be silently ignored. session, the message MUST be silently ignored.
5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| No HNP option with a NON_ZERO Value | | No HNP option with a NON_ZERO Value |
skipping to change at page 34, line 15 skipping to change at page 34, line 15
is no de-registration message that is received within is no de-registration message that is received within
MaxDelayBeforeNewBCEAssign amount of time, the local mobility MaxDelayBeforeNewBCEAssign amount of time, the local mobility
anchor upon accepting the request MUST consider the request as a anchor upon accepting the request MUST consider the request as a
request for creating a new mobility session. The local mobility request for creating a new mobility session. The local mobility
anchor MAY also choose to create a new mobility session and anchor MAY also choose to create a new mobility session and
without waiting for a de-registration message and this should be without waiting for a de-registration message and this should be
configurable on the local mobility anchor. configurable on the local mobility anchor.
4. For all other cases, the message MUST be considered as a request 4. For all other cases, the message MUST be considered as a request
for creating a new mobility session. However, if the received for creating a new mobility session. However, if the received
Proxy Binding Update request has the lifetime value of zero and Proxy Binding Update message has the lifetime value of zero and
if the request cannot be associated with any existing mobility if the request cannot be associated with any existing mobility
session, the message MUST be silently ignored. session, the message MUST be silently ignored.
5.5. Timestamp Option for Message Ordering 5.5. Timestamp Option for Message Ordering
Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding
registration messages as a way for the home agent to process the 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 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 home agent and the mobile node are required to manage this counter
over the lifetime of a binding. However, in Proxy Mobile IPv6, as over the lifetime of a binding. However, in Proxy Mobile IPv6, as
the mobile node moves from one mobile access gateway to another and the mobile node moves from one mobile access gateway to another and
in the absence of mechanisms such as context transfer between the in the absence of mechanisms such as context transfer between the
mobile access gateways, the serving mobile access gateway will be mobile access gateways, the serving mobile access gateway will be
unable to determine the sequence number that it needs to use in the unable to determine the sequence number that it needs to use in the
signaling messages. Hence, the sequence number scheme, as specified signaling messages. Hence, the sequence number scheme, as specified
in [RFC-3775], will be insufficient for Proxy Mobile IPv6. in [RFC-3775], will be insufficient for Proxy Mobile IPv6.
If the local mobility anchor cannot determine the sending order of If the local mobility anchor cannot determine the sending order of
the received binding registration messages, it may potentially the received Proxy Binding Update messages, it may potentially
process an older message sent by a mobile access gateway where the process an older message sent by a mobile access gateway where the
mobile node was previously anchored, but delivered out of order, mobile node was previously anchored, but delivered out of order,
resulting in incorrectly updating the mobile node's Binding Cache resulting in incorrectly updating the mobile node's Binding Cache
entry and creating a routing state for tunneling the mobile node's entry and creating a routing state for tunneling the mobile node's
traffic to the previous mobile access gateway. traffic to the previous mobile access gateway.
For solving this problem, this specification adopts two alternative For solving this problem, this specification adopts two alternative
solutions. One is based on timestamps and the other based on solutions. One is based on timestamps and the other based on
sequence numbers, as defined in [RFC-3775]. sequence numbers, as defined in [RFC-3775].
The basic principle behind the use of timestamps in binding The basic principle behind the use of timestamps in binding
registration messages is that the node generating the message inserts registration messages is that the node generating the message inserts
the current time-of-day, and the node receiving the message checks the current time-of-day, and the node receiving the message checks
that this timestamp is greater than all previously accepted that this timestamp is greater than all previously accepted
timestamps. The timestamp based solution may be used when the timestamps. The timestamp based solution may be used when the
serving mobile access gateways in a Proxy Mobile IPv6 domain do not 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 have the ability to obtain the last sequence number that was sent in
a binding registration message for updating a given mobile node's a Proxy Binding Update message for updating a given mobile node's
binding. binding.
If the mechanism used for clock synchronization in the Proxy Mobile Clock drift reduces the effectiveness of the timestamp mechanism.
IPv6 domain cannot assure a clock drift between the two mobile access The time required for reconnection is the total of the time required
gateways (between which the mobile node did a handoff), which is not for the mobile node to roam between two mobile access gateways and
less than half the total time it took for the mobile node to roam the time required for the serving mobile access gateway to detect the
between the two mobile access gateways and the time it took for the mobile node on its access link and construct the Proxy Binding Update
serving mobile access gateway to detect the node on its access link message. If the clock skew on any one of these two neighboring
and construct the Proxy Binding Update message, then this solution mobile access gateways (relative to the common time source used for
will not predictably work in all cases and hence SHOULD NOT be used. 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 As an alternative to the Timestamp based approach, the specification
also allows the use of Sequence Number based scheme, as specified in also allows the use of Sequence Number based scheme, as specified in
[RFC-3775]. However, for this scheme to work, the serving mobile [RFC-3775]. However, for this scheme to work, the serving mobile
access gateway in a Proxy Mobile IPv6 domain MUST have the ability to access gateway in a Proxy Mobile IPv6 domain MUST have the ability to
obtain the last sequence number that was sent in a binding obtain the last sequence number that was sent in a binding
registration message. The sequence number MUST be maintained on a registration message. The sequence number MUST be maintained on a
per mobile node basis and MUST be available to the serving mobile per mobile node basis and MUST be available to the serving mobile
access gateway. This may be achieved by using context transfer access gateway. This may be achieved by using context transfer
schemes or by maintaining the sequence number in a policy store. schemes or by maintaining the sequence number in a policy store.
However, the specific details on how the mobile node's sequence However, the specific details on how the mobile node's sequence
number is made available to the serving mobile access gateway prior number is made available to the serving mobile access gateway prior
to sending the binding registration messages is outside the scope of to sending the Proxy Binding Update message is outside the scope of
this document." this document."
Using the Timestamps based approach: Using the Timestamps based approach:
1. A local mobility anchor implementation MUST support the Timestamp 1. A local mobility anchor implementation MUST support the Timestamp
option. If the Timestamp option is present in the received Proxy option. If the Timestamp option is present in the received Proxy
Binding Update request message, then the local mobility anchor Binding Update message, then the local mobility anchor MUST
MUST include a valid Timestamp option in the Proxy Binding include a valid Timestamp option in the Proxy Binding
Acknowledgement message that it sends to the mobile access Acknowledgement message that it sends to the mobile access
gateway. gateway.
2. All the mobility entities in a Proxy Mobile IPv6 domain that are 2. All the mobility entities in a Proxy Mobile IPv6 domain that are
exchanging binding registration messages using the Timestamp exchanging binding registration messages using the Timestamp
option MUST have adequately synchronized time-of-day clocks. option MUST have adequately synchronized time-of-day clocks.
This is the essential requirement for this solution to work. If This is the essential requirement for this solution to work. If
this requirement is not met, the solution will not predictably this requirement is not met, the solution will not predictably
work in all cases. work in all cases.
3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD
synchronize their clocks to a common time source. For synchronize their clocks to a common time source. For
synchronizing the clocks, the nodes MAY use the Network Time synchronizing the clocks, the nodes MAY use the Network Time
Protocol [RFC-4330]. Deployments MAY also adopt other approaches Protocol [RFC-4330]. Deployments MAY also adopt other approaches
suitable for that specific deployment. Alternatively, if there suitable for that specific deployment. Alternatively, if there
is mobile node generated timestamp that is increasing at every is mobile node generated timestamp that is increasing at every
attachment to the access link and if that timestamp is available attachment to the access link and if that timestamp is available
to the mobile access gateway (Ex: The timestamp option in the to the mobile access gateway (Ex: the timestamp option in the
SEND messages that the mobile node sends), the mobile access SEND [RFC-3971] messages that the mobile node sends), the mobile
gateway can use this timestamp or sequence number in the Proxy access gateway can use this timestamp or sequence number in the
Binding Update messages and does not have to depend on any Proxy Binding Update messages and does not have to depend on any
external clock source. However, the specific details on how this external clock source. However, the specific details on how this
is achieved is outside the scope of this document. is achieved are outside the scope of this document.
4. When generating the timestamp value for building the Timestamp 4. When generating the timestamp value for building the Timestamp
option, the mobility entities MUST ensure that the generated option, the mobility entities MUST ensure that the generated
timestamp is the elapsed time past the same reference epoch, as timestamp is the elapsed time past the same reference epoch, as
specified in the format for the Timestamp option (Section 8.8). specified in the format for the Timestamp option (Section 8.8).
5. If the Timestamp option is present in the received Proxy Binding 5. If the Timestamp option is present in the received Proxy Binding
Update message, the local mobility anchor MUST ignore the Update message, the local mobility anchor MUST ignore the
sequence number field in the message. However, it MUST copy the sequence number field in the message. However, it MUST copy the
sequence number from the received Proxy Binding Update message to sequence number from the received Proxy Binding Update message to
skipping to change at page 37, line 4 skipping to change at page 37, line 8
valid (validity as specified in the above considerations) or if valid (validity as specified in the above considerations) or if
the flag MobileNodeGeneratedTimestampInUse is set to value of 1, the flag MobileNodeGeneratedTimestampInUse is set to value of 1,
the local mobility anchor MUST return the same timestamp value in the local mobility anchor MUST return the same timestamp value in
the Timestamp option included in the Proxy Binding the Timestamp option included in the Proxy Binding
Acknowledgement message that it sends to the mobile access Acknowledgement message that it sends to the mobile access
gateway. gateway.
8. If the timestamp value in the received Proxy Binding Update is 8. If the timestamp value in the received Proxy Binding Update is
lower than the previously accepted timestamp in the Proxy Binding lower than the previously accepted timestamp in the Proxy Binding
Update messages sent for that mobility binding, the local Update messages sent for that mobility binding, the local
mobility anchor MUST reject the Proxy Binding Update request and mobility anchor MUST reject the Proxy Binding Update message and
send a Proxy Binding Acknowledgement message with Status field send a Proxy Binding Acknowledgement message with Status field
set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than
previously accepted timestamp). The message MUST also include previously accepted timestamp). The message MUST also include
the Timestamp option with the value set to the current time-of- the Timestamp option with the value set to the current time-of-
day on the local mobility anchor. day on the local mobility anchor.
9. If the timestamp value in the received Proxy Binding Update is 9. If the timestamp value in the received Proxy Binding Update is
not valid (validity as specified in the above considerations), not valid (validity as specified in the above considerations),
the local mobility anchor MUST reject the Proxy Binding Update the local mobility anchor MUST reject the Proxy Binding Update
and send a Proxy Binding Acknowledgement message with Status and send a Proxy Binding Acknowledgement message with Status
field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The
message MUST also include the Timestamp option with the value set message MUST also include the Timestamp option with the value set
to the current time-of-day on the local mobility anchor. to the current time-of-day on the local mobility anchor.
Using the Sequence Number based approach: Using the Sequence Number based approach:
1. If the Timestamp option is not present in the received Proxy 1. If the Timestamp option is not present in the received Proxy
Binding Update request, the local mobility anchor MUST fall back Binding Update message, the local mobility anchor MUST fall back
to the Sequence Number based scheme. It MUST process the to the Sequence Number based scheme. It MUST process the
sequence number field as specified in [RFC-3775]. Also, it MUST sequence number field as specified in [RFC-3775]. Also, it MUST
NOT include the Timestamp option in the Proxy Binding NOT include the Timestamp option in the Proxy Binding
Acknowledgement messages that it sends to the mobile access Acknowledgement messages that it sends to the mobile access
gateway. gateway.
2. An implementation MUST support the Sequence Number based scheme, 2. An implementation MUST support the Sequence Number based scheme,
as specified in [RFC-3775]. as specified in [RFC-3775].
3. The Sequence Number based approach can be used only when there is 3. The Sequence Number based approach can be used only when there is
some mechanism (such as context transfer procedure between mobile some mechanism (such as context transfer procedure between mobile
access gateways) that allows the serving mobile access gateway to access gateways) that allows the serving mobile access gateway to
obtain the last sequence number that was sent in a binding obtain the last sequence number that was sent in a Proxy Binding
registration message for updating a given mobile node's binding. Update message for updating a given mobile node's binding.
5.6. Routing Considerations 5.6. Routing Considerations
5.6.1. Bi-Directional Tunnel Management 5.6.1. Bi-Directional Tunnel Management
The bi-directional tunnel MUST be used for routing the mobile node's The bi-directional tunnel MUST be used for routing the mobile node's
data traffic between the mobile access gateway and the local mobility data traffic between the mobile access gateway and the local mobility
anchor. A tunnel hides the topology and enables a mobile node to use 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 address(es) from its home network prefix(es) from any access link in
that Proxy Mobile IPv6 domain. A tunnel may be created dynamically that Proxy Mobile IPv6 domain. A tunnel may be created dynamically
skipping to change at page 41, line 25 skipping to change at page 41, line 26
specified in Mobile IPv6 [RFC-3775]. However, this specification specified in Mobile IPv6 [RFC-3775]. However, this specification
does support some other form of route optimization as specified in does support some other form of route optimization as specified in
Section 6.10.3. Section 6.10.3.
6. Mobile Access Gateway Operation 6. Mobile Access Gateway Operation
The Proxy Mobile IPv6 protocol described in this document introduces The Proxy Mobile IPv6 protocol described in this document introduces
a new functional entity, the Mobile Access Gateway (MAG). The mobile a new functional entity, the Mobile Access Gateway (MAG). The mobile
access gateway is the entity that is responsible for detecting the access gateway is the entity that is responsible for detecting the
mobile node's movements to and from the access link and sending the mobile node's movements to and from the access link and sending the
binding registration requests to the local mobility anchor. In Proxy Binding Update messages to the local mobility anchor. In
essence, the mobile access gateway performs mobility management on essence, the mobile access gateway performs mobility management on
behalf of a mobile node. behalf of a mobile node.
The mobile access gateway is a function that typically runs on an The mobile access gateway is a function that typically runs on an
access router. However, implementations MAY choose to split this access router. However, implementations MAY choose to split this
function and run it across multiple systems. The specifics on how function and run it across multiple systems. The specifics on how
that is achieved or the signaling interactions between those that is achieved or the signaling interactions between those
functional entities are beyond the scope of this document. functional entities are beyond the scope of this document.
The mobile access gateway has the following key functional roles: The mobile access gateway has the following key functional roles:
skipping to change at page 43, line 36 skipping to change at page 43, line 36
The following are the mandatory fields of the policy profile: The following are the mandatory fields of the policy profile:
o The mobile node's identifier (MN-Identifier) o The mobile node's identifier (MN-Identifier)
o The IPv6 address of the local mobility anchor (LMAA) o The IPv6 address of the local mobility anchor (LMAA)
The following are the optional fields of the policy profile: The following are the optional fields of the policy profile:
o The mobile node's IPv6 home network prefix(es) assigned to the o The mobile node's IPv6 home network prefix(es) assigned to the
mobile node's connected interface. These prefix(es) have to be mobile node's connected interface. These prefix(es) have to be
maintained on a per-interface basis. There can be multiple of maintained on a per-interface basis. There can be multiple unique
these entries one for each interface of the mobile node. The entries for each interface of the mobile node. The specific
specific details on how the network maintains this association details on how the network maintains this association between the
between the prefix set and the interfaces, specially during the prefix set and the interfaces, specially during the mobility
mobility session handoff between interfaces is outside the scope session handoff between interfaces is outside the scope of this
of this document. document.
o The mobile node's IPv6 home network Prefix lifetime. This o The mobile node's IPv6 home network Prefix lifetime. This
lifetime will be same for all the hosted prefixes on the link, as lifetime will be same for all the hosted prefixes on the link, as
they all are part of one mobility session. This value can also be they all are part of one mobility session. This value can also be
same for all the mobile node's mobility sessions. same for all the mobile node's mobility sessions.
o Supported address configuration procedures (Stateful, Stateless or o Supported address configuration procedures (Stateful, Stateless or
both) for the mobile node in the Proxy Mobile IPv6 domain both) for the mobile node in the Proxy Mobile IPv6 domain
6.3. Supported Access Link Types 6.3. Supported Access Link Types
skipping to change at page 47, line 32 skipping to change at page 47, line 32
node's link-local addresses since the mobile access gateway and the node's link-local addresses since the mobile access gateway and the
mobile node will have link-local addresses configured from the same mobile node will have link-local addresses configured from the same
link-local prefix (FE80::/64). This leaves a room for link-local link-local prefix (FE80::/64). This leaves a room for link-local
address collision between the two neighbors (i.e., the mobile node address collision between the two neighbors (i.e., the mobile node
and the mobile access gateway) on that access link. For solving this and the mobile access gateway) on that access link. For solving this
problem, this specification requires that the link-local address that problem, this specification requires that the link-local address that
the mobile access gateway configures on the point-to-point link the mobile access gateway configures on the point-to-point link
shared with a given mobile node be generated by the local mobility shared with a given mobile node be generated by the local mobility
anchor and be stored in the mobile node's Binding Cache entry. This anchor and be stored in the mobile node's Binding Cache entry. This
address will not change for the duration of that mobile node's address will not change for the duration of that mobile node's
session and can be provided to the serving mobile access gateway at mobility session and can be provided to the serving mobile access
every mobile node's handoff, as part of the Proxy Mobile IPv6 gateway at every mobile node's handoff, as part of the Proxy Mobile
signaling messages. The specific method by which the local mobility IPv6 signaling messages. The specific method by which the local
anchor generates the link-local address is out of scope for this mobility anchor generates the link-local address is out of scope for
specification. this specification.
It is highly desirable that the access link on the mobile access It is highly desirable that the access link on the mobile access
gateway shared with the mobile node be provisioned in such a way that gateway shared with the mobile node be provisioned in such a way that
before the mobile node completes the DAD operation [RFC-4862] on its before the mobile node completes the DAD operation [RFC-4862] on its
link-local address, the mobile access gateway on that link is aware link-local address, the mobile access gateway on that link is aware
of its own link-local address provided by the local mobility anchor of its own link-local address provided by the local mobility anchor
that it needs to use on that access link. This essentially requires that it needs to use on that access link. This essentially requires
a successful completion of the Proxy Mobile IPv6 signaling by the a successful completion of the Proxy Mobile IPv6 signaling by the
mobile access gateway before the mobile node completes the DAD mobile access gateway before the mobile node completes the DAD
operation. This can be achieved by ensuring that link layer operation. This can be achieved by ensuring that link layer
skipping to change at page 50, line 46 skipping to change at page 50, line 46
7. The Mobile Node Link-layer Identifier option carrying the link- 7. The Mobile Node Link-layer Identifier option carrying the link-
layer identifier of the currently attached interface MUST be layer identifier of the currently attached interface MUST be
present in the Proxy Binding Update message, if the mobile present in the Proxy Binding Update message, if the mobile
access gateway is aware of the same. If the link-layer access gateway is aware of the same. If the link-layer
identifier of the currently attached interface is not known or identifier of the currently attached interface is not known or
if the identifier value is ALL_ZERO, this option MUST NOT be if the identifier value is ALL_ZERO, this option MUST NOT be
present. present.
8. The Access Technology Type option MUST be present in the Proxy 8. The Access Technology Type option MUST be present in the Proxy
Binding Update message. The access technology type field in the Binding Update message. The access technology type field in the
option SHOULD be set to the type of access technology using option SHOULD be set to the type of access technology by which
which the mobile node is currently attached to the mobile access the mobile node is currently attached to the mobile access
gateway. gateway.
9. The Link-local Address option MUST be present in the Proxy 9. The Link-local Address option MUST be present in the Proxy
Binding Update request only if the value of the configuration Binding Update message only if the value of the configuration
variable FixedMAGLinkLocalAddressOnAllAccessLinks is set to a variable FixedMAGLinkLocalAddressOnAllAccessLinks is set to a
value of ALL_ZERO, otherwise the Link-local Address option MUST value of ALL_ZERO, otherwise the Link-local Address option MUST
NOT be present in the request. Considerations from Section 6.8 NOT be present in the request. Considerations from Section 6.8
MUST be applied when using the Link-local Address option. MUST be applied when using the Link-local Address option.
* For querying the local mobility anchor to provide the link- * For querying the local mobility anchor to provide the link-
local address that it should use on the point-to-point link local address that it should use on the point-to-point link
shared with the mobile node, this option MUST be set to shared with the mobile node, this option MUST be set to
ALL_ZERO value. This essentially serves as a request to the ALL_ZERO value. This essentially serves as a request to the
local mobility anchor to provide the link-local address that local mobility anchor to provide the link-local address that
it can use on the access link shared with the mobile node. it can use on the access link shared with the mobile node.
10. The Proxy Binding Update message MUST be constructed as 10. The Proxy Binding Update message MUST be constructed as
specified in Section 6.9.1.5. specified in Section 6.9.1.5.
11. If there is no existing Binding Update List entry for that 11. If there is no existing Binding Update List entry for that
mobile node, the mobile access gateway MUST create a Binding mobile node, the mobile access gateway MUST create a Binding
Update List entry for the mobile node upon sending the Proxy Update List entry for the mobile node upon sending the Proxy
Binding Update request. Binding Update message.
6.9.1.2. Receiving Binding Registration Reply 6.9.1.2. Receiving Proxy Binding Acknowledgement
On receiving a Proxy Binding Acknowledgement message (format On receiving a Proxy Binding Acknowledgement message (format
specified in Section 8.2) from the local mobility anchor, the mobile specified in Section 8.2) from the local mobility anchor, the mobile
access gateway MUST process the message as specified below. access gateway MUST process the message as specified below.
1. The received Proxy Binding Acknowledgement message (a Binding 1. The received Proxy Binding Acknowledgement message (a Binding
Acknowledgement message with the 'P' flag set to value of 1) Acknowledgement message with the 'P' flag set to value of 1)
MUST be authenticated as described in Section 4. When IPsec is MUST be authenticated as described in Section 4. When IPsec is
used for message authentication, the SPI in the IPsec header used for message authentication, the SPI in the IPsec header
[RFC-4306] of the received packet is needed for locating the [RFC-4306] of the received packet is needed for locating the
skipping to change at page 52, line 26 skipping to change at page 52, line 26
be ignored. be ignored.
6. If the received Proxy Binding Acknowledgement message has any 6. If the received Proxy Binding Acknowledgement message has any
one or more of the following options, Handoff Indicator option, one or more of the following options, Handoff Indicator option,
Access Technology Type option, Mobile Node Link-layer Identifier Access Technology Type option, Mobile Node Link-layer Identifier
option, Mobile Node Identifier option, carrying option values option, Mobile Node Identifier option, carrying option values
that are different from the option values present in the that are different from the option values present in the
corresponding request (Proxy Binding Update) message, the corresponding request (Proxy Binding Update) message, the
message MUST be ignored as the local mobility anchor is expected message MUST be ignored as the local mobility anchor is expected
to echo back all these listed options and with the same option to echo back all these listed options and with the same option
values in the reply message. Further, the mobile access gateway values in the reply message. In this case, the mobile access
MUST NOT retransmit the Proxy Binding Update message till an gateway MUST NOT retransmit the Proxy Binding Update message
administrative action is taken. till an administrative action is taken.
7. If the received Proxy Binding Acknowledgement message has the 7. If the received Proxy Binding Acknowledgement message has the
Status field value set to PROXY_REG_NOT_ENABLED (Proxy Status field value set to PROXY_REG_NOT_ENABLED (Proxy
registration not enabled for the mobile node), the mobile access registration not enabled for the mobile node), the mobile access
gateway SHOULD NOT send binding registration requests again for gateway SHOULD NOT send a Proxy Binding Update message again for
that mobile node. It MUST deny the mobility service to that that mobile node till an administrative action is taken. It
mobile node. MUST deny the mobility service to that mobile node.
8. If the received Proxy Binding Acknowledgement message has the 8. If the received Proxy Binding Acknowledgement message has the
Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED
(Timestamp value lower than previously accepted value), the (Timestamp value lower than previously accepted value), the
mobile access gateway SHOULD try to register again to reassert mobile access gateway SHOULD try to register again to reassert
the mobile node's presence on its access link. The mobile the mobile node's presence on its access link. The mobile
access gateway is not specifically required to synchronize its access gateway is not specifically required to synchronize its
clock upon receiving this error code. clock upon receiving this error code.
9. If the received Proxy Binding Acknowledgement message has the 9. If the received Proxy Binding Acknowledgement message has the
skipping to change at page 53, line 9 skipping to change at page 53, line 9
only after it has synchronized its clock to a common time source only after it has synchronized its clock to a common time source
that is used by all the mobility entities in that domain for that is used by all the mobility entities in that domain for
their clock synchronization. The mobile access gateway SHOULD their clock synchronization. The mobile access gateway SHOULD
NOT synchronize its clock to the local mobility anchor's system NOT synchronize its clock to the local mobility anchor's system
clock, based on the timestamp present in the received message. clock, based on the timestamp present in the received message.
10. If the received Proxy Binding Acknowledgement message has the 10. If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
(The mobile node is not authorized for one or more of the (The mobile node is not authorized for one or more of the
requesting home network prefix(es)), the mobile access gateway requesting home network prefix(es)), the mobile access gateway
SHOULD NOT request for the same prefix(es) again, but can only SHOULD NOT request for the same prefix(es) again, but MAY
request the local mobility anchor to do the assignment of request the local mobility anchor to do the assignment of
prefix(es) by including only one Home Network Prefix option with prefix(es) by including only one Home Network Prefix option with
the prefix value set to ALL_ZERO. the prefix value set to ALL_ZERO.
11. If the received Proxy Binding Acknowledgement message has the 11. If the received Proxy Binding Acknowledgement message has the
Status field value set to any value greater than or equal to 128 Status field value set to any value greater than or equal to 128
(i.e., if the binding is rejected), the mobile access gateway (i.e., if the binding is rejected), the mobile access gateway
MUST NOT advertise the mobile node's home network prefix(es) in MUST NOT advertise the mobile node's home network prefix(es) in
the Router Advertisement messages sent on that access link and the Router Advertisement messages sent on that access link and
MUST deny the mobility service to the mobile node by not MUST deny the mobility service to the mobile node by not
skipping to change at page 53, line 40 skipping to change at page 53, line 40
the dynamically created bi-directional tunnel. the dynamically created bi-directional tunnel.
13. The mobile access gateway MUST set up the route for forwarding 13. The mobile access gateway MUST set up the route for forwarding
the packets received from the mobile node using address(es) from the packets received from the mobile node using address(es) from
its home network prefix(es) through the bi-directional set up its home network prefix(es) through the bi-directional set up
for that mobile node. The created tunnel and the routing state for that mobile node. The created tunnel and the routing state
MUST result in the forwarding behavior on the mobile access MUST result in the forwarding behavior on the mobile access
gateway as specified in Section 6.10.5. gateway as specified in Section 6.10.5.
14. The mobile access gateway MUST also update the Binding Update 14. The mobile access gateway MUST also update the Binding Update
List entry for reflecting the accepted binding registration List entry to reflect the accepted binding registration values.
values. It MUST also advertise the mobile node's home network It MUST also advertise the mobile node's home network prefix(es)
prefix(es) as the hosted on-link prefixes, by including them in as the hosted on-link prefixes, by including them in the Router
the Router Advertisement messages that it sends on that access Advertisement messages that it sends on that access link.
link.
15. If the received Proxy Binding Acknowledgement message has the 15. If the received Proxy Binding Acknowledgement message has the
address in the Link-local Address option set to a NON_ZERO address in the Link-local Address option set to a NON_ZERO
value, the mobile access gateway SHOULD configure that link- value, the mobile access gateway SHOULD configure that link-
local address on that point-to-point link and SHOULD NOT local address on that point-to-point link and SHOULD NOT
configure any other link-local address without performing a DAD configure any other link-local address without performing a DAD
operation [RFC-4862]. This will avoid any potential link-local operation [RFC-4862]. This will avoid any potential link-local
address collisions on that access link. However, if the link- address collisions on that access link. However, if the link-
local address generated by the local mobility anchor happens to local address generated by the local mobility anchor happens to
be already in use by the mobile node on that link, the mobile be already in use by the mobile node on that link, the mobile
access gateway MUST NOT use that address, but SHOULD configure a access gateway MUST NOT use that address, but SHOULD configure a
different link-local address. It SHOULD also upload this link- different link-local address. It SHOULD also upload this link-
local address to the local mobility anchor by immediately local address to the local mobility anchor by immediately
sending a Proxy Binding Update request and by including this sending a Proxy Binding Update message and by including this
address in the Link-local Address option. address in the Link-local Address option.
6.9.1.3. Extending Binding Lifetime 6.9.1.3. Extending Binding Lifetime
1. For extending the lifetime of a currently registered mobile node 1. For extending the lifetime of a currently registered mobile node
(i.e., after a successful initial binding registration from the (i.e., after a successful initial binding registration from the
same mobile access gateway), the mobile access gateway can send a same mobile access gateway), the mobile access gateway can send a
Proxy Binding Update message to the local mobility anchor with a Proxy Binding Update message to the local mobility anchor with a
new lifetime value. This re-registration message MUST be new lifetime value. This re-registration message MUST be
constructed with the same set of options as the initial binding constructed with the same set of options as the initial Proxy
registration message, under the considerations specified in Binding Update message, under the considerations specified in
Section 6.9.1.1. However the following exceptions apply. Section 6.9.1.1. However the following exceptions apply.
2. There MUST be a Home Network Prefix option for each of the 2. There MUST be a Home Network Prefix option for each of the
assigned home network prefixes assigned for that mobility session assigned home network prefixes assigned for that mobility session
and with the prefix value in the option set to that respective and with the prefix value in the option set to that respective
prefix value. prefix value.
3. The Handoff Indicator field in the Handoff Indicator option MUST 3. The Handoff Indicator field in the Handoff Indicator option MUST
be set to a value of 5 (Handoff state not changed - Re- be set to a value of 5 (Handoff state not changed - Re-
Registration). Registration).
6.9.1.4. Mobile Node Detachment and Binding De-Registration 6.9.1.4. Mobile Node Detachment and Binding De-Registration
1. If at any point the mobile access gateway detects that the mobile 1. If at any point the mobile access gateway detects that the mobile
node has moved away from its access link, or if it decides to node has moved away from its access link, or if it decides to
terminate the mobile node's mobility session, it SHOULD send a terminate the mobile node's mobility session, it SHOULD send a
Proxy Binding Update message to the local mobility anchor with Proxy Binding Update message to the local mobility anchor with
the lifetime value set to zero. This de-registration message the lifetime value set to zero. This de-registration message
MUST be constructed with the same set of options as the initial MUST be constructed with the same set of options as the initial
binding registration message, under the considerations specified Proxy Binding Update message, under the considerations specified
in Section 6.9.1.1. However, the following exceptions apply. in Section 6.9.1.1. However, the following exceptions apply.
2. There MUST be a Home Network Prefix option for each of the 2. There MUST be a Home Network Prefix option for each of the
assigned home network prefix(es) assigned for that mobility assigned home network prefix(es) assigned for that mobility
session and with the prefix value in the option set to the session and with the prefix value in the option set to the
respective prefix value. respective prefix value.
3. The Handoff Indicator field in the Handoff Indicator option MUST 3. The Handoff Indicator field in the Handoff Indicator option MUST
be set to a value of 4 (Handoff state unknown). be set to a value of 4 (Handoff state unknown).
Either upon receipt of a Proxy Binding Acknowledgement message from Either upon receipt of a Proxy Binding Acknowledgement message from
the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775] the local mobility anchor with the Status field set to 0 (Proxy
Binding Update Accepted), or after INITIAL_BINDACK_TIMEOUT [RFC-3775]
timeout waiting for the reply, the mobile access gateway MUST do the timeout waiting for the reply, the mobile access gateway MUST do the
following: following:
1. It MUST remove the Binding Update List entry for the mobile node 1. It MUST remove the Binding Update List entry for the mobile node
from its Binding Update List. from its Binding Update List.
2. It MUST remove the created routing state for tunneling the mobile 2. It MUST remove the created routing state for tunneling the mobile
node's traffic. node's traffic.
3. If there is a dynamically created tunnel to the mobile node's 3. If there is a dynamically created tunnel to the mobile node's
skipping to change at page 55, line 28 skipping to change at page 55, line 29
which the tunnel is being used, then the tunnel MUST be deleted. which the tunnel is being used, then the tunnel MUST be deleted.
4. It MUST tear down the point-to-point link shared with the mobile 4. It MUST tear down the point-to-point link shared with the mobile
node. This action will force the mobile node to remove any IPv6 node. This action will force the mobile node to remove any IPv6
address configuration on the interface connected to this point- address configuration on the interface connected to this point-
to-point link. to-point link.
6.9.1.5. Constructing the Proxy Binding Update Message 6.9.1.5. Constructing the Proxy Binding Update Message
o The mobile access gateway when sending the Proxy Binding Update o The mobile access gateway when sending the Proxy Binding Update
request to the local mobility anchor MUST construct the message as message to the local mobility anchor MUST construct the message as
specified below. specified below.
IPv6 header (src=Proxy-CoA, dst=LMAA) IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header Mobility header
- BU /* P & A flags MUST be set to value 1 */ - BU /* P & A flags MUST be set to value 1 */
Mobility Options Mobility Options
- Mobile Node Identifier option (mandatory) - Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory) - Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory) - Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory) - Access Technology Type option (mandatory)
- Timestamp option (optional) - Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional) - Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional) - Link-local Address option (optional)
Figure 12: Proxy Binding Update message format Figure 12: Proxy Binding Update message format
o The Source Address field in the IPv6 header of the message MUST be o The Source Address field in the IPv6 header of the message MUST be
set to the global address configured on the egress interface of set to the global address configured on the egress interface of
the mobile access gateway. When there is no Alternate Care-of the mobile access gateway. When there is no Alternate Care-of
Address option present in the request, this address will be Address option present in the request, this address will be
considered as the Proxy-CoA address for this binding registration considered as the Proxy-CoA address for this Proxy Binding Update
request. However, when there is Alternate Care-of Address option message. However, when there is Alternate Care-of Address option
present in the request, this address will be not be considered as present in the request, this address will be not be considered as
the Proxy-CoA address, but the address in the alternate Care-of the Proxy-CoA address, but the address in the alternate Care-of
Address option will be considered as the Proxy-CoA address. Address option will be considered as the Proxy-CoA address.
o The Destination Address field in the IPv6 header of the message o The Destination Address field in the IPv6 header of the message
MUST be set to the local mobility anchor address. MUST be set to the local mobility anchor address.
o The Mobile Node Identifier option [RFC-4283] MUST be present. o The Mobile Node Identifier option [RFC-4283] MUST be present.
o At least one Home Network Prefix option MUST be present. o At least one Home Network Prefix option MUST be present.
skipping to change at page 57, line 5 skipping to change at page 57, line 5
the following considerations. the following considerations.
1. The mobile access gateway on receiving the Router Solicitation 1. The mobile access gateway on receiving the Router Solicitation
message SHOULD send a Router Advertisement message containing the message SHOULD send a Router Advertisement message containing the
mobile node's home network prefix(es) as the on-link prefix(es). mobile node's home network prefix(es) as the on-link prefix(es).
However, before sending the Router Advertisement message However, before sending the Router Advertisement message
containing the mobile node's home network prefix(es), it SHOULD containing the mobile node's home network prefix(es), it SHOULD
complete the binding registration process with the mobile node's complete the binding registration process with the mobile node's
local mobility anchor. local mobility anchor.
2. If the local mobility anchor rejects the binding registration 2. If the local mobility anchor rejects the Proxy Binding Update
request, or, if the mobile access gateway failed to complete the message, or, if the mobile access gateway failed to complete the
binding registration process for whatever reason, the mobile binding registration process for whatever reason, the mobile
access gateway MUST NOT advertise the mobile node's home network access gateway MUST NOT advertise the mobile node's home network
prefix(es) in the Router Advertisement messages that it sends on prefix(es) in the Router Advertisement messages that it sends on
the access link. However, it MAY choose to advertise a local the access link. However, it MAY choose to advertise a local
visited network prefix(es) to enable the mobile node for regular visited network prefix(es) to enable the mobile node for regular
IPv6 access. IPv6 access.
3. The mobile access gateway SHOULD add the MTU option, as specified 3. The mobile access gateway SHOULD add the MTU option, as specified
in [RFC-4861], to the Router Advertisement messages that it sends in [RFC-4861], to the Router Advertisement messages that it sends
on the access link. This will ensure the mobile node on the link on the access link. This will ensure the mobile node on the link
skipping to change at page 58, line 20 skipping to change at page 58, line 20
There is, however, ongoing work at the IETF to revise the SEND There is, however, ongoing work at the IETF to revise the SEND
specifications. It is suggested that these revisions also address specifications. It is suggested that these revisions also address
the above problem. Other revisions are needed to deal with other the above problem. Other revisions are needed to deal with other
problematic cases (such as Neighbor Discovery proxies) before wide- problematic cases (such as Neighbor Discovery proxies) before wide-
spread deployment of SEND. spread deployment of SEND.
6.9.4. Retransmissions and Rate Limiting 6.9.4. Retransmissions and Rate Limiting
The mobile access gateway is responsible for retransmissions and rate The mobile access gateway is responsible for retransmissions and rate
limiting the binding registration requests that it sends to the local limiting the Proxy Binding Update messages that it sends to the local
mobility anchor. The Retransmission and the Rate Limiting rules are mobility anchor. The Retransmission and the Rate Limiting rules are
as specified in [RFC-3775]. However, the following considerations as specified in [RFC-3775]. However, the following considerations
MUST be applied. MUST be applied.
1. When the mobile access gateway sends a Proxy Binding Update 1. When the mobile access gateway sends a Proxy Binding Update
request, it should use the constant, INITIAL_BINDACK_TIMEOUT message, it should use the constant, INITIAL_BINDACK_TIMEOUT
[RFC-3775], for configuring the retransmission timer, as [RFC-3775], for configuring the retransmission timer, as
specified in Section 11.8 [RFC-3775]. However, the mobile access specified in Section 11.8 [RFC-3775]. However, the mobile access
gateway is not required to use a longer retransmission interval gateway is not required to use a longer retransmission interval
of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for
the initial binding registration request. the initial Proxy Binding Update message.
2. If the mobile access gateway fails to receive a valid matching 2. If the mobile access gateway fails to receive a valid matching
response for a registration or re-registration message within the response for a registration or re-registration message within the
retransmission interval, it SHOULD retransmit the message until a retransmission interval, it SHOULD retransmit the message until a
response is received. However, the mobile access gateway MUST response is received. However, the mobile access gateway MUST
ensure the mobile node is still attached to the connected link ensure the mobile node is still attached to the connected link
before retransmitting the message. before retransmitting the message.
3. As specified in Section 11.8 of [RFC-3775], the mobile access 3. As specified in Section 11.8 of [RFC-3775], the mobile access
gateway MUST use an exponential back-off process in which the gateway MUST use an exponential back-off process in which the
skipping to change at page 62, line 34 skipping to change at page 62, line 34
o On receiving a packet from the bi-directional tunnel established o On receiving a packet from the bi-directional tunnel established
with the mobile node's local mobility anchor, the mobile access with the mobile node's local mobility anchor, the mobile access
gateway MUST use the destination address of the inner packet for gateway MUST use the destination address of the inner packet for
forwarding it on the interface where the destination network forwarding it on the interface where the destination network
prefix is hosted. The mobile access gateway MUST remove the outer prefix is hosted. The mobile access gateway MUST remove the outer
header before forwarding the packet. Considerations from [RFC- header before forwarding the packet. Considerations from [RFC-
2473] MUST be applied for IPv6 decapsulation. If the mobile 2473] MUST be applied for IPv6 decapsulation. If the mobile
access gateway cannot find the connected interface for that access gateway cannot find the connected interface for that
destination address, it MUST silently drop the packet. For destination address, it MUST silently drop the packet. For
reporting an error in such a scenario, in the form of ICMP control reporting an error in such a scenario, in the form of a ICMP
message, the considerations from [RFC-2473] MUST be applied. control message, the considerations from [RFC-2473] MUST be
applied.
o On receiving a packet from a correspondent node that is locally o On receiving a packet from a correspondent node that is locally
connected and which is destined to a mobile node that is on connected and which is destined to a mobile node that is on
another locally connected access link, the mobile access gateway another locally connected access link, the mobile access gateway
MUST check the flag EnableMAGLocalRouting, to ensure the mobile MUST check the flag EnableMAGLocalRouting, to ensure the mobile
access gateway is allowed to route the packet directly to the access gateway is allowed to route the packet directly to the
mobile node. If the mobile access gateway is not allowed to route mobile node. If the mobile access gateway is not allowed to route
the packet directly, it MUST route the packet through the bi- the packet directly, it MUST route the packet through the bi-
directional tunnel established between itself and the mobile directional tunnel established between itself and the mobile
node's local mobility anchor. Otherwise, it can route the packet node's local mobility anchor. Otherwise, it can route the packet
skipping to change at page 66, line 45 skipping to change at page 66, line 50
mobile node and the mobile access gateway and is outside the scope of mobile node and the mobile access gateway and is outside the scope of
this document. Typically, there are various link-layer specific this document. Typically, there are various link-layer specific
events specific to each access technology that the mobile access events specific to each access technology that the mobile access
gateway can depend on for detecting the node loss. In general, the gateway can depend on for detecting the node loss. In general, the
mobile access gateway can depend on one or more of the following mobile access gateway can depend on one or more of the following
methods for the detection presence of the mobile node on the methods for the detection presence of the mobile node on the
connected link: connected link:
o Link-layer event specific to the access technology o Link-layer event specific to the access technology
o PPP Session termination event on point-to-point link types o Session termination event on point-to-point link types
o IPv6 Neighbor Unreachability Detection event from IPv6 stack o IPv6 Neighbor Unreachability Detection event from IPv6 stack
o Notification event from the local mobility anchor o Notification event from the local mobility anchor
6.14. Allowing network access to other IPv6 nodes 6.14. Allowing network access to other IPv6 nodes
In some Proxy Mobile IPv6 deployments, network operators may want to In some Proxy Mobile IPv6 deployments, network operators may want to
provision the mobile access gateway to offer network-based mobility provision the mobile access gateway to offer network-based mobility
management service only to some visiting mobile nodes and enable just management service only to some visiting mobile nodes and enable just
regular IP access to some other nodes. This requires the network to regular IP access to some other nodes. This requires the network to
skipping to change at page 67, line 50 skipping to change at page 68, line 6
7.1. Moving into a Proxy Mobile IPv6 Domain 7.1. Moving into a Proxy Mobile IPv6 Domain
When a mobile node enters a Proxy Mobile IPv6 domain and attaches to When a mobile node enters a Proxy Mobile IPv6 domain and attaches to
an access network, the mobile access gateway on the access link an access network, the mobile access gateway on the access link
detects the attachment of the mobile node and completes the binding detects the attachment of the mobile node and completes the binding
registration with the mobile node's local mobility anchor. If the registration with the mobile node's local mobility anchor. If the
binding update operation is successfully performed, the mobile access binding update operation is successfully performed, the mobile access
gateway will create the required state and set up the forwarding for gateway will create the required state and set up the forwarding for
the mobile node's data traffic. the mobile node's data traffic.
If the mobile node is IPv6 enabled, on attaching to the access link, When a mobile node attaches to the access link, it will typically
it will typically send a Router Solicitation message [RFC-4861]. The send a Router Solicitation message [RFC-4861]. The mobile access
mobile access gateway on the access link will respond to the Router gateway on the access link will respond to the Router Solicitation
Solicitation message with a Router Advertisement message. The Router message with a Router Advertisement message. The Router
Advertisement message will carry the mobile node's home network Advertisement message will carry the mobile node's home network
prefix(es), default-router address and other address configuration prefix(es), default-router address and other address configuration
Parameters. Parameters.
If the mobile access gateway on the access link receives a Router If the mobile access gateway on the access link receives a Router
Solicitation message from the mobile node, before it completes the Solicitation message from the mobile node, before it completes the
signaling with the mobile node's local mobility anchor, the mobile signaling with the mobile node's local mobility anchor, the mobile
access gateway may not know the mobile node's home network prefix(es) access gateway may not know the mobile node's home network prefix(es)
and may not be able to emulate the mobile node's home link on the and may not be able to emulate the mobile node's home link on the
access link. In such a scenario, the mobile node may notice a delay access link. In such a scenario, the mobile node may notice a delay
skipping to change at page 72, line 35 skipping to change at page 72, line 35
Additionally, there can one or more instances of the Vendor- Additionally, there can one or more instances of the Vendor-
Specific Mobility option [RFC-5094]. Specific Mobility option [RFC-5094].
Status Status
8-bit unsigned integer indicating the disposition of the Proxy 8-bit unsigned integer indicating the disposition of the Proxy
Binding Update. Values of the Status field less than 128 indicate Binding Update. Values of the Status field less than 128 indicate
that the Proxy Binding Update was accepted by the local mobility that the Proxy Binding Update was accepted by the local mobility
anchor. Values greater than or equal to 128 indicate that the anchor. Values greater than or equal to 128 indicate that the
binding registration was rejected by the local mobility anchor. Proxy Binding Update message was rejected by the local mobility
Section 8.9 defines the Status values that can used in Proxy anchor. Section 8.9 defines the Status values that can used in
Binding Acknowledgement message. Proxy Binding Acknowledgement message.
For descriptions of other fields present in this message, refer to For descriptions of other fields present in this message, refer to
the section 6.1.8 of [RFC-3775]. the section 6.1.8 of [RFC-3775].
8.3. Home Network Prefix Option 8.3. Home Network Prefix Option
A new option, Home Network Prefix Option is defined for using it in A new option, Home Network Prefix Option is defined for use with the
the Proxy Binding Update and Proxy Binding Acknowledgement messages Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the mobile node's home gateway. This option is used for exchanging the mobile node's home
network prefix information. There can be multiple Home Network network prefix information. There can be multiple Home Network
Prefix options present in the message. Prefix options present in the message.
The Home Network Prefix Option has an alignment requirement of 8n+4. The Home Network Prefix Option has an alignment requirement of 8n+4.
Its format is as follows: Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 73, line 46 skipping to change at page 73, line 46
8-bit unsigned integer indicating the prefix length of the 8-bit unsigned integer indicating the prefix length of the
IPv6 prefix contained in the option. IPv6 prefix contained in the option.
Home Network Prefix Home Network Prefix
A sixteen-byte field containing the mobile node's IPv6 Home A sixteen-byte field containing the mobile node's IPv6 Home
Network Prefix. Network Prefix.
8.4. Handoff Indicator Option 8.4. Handoff Indicator Option
A new option, Handoff Indicator Option is defined for using it in the A new option, Handoff Indicator Option is defined for use with the
Proxy Binding Update and Proxy Binding Acknowledgement messages Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the mobile node's gateway. This option is used for exchanging the mobile node's
handoff related hints. handoff related hints.
The Handoff Indicator Option has no alignment requirement. Its The Handoff Indicator Option has no alignment requirement. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 74, line 44 skipping to change at page 74, line 44
0: Reserved 0: Reserved
1: Attachment over a new interface 1: Attachment over a new interface
2: Handoff between two different interfaces of the mobile node 2: Handoff between two different interfaces of the mobile node
3: Handoff between mobile access gateways for the same interface 3: Handoff between mobile access gateways for the same interface
4: Handoff state unknown 4: Handoff state unknown
5: Handoff state not changed (Re-registration) 5: Handoff state not changed (Re-registration)
8.5. Access Technology Type Option 8.5. Access Technology Type Option
A new option, Access Technology Type Option is defined for using it A new option, Access Technology Type Option is defined for use with
in the Proxy Binding Update and Proxy Binding Acknowledgement the Proxy Binding Update and Proxy Binding Acknowledgement messages
messages exchanged between a local mobility anchor and a mobile exchanged between a local mobility anchor and a mobile access
access gateway. This option is used for exchanging the type of the gateway. This option is used for exchanging the type of the access
access technology using which the mobile node is currently attached technology by which the mobile node is currently attached to the
to the mobile access gateway. mobile access gateway.
The Access Technology Type Option has no alignment requirement. Its The Access Technology Type Option has no alignment requirement. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) | ATT | | Type | Length | Reserved (R) | ATT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 76, line 8 skipping to change at page 76, line 8
0: Reserved ("Reserved") 0: Reserved ("Reserved")
1: Virtual ("Logical Network Interface") 1: Virtual ("Logical Network Interface")
2: PPP ("Point-to-Point Protocol") 2: PPP ("Point-to-Point Protocol")
3: IEEE 802.3 ("Ethernet") 3: IEEE 802.3 ("Ethernet")
4: IEEE 802.11a/b/g ("Wireless LAN") 4: IEEE 802.11a/b/g ("Wireless LAN")
5: IEEE 802.16e ("WIMAX") 5: IEEE 802.16e ("WIMAX")
8.6. Mobile Node Link-layer Identifier Option 8.6. Mobile Node Link-layer Identifier Option
A new option, Mobile Node Link-layer Identifier Option is defined for A new option, Mobile Node Link-layer Identifier Option is defined for
using it in the Proxy Binding Update and Proxy Binding use with the Proxy Binding Update and Proxy Binding Acknowledgement
Acknowledgement messages exchanged between a local mobility anchor messages exchanged between a local mobility anchor and a mobile
and a mobile access gateway. This option is used for exchanging the access gateway. This option is used for exchanging the mobile node's
mobile node's link-layer identifier. link-layer identifier.
The format of the Link-layer Identifier option is shown below. Based The format of the Link-layer Identifier option is shown below. Based
on the size of the identifier, the option MUST be aligned on the size of the identifier, the option MUST be aligned
appropriately, as per mobility option alignment requirements appropriately, as per mobility option alignment requirements
specified in [RFC-3775]. specified in [RFC-3775].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
skipping to change at page 77, line 8 skipping to change at page 77, line 8
identifier. identifier.
The content and format of this field (including byte and bit The content and format of this field (including byte and bit
ordering) is as specified in Section 4.6 of [RFC-4861] for ordering) is as specified in Section 4.6 of [RFC-4861] for
carrying Link-Layer Address. On certain access links, where carrying Link-Layer Address. On certain access links, where
the link-layer address is not used or cannot be determined, the link-layer address is not used or cannot be determined,
this option cannot be used. this option cannot be used.
8.7. Link-local Address Option 8.7. Link-local Address Option
A new option, Link-local Address Option is defined for using it in A new option, Link-local Address Option is defined for use with the
the Proxy Binding Update and Proxy Binding Acknowledgement messages Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the link-local address gateway. This option is used for exchanging the link-local address
of the mobile access gateway. of the mobile access gateway.
The Link-local Address option has an alignment requirement of 8n+6. The Link-local Address option has an alignment requirement of 8n+6.
Its format is as follows: Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 77, line 42 skipping to change at page 77, line 42
<IANA> <IANA>
Length Length
8-bit unsigned integer indicating the length of the option 8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field in octets, excluding the type and length fields. This field
MUST be set to 16. MUST be set to 16.
Link-local Address Link-local Address
A sixteen-byte field containing the mobile node's link-local A sixteen-byte field containing the link-local address.
address.
8.8. Timestamp Option 8.8. Timestamp Option
A new option, Timestamp Option is defined for use in the Proxy A new option, Timestamp Option is defined for use in the Proxy
Binding Update and Proxy Binding Acknowledgement messages. Binding Update and Proxy Binding Acknowledgement messages.
The Timestamp option has an alignment requirement of 8n+2. Its The Timestamp option has an alignment requirement of 8n+2. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 79, line 4 skipping to change at page 79, line 4
second. second.
8.9. Status Values 8.9. Status Values
This document defines the following new Status values for use in This document defines the following new Status values for use in
Proxy Binding Acknowledgement message. These values are to be Proxy Binding Acknowledgement message. These values are to be
allocated from the same number space, as defined in Section 6.1.8 of allocated from the same number space, as defined in Section 6.1.8 of
[RFC-3775]. [RFC-3775].
Status values less than 128 indicate that the Proxy Binding Update Status values less than 128 indicate that the Proxy Binding Update
request was accepted by the local mobility anchor. Status values message was accepted by the local mobility anchor. Status values
greater than 128 indicate that the Proxy Binding Update was rejected greater than 128 indicate that the Proxy Binding Update was rejected
by the local mobility anchor. by the local mobility anchor.
PROXY_REG_NOT_ENABLED: IANA PROXY_REG_NOT_ENABLED: IANA
Proxy registration not enabled for the mobile node Proxy registration not enabled for the mobile node
NOT_LMA_FOR_THIS_MOBILE_NODE: IANA NOT_LMA_FOR_THIS_MOBILE_NODE: IANA
Not local mobility anchor for this mobile node Not local mobility anchor for this mobile node
MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA
The mobile access gateway is not authorized to send proxy binding The mobile access gateway is not authorized to send proxy binding
registrations updates
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA
The mobile node is not authorized for one or more of the The mobile node is not authorized for one or more of the
requesting home network prefixes. requesting home network prefixes
TIMESTAMP_MISMATCH: IANA TIMESTAMP_MISMATCH: IANA
Invalid timestamp value (the clocks are out of sync) Invalid timestamp value (the clocks are out of sync)
TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA
The timestamp value is lower than the previously accepted value The timestamp value is lower than the previously accepted value
MISSING_HOME_NETWORK_PREFIX_OPTION: IANA MISSING_HOME_NETWORK_PREFIX_OPTION: IANA
skipping to change at page 80, line 18 skipping to change at page 80, line 18
MISSING_HANDOFF_INDICATOR_OPTION: IANA MISSING_HANDOFF_INDICATOR_OPTION: IANA
Missing handoff indicator option Missing handoff indicator option
MISSING_ACCESS_TECH_TYPE_OPTION: IANA MISSING_ACCESS_TECH_TYPE_OPTION: IANA
Missing access technology type option Missing access technology type option
Additionally, the following Status values defined in [RFC-3775] can Additionally, the following Status values defined in [RFC-3775] can
also be used in Proxy Binding Acknowledgement message. also be used in a Proxy Binding Acknowledgement message.
0 Proxy Binding Update accepted 0 Proxy Binding Update accepted
128 Reason unspecified 128 Reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Insufficient resources 130 Insufficient resources
9. Protocol Configuration Variables 9. Protocol Configuration Variables
skipping to change at page 81, line 25 skipping to change at page 81, line 25
local mobility anchor MUST wait for the de-registration message local mobility anchor MUST wait for the de-registration message
for an existing mobility session before it decides to create a new for an existing mobility session before it decides to create a new
mobility session. mobility session.
The default value for this variable is 1500 milliseconds. The default value for this variable is 1500 milliseconds.
Note that there is a dependency between this value and the values Note that there is a dependency between this value and the values
used in the retransmission algorithm for Proxy Binding Updates. used in the retransmission algorithm for Proxy Binding Updates.
The retransmissions need to happen before The retransmissions need to happen before
MaxDelayBeforeNewBCEAssign runs out, as otherwise there are MaxDelayBeforeNewBCEAssign runs out, as otherwise there are
situations where a de-registration from and old mobile access situations where a de-registration from a previous mobile access
gateway may be lost, and the local mobility anchor creates gateway may be lost, and the local mobility anchor creates
needlessly a new session and new prefixes for the mobile node. needlessly a new mobility session and new prefixes for the mobile
This affects situations where there is no information from the node. This affects situations where there is no information from
lower layers about the type of a handoff or other parameters that the lower layers about the type of a handoff or other parameters
can be used for identifying the mobility session, however. that can be used for identifying the mobility session, however.
TimestampValidityWindow TimestampValidityWindow
This variable specifies the maximum amount of time difference in This variable specifies the maximum amount of time difference in
milliseconds between the timestamp in the received Proxy Binding milliseconds between the timestamp in the received Proxy Binding
Update message and the current time-of-day on the local mobility Update message and the current time-of-day on the local mobility
anchor, that is allowed by the local mobility anchor for the anchor, that is allowed by the local mobility anchor for the
received message to be considered valid. received message to be considered valid.
The default value for this variable is 300 milliseconds. This The default value for this variable is 300 milliseconds. This
skipping to change at page 82, line 27 skipping to change at page 82, line 27
When the value of this flag is set to value of 1, the mobile When the value of this flag is set to value of 1, the mobile
access gateway MUST route the traffic locally. access gateway MUST route the traffic locally.
This aspect of local routing MAY be defined as policy on a per This aspect of local routing MAY be defined as policy on a per
mobile basis and when present will take precedence over this flag. mobile basis and when present will take precedence over this flag.
9.3. Proxy Mobile IPv6 Domain - Configuration Variables 9.3. Proxy Mobile IPv6 Domain - Configuration Variables
All the mobile entities (local mobility anchors and mobile access All the mobile entities (local mobility anchors and mobile access
gateways in a Proxy Mobile IPv6 domain MUST allow the following gateways) in a Proxy Mobile IPv6 domain MUST allow the following
variables to be configured by the system management. The configured variables to be configured by the system management. The configured
values for these protocol variables MUST survive server reboots and values for these protocol variables MUST survive server reboots and
service restarts. These variables MUST be globally fixed for a given service restarts. These variables MUST be globally fixed for a given
Proxy Mobile IPv6 domain resulting in the same values being enforced Proxy Mobile IPv6 domain resulting in the same values being enforced
on all the mobility entities in that domain. on all the mobility entities in that domain.
MobileNodeGeneratedTimestampInUse MobileNodeGeneratedTimestampInUse
This flag indicates whether or not the mobile node generated This flag indicates whether or not the mobile node generated
timestamp mechanism is in use in that Proxy Mobile IPv6 domain. timestamp mechanism is in use in that Proxy Mobile IPv6 domain.
When the value for this flag is set to 1, the local mobility When the value for this flag is set to 1, the local mobility
anchors and mobile access gateways in that Proxy Mobile IPv6 anchors and mobile access gateways in that Proxy Mobile IPv6
domain MUST apply the mobile node generated timestamp domain MUST apply the mobile node generated timestamp
considerations. considerations as specified in Section 5.5.
The default value for this flag is set to value of 0, indicating The default value for this flag is set to value of 0, indicating
that the mobile node generated timestamp mechanism is not in use that the mobile node generated timestamp mechanism is not in use
in that Proxy Mobile IPv6 domain. in that Proxy Mobile IPv6 domain.
FixedMAGLinkLocalAddressOnAllAccessLinks FixedMAGLinkLocalAddressOnAllAccessLinks
This variable indicates the link-local address value that all the This variable indicates the link-local address value that all the
mobile access gateways SHOULD use on any of the access links mobile access gateways SHOULD use on any of the access links
shared with any of the mobile nodes in that Proxy Mobile IPv6 shared with any of the mobile nodes in that Proxy Mobile IPv6
domain. If this variable is initialized to ALL_ZERO value, it domain. If this variable is initialized to ALL_ZERO value, it
skipping to change at page 84, line 12 skipping to change at page 84, line 12
as defined in [RFC-3775]. The allocated values for each of these as defined in [RFC-3775]. The allocated values for each of these
status values must be greater than 128. status values must be greater than 128.
11. Security Considerations 11. Security Considerations
The potential security threats against any network-based mobility The potential security threats against any network-based mobility
management protocol are described in [RFC-4832]. This section management protocol are described in [RFC-4832]. This section
explains how Proxy Mobile IPv6 protocol defends itself against those explains how Proxy Mobile IPv6 protocol defends itself against those
threats. threats.
Proxy Mobile IPv6 protocol requires the signaling messages, Proxy Proxy Mobile IPv6 protocol recommends the signaling messages, Proxy
Binding Update and Proxy Binding Acknowledgement, exchanged between Binding Update and Proxy Binding Acknowledgement, exchanged between
the mobile access gateway and the local mobility anchor to be the mobile access gateway and the local mobility anchor to be
protected using IPsec, using the established security association protected using IPsec, using the established security association
between them. This essentially eliminates the threats related to the between them. This essentially eliminates the threats related to the
impersonation of the mobile access gateway or the local mobility impersonation of the mobile access gateway or the local mobility
anchor. anchor.
This specification allows a mobile access gateway to send binding This specification allows a mobile access gateway to send binding
registration messages on behalf of a mobile node. If proper registration messages on behalf of a mobile node. If proper
authorization checks are not in place, a malicious node may be able authorization checks are not in place, a malicious node may be able
to hijack a mobile node's session or may carry out a denial-of- to hijack a mobile node's mobility session or may carry out a denial-
service attack. To prevent this attack, this specification requires of-service attack. To prevent this attack, this specification
the local mobility anchor to allow only authorized mobile access requires the local mobility anchor to allow only authorized mobile
gateways that are part of that Proxy Mobile IPv6 domain to send access gateways that are part of that Proxy Mobile IPv6 domain to
binding registration messages on behalf of a mobile node. send Proxy Binding Update messages on behalf of a mobile node.
To eliminate the threats on the interface between the mobile access To eliminate the threats on the interface between the mobile access
gateway and the mobile node, this specification requires an gateway and the mobile node, this specification requires an
established trust between the mobile access gateway and the mobile established trust between the mobile access gateway and the mobile
node and to authenticate and authorize the mobile node before it is node and to authenticate and authorize the mobile node before it is
allowed to access the network. Further, the established allowed to access the network. Further, the established
authentication mechanisms enabled on that access link will ensure authentication mechanisms enabled on that access link will ensure
that there is a secure binding between the mobile node's identity and that there is a secure binding between the mobile node's identity and
its link-layer address. The mobile access gateway will definitively its link-layer address. The mobile access gateway will definitively
identify the mobile node from the packets that it receives on that identify the mobile node from the packets that it receives on that
access link. access link.
To address the threat related to a compromised mobile access gateway, To address the threat related to a compromised mobile access gateway,
the local mobility anchor, before accepting a Proxy Binding Update the local mobility anchor, before accepting a Proxy Binding Update
message for a given mobile node, may ensure that the mobile node is message for a given mobile node, may ensure that the mobile node is
definitively attached to the mobile access gateway that sent the attached to the mobile access gateway that sent the Proxy Binding
proxy binding registration request. This may be accomplished by Update message. This may be accomplished by contacting a trusted
contacting a trusted entity which is able to track the mobile node's entity which is able to track the mobile node's current point of
current point of attachment. However, the specific details of the attachment. However, the specific details of the actual mechanisms
actual mechanisms for achieving this is outside the scope of this for achieving this is outside the scope of this document.
document.
12. Acknowledgements 12. Acknowledgements
The authors would like to specially thank Jari Arkko, Julien The authors would like to specially thank Jari Arkko, Julien
Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann, Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann,
Brian Haley, Ahmad Muhanna, JinHyeock Choi and Elwyn Davies for their Brian Haley, Ahmad Muhanna, JinHyeock Choi and Elwyn Davies for their
thorough review of this document. thorough review of this document.
The authors would also like to thank Alex Petrescu, Alice Qinxia, The authors would also like to thank Alex Petrescu, Alice Qinxia,
Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Charlie Perkins, Fred Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Charlie Perkins, Fred
 End of changes. 119 change blocks. 
205 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/