draft-ietf-netlmm-proxymip6-09.txt   draft-ietf-netlmm-proxymip6-10.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: August 6, 2008 V. Devarapalli Expires: August 12, 2008 V. Devarapalli
Azaire Networks Azaire Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
B. Patil B. Patil
Nokia Siemens Networks Nokia Siemens Networks
February 03, 2008 February 09, 2008
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-09.txt draft-ietf-netlmm-proxymip6-10.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 August 6, 2008. This Internet-Draft will expire on August 12, 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 35 skipping to change at page 2, line 35
5.3.1. Processing Binding Registrations . . . . . . . . . . . 18 5.3.1. Processing Binding Registrations . . . . . . . . . . . 18
5.3.2. Initial Binding Registration (New Mobility Session) . 20 5.3.2. Initial Binding Registration (New Mobility Session) . 20
5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 21 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 21
5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 22 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 22
5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 22 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 22
5.3.6. Constructing the Proxy Binding Acknowledgement 5.3.6. Constructing the Proxy Binding Acknowledgement
Message . . . . . . . . . . . . . . . . . . . . . . . 23 Message . . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 25 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 25
5.4.1. Binding Cache entry lookup considerations . . . . . . 26 5.4.1. Binding Cache entry lookup considerations . . . . . . 26
5.5. Timestamp Option for Message Ordering . . . . . . . . . . 31 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 31
5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 33 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 34
5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 33 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 34
5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 34 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 34
5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 35 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 35
5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 36 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 36
5.9. Route Optimizations Considerations . . . . . . . . . . . . 36 5.9. Route Optimizations Considerations . . . . . . . . . . . . 36
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 36 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 36
6.1. Extensions to Binding Update List Entry Data Structure . . 37 6.1. Extensions to Binding Update List Entry Data Structure . . 37
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 38 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 38
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 38 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 38
6.4. Supported Address Configuration Modes . . . . . . . . . . 39 6.4. Supported Address Configuration Modes . . . . . . . . . . 39
6.5. Access Authentication & Mobile Node Identification . . . . 39 6.5. Access Authentication & Mobile Node Identification . . . . 39
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 39 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 40
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 40 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 40
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 41 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 41
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 42 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 42
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 42 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 42
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 49 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 50
6.9.3. Default-Router Lifetime . . . . . . . . . . . . . . . 50 6.9.3. Default-Router Lifetime . . . . . . . . . . . . . . . 50
6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 51 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 52
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 52 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 52
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 52 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 53
6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 53 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 53
6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 53 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 54
6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 53 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 54
6.11. Supporting DHCPv6 based Address Configuration on the 6.11. Supporting DHCPv6 based Address Configuration on the
Access Link . . . . . . . . . . . . . . . . . . . . . . . 55 Access Link . . . . . . . . . . . . . . . . . . . . . . . 55
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 56 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 56
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 56 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 57
6.14. Allowing network access to other IPv6 nodes . . . . . . . 57 6.14. Allowing network access to other IPv6 nodes . . . . . . . 57
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 57 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 58
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 57 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 58
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 58 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 59
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 59 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 59
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 59 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 60
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 61 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 61
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 62 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 63
8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 63 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 64
8.5. Access Technology Type Option . . . . . . . . . . . . . . 64 8.5. Access Technology Type Option . . . . . . . . . . . . . . 65
8.6. Mobile Node Interface Identifier Option . . . . . . . . . 66 8.6. Mobile Node Interface Identifier Option . . . . . . . . . 67
8.7. Link-local Address Option . . . . . . . . . . . . . . . . 67 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 68
8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 67 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 68
8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 68 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 69
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 70 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 71
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
11. Security Considerations . . . . . . . . . . . . . . . . . . . 72 11. Security Considerations . . . . . . . . . . . . . . . . . . . 73
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . . 73 13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 74 13.2. Informative References . . . . . . . . . . . . . . . . . . 75
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 75 Infrastructure . . . . . . . . . . . . . . . . . . . 76
Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 75 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 76
Appendix C. Routing State . . . . . . . . . . . . . . . . . . . . 76 Appendix C. Routing State . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
Intellectual Property and Copyright Statements . . . . . . . . . . 79 Intellectual Property and Copyright Statements . . . . . . . . . . 80
1. Introduction 1. Introduction
IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775]. IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775].
Mobile IPv6 requires client functionality in the IPv6 stack of a Mobile IPv6 requires client functionality in the IPv6 stack of a
mobile node. Exchange of signaling messages between the mobile node mobile node. Exchange of signaling messages between the mobile node
and home agent enables the creation and maintenance of a binding and home agent enables the creation and maintenance of a binding
between the mobile node's home address and its care-of-address. between the mobile node's home address and its care-of-address.
Mobility as specified in [RFC-3775] requires the IP host to send IP Mobility as specified in [RFC-3775] requires the IP host to send IP
mobility management signaling messages to the home agent, which is mobility management signaling messages to the home agent, which is
skipping to change at page 18, line 37 skipping to change at page 18, line 37
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 Binding Registrations
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) MUST be authenticated as message with the 'P' flag set) MUST be authenticated as
described in Section 4.0. When IPsec is used for message described in Section 4. When IPsec is used for message
authentication, the SPI in the IPsec header [RFC-4306] of the authentication, the SPI in the IPsec header [RFC-4306] of the
received packet is needed for locating the security association, received packet is needed for locating the security association,
for authenticating the Proxy Binding Update message. for authenticating the Proxy 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 [RFC-3775] when processing Mobility Header in the Section 9.2 [RFC-3775] when processing Mobility Header in the
received Proxy Binding Update request. Additionally, the rules received Proxy Binding Update request. Additionally, the rules
specified in Section 10.3 [RFC-3775] MUST be applied when specified in Section 10.3 [RFC-3775] MUST be applied when
processing this message. processing this message.
skipping to change at page 19, line 18 skipping to change at page 19, line 18
4283] of the Proxy Binding Update request. If the Mobile Node 4283] of the Proxy Binding Update request. 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 request, 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.0, 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. requests 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 requests 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 registrations).
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 request, 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 133 (Not local mobility anchor message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE
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
skipping to change at page 25, line 45 skipping to change at page 25, line 45
o The local mobility anchor MUST manage each of the allocated home o The local mobility anchor MUST manage each of the allocated home
network prefixes as part of a separate mobility session, each network prefixes as part of a separate mobility session, each
under a separate Binding Cache entry and with its own lifetime. under a separate Binding Cache entry and with its own lifetime.
o The local mobility anchor MUST allow for an handoff between two o The local mobility anchor MUST allow for an handoff between two
different interfaces of the mobile node. In such a case, the home different interfaces of the mobile node. In such a case, the home
network prefix that is associated with a specific interface network prefix that is associated with a specific interface
identifier of a mobile node will be updated with the new interface identifier of a mobile node will be updated with the new interface
identifier. The decision on when to create a new mobility session identifier. The decision on when to create a new mobility session
and when to update an existing mobility session MUST be based on and when to update an existing mobility session MUST be based on
the Handover hint present in the signaling messages and under the the Handover hint present in the Proxy Binding Update message and
considerations specified in this section. under the considerations specified in this section.
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 request message, the local
mobility anchor MUST apply the following multihoming considerations mobility anchor MUST apply the following multihoming considerations
(in the specified order). These rules are chained with the (in the below specified order). These rules are chained with the
processing rules specified in Section 5.3. 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 |
+=====================================================================+ +=====================================================================+
| HNP (NON_ZERO Value) | | HNP (NON_ZERO Value) |
+=====================================================================+ +=====================================================================+
skipping to change at page 29, line 30 skipping to change at page 29, line 30
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 updating that Binding consider the request as a request for updating that Binding
Cache entry. The local mobility anchor MAY also choose to Cache entry. The local mobility anchor MAY also choose to
create a new mobility session and without waiting for a de- create a new mobility session and without waiting for a de-
registration message. registration message and this should be configurable on the
local mobility anchor.
5. For all other cases, the message MUST be considered as a request 5. For all other cases, the message MUST be considered as a request
for creating a new mobility session. for creating a new mobility session.
5.4.1.3. Mobile Node Interface Identifier Option not present in the 5.4.1.3. Mobile Node Interface Identifier Option not present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| HNP (ALL_ZERO Value) | | HNP (ALL_ZERO Value) |
+=====================================================================+ +=====================================================================+
| ATT | | ATT |
+=====================================================================+ +=====================================================================+
| IID Option Not Present | | IID Option Not Present |
+=====================================================================+ +=====================================================================+
| HI | | HI |
skipping to change at page 30, line 44 skipping to change at page 30, line 48
present in the request is set to a value of 4 (Handoff state present in the request is set to a value of 4 (Handoff state
unknown), the local mobility anchor SHOULD wait till the existing unknown), the local mobility anchor SHOULD wait till the existing
Binding Cache entry is de-registered by the previously serving Binding Cache entry is de-registered by the previously serving
mobile access gateway, before the request can be considered as a mobile access gateway, before the request can be considered as a
request for updating that Binding Cache entry. However, if there request for updating that Binding Cache entry. However, if there
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 updating that Binding Cache entry. The local request for updating that Binding Cache entry. The local
mobility anchor MAY also choose to create a new mobility session mobility anchor MAY also choose to create a new mobility session
and without waiting for a de-registration message. and without waiting for a de-registration message and this should
be configurable on the local mobility anchor.
4. For all other cases, the message MUST be considered as a request 4. For all other cases, the message MUST be considered as a request
for creating a new mobility session. for creating a new mobility session.
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
skipping to change at page 40, line 26 skipping to change at page 40, line 32
4372] may be used. 4372] may be used.
o The MN-Identifier that the policy store delivers to the mobile o The MN-Identifier that the policy store delivers to the mobile
access gateway may not be the true identifier of the mobile node. access gateway may not be the true identifier of the mobile node.
However, the mobility access gateway MUST be able to use this However, the mobility access gateway MUST be able to use this
identifier in the signaling messages exchanged with the local identifier in the signaling messages exchanged with the local
mobility anchor. mobility anchor.
o The mobile access gateway MUST be able to identify the mobile node o The mobile access gateway MUST be able to identify the mobile node
by its MN-Identifier and it MUST be able to associate this by its MN-Identifier and it MUST be able to associate this
identity to the point-to-point link sharing with the mobile node. identity to the point-to-point link shared with the mobile node.
6.7. Home Network Emulation 6.7. Home Network Emulation
One of the key functions of a mobile access gateway is to emulate the One of the key functions of a mobile access gateway is to emulate the
mobile node's home network on the access link. It must ensure, the mobile node's home network on the access link. It must ensure, the
mobile node believes it is still connected to its home link or on the mobile node believes it is still connected to its home link or on the
link where it obtained its initial address configuration after it link where it obtained its initial address configuration after it
moved into that Proxy Mobile IPv6 domain. moved into that Proxy Mobile IPv6 domain.
For emulating the mobile node's home link on the access link, the For emulating the mobile node's home link on the access link, the
skipping to change at page 42, line 41 skipping to change at page 42, line 46
or from other means, the mobile access gateway MAY choose to or from other means, the mobile access gateway MAY choose to
specify the same in the Home Network Prefix option for specify the same in the Home Network Prefix option for
requesting the local mobility anchor to allocate that prefix, requesting the local mobility anchor to allocate that prefix,
otherwise it MUST specify a value of ALL_ZERO. If the specified otherwise it MUST specify a value of ALL_ZERO. If the specified
value is ALL_ZERO, then the local mobility anchor will do the value is ALL_ZERO, then the local mobility anchor will do the
prefix assignment. prefix assignment.
4. The Handoff Indicator option MUST be present in the Proxy 4. The Handoff Indicator option MUST be present in the Proxy
Binding Update message. The Handoff Indicator field in the Binding Update message. The Handoff Indicator field in the
Handoff Indicator option MUST be set to a value indicating the Handoff Indicator option MUST be set to a value indicating the
handoff hint. The specific details on how the mobile access handoff hint.
gateway determines if the mobile node's current attachment is
due to an handoff of an existing mobility session or if it is as
a result of an attachment over a different interface is outside
the scope of this document.
* The Handoff Indicator field MUST be set to value 1 * The Handoff Indicator field MUST be set to value 1
(Attachment over a new interface), if the mobile access (Attachment over a new interface), if the mobile access
gateway predictably knows that the mobile node's current gateway predictably knows that the mobile node's current
attachment to the network over this interface is not as a attachment to the network over this interface is not as a
result of an handoff of an existing mobility session (over result of an handoff of an existing mobility session (over
the same interface or through a different interface), but as the same interface or through a different interface), but as
a result of an attachment over a new interface. This a result of an attachment over a new interface. This
essentially serves as a request to the local mobility anchor essentially serves as a request to the local mobility anchor
to create a new mobility session and not update any existing to create a new mobility session and not update any existing
skipping to change at page 43, line 31 skipping to change at page 43, line 32
the mobile access gateway definitively knows the mobile the mobile access gateway definitively knows the mobile
node's current attachment is due to an handoff of an existing node's current attachment is due to an handoff of an existing
mobility session between two mobile access gateways and for mobility session between two mobile access gateways and for
the same interface of the mobile node. the same interface of the mobile node.
* The Handoff Indicator field MUST be set to value 4 (Handoff * The Handoff Indicator field MUST be set to value 4 (Handoff
state unknown), if the mobile access gateway cannot determine state unknown), if the mobile access gateway cannot determine
if the mobile node's current attachment is due to an handoff if the mobile node's current attachment is due to an handoff
of an existing mobility session. of an existing mobility session.
5. Either the Timestamp option or a valid sequence number 5. The mobile access gateway MUST apply the below considerations
when choosing the value for the Handoff Indicator field.
* The mobile access gateway can choose to use the value 2
(Handoff between two different interfaces of the mobile
node), only when it knows that the mobile node has on purpose
switched from one interface to another, and the previous
interface is going to be disabled. It may know this due to a
number of factors. For instance, most cellular networks have
controlled handovers where the network knows that the host is
moving from one attachment to another. In this situation the
link layer mechanism can inform the mobility functions that
this is indeed a movement, not a new attachment.
* Some link layers have interface identifiers that can be used
to distinguish (a) the movement of a particular interface to
a new attachment from (b) the attachment of new interface
from the same host. Option value 3 (Handoff between mobile
access gateways for the same interface)is appropriate in case
a and value of 1 (Attachment over a new interface) in case b.
* The mobile access gateway MUST NOT set the option value to 2
(Handoff between two different interfaces of the mobile node)
or 3 (Handoff between mobile access gateways for the same
interface) if it can not be determined that the mobile node
can move the address between the interfaces involved in the
handover or that it is the same interface that has moved.
Otherwise Proxy Mobile IPv6-unaware hosts that have multiple
physical interfaces to the same domain may suffer unexpected
failures.
* Where no support from link-layer exists, the host and the
network would need to inform each other about the intended
movement. Proxy Mobile IPv6 protocol does not specify this
and simply requires that knowledge about movements can be
derived either from the link-layer or from somewhere else.
The method by which this is accomplished is outside the scope
of this specification.
6. Either the Timestamp option or a valid sequence number
maintained on a per mobile node basis (if Sequence Number based maintained on a per mobile node basis (if Sequence Number based
scheme is in use) MUST be present. When Timestamp option is scheme is in use) MUST be present. When Timestamp option is
added to the message, the mobile access gateway SHOULD also set added to the message, the mobile access gateway SHOULD also set
the Sequence Number field to a value of a monotonically the Sequence Number field to a value of a monotonically
increasing counter (not to be confused with the per mobile node increasing counter (not to be confused with the per mobile node
sequence number specified [RFC-3775]). The local mobility sequence number specified [RFC-3775]). The local mobility
anchor will ignore this field when there is a Timestamp option anchor will ignore this field when there is a Timestamp option
present in the request, but will return the same value in the present in the request, but will return the same value in the
Proxy Binding Acknowledgement message. This will be useful for Proxy Binding Acknowledgement message. This will be useful for
matching the reply to the request message. matching the reply to the request message.
6. The Mobile Node Interface Identifier option carrying the 7. The Mobile Node Interface Identifier option carrying the
interface identifier of the currently attached interface MUST be interface 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 knows the interface identifier of the mobile access gateway knows the interface identifier of the mobile
node's currently attached interface. If the interface node's currently attached interface. If the interface
identifier is not known or if the identifier value is ALL_ZERO, identifier is not known or if the identifier value is ALL_ZERO,
this option MUST NOT be present. this option MUST NOT be present.
7. 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 using
which the mobile node is currently attached to the mobile access which the mobile node is currently attached to the mobile access
gateway. gateway.
8. The Link-local Address option MAY be present in the Proxy 9. The Link-local Address option MAY be present in the Proxy
Binding Update message. Considerations from Section 6.8 MUST be Binding Update message. Considerations from Section 6.8 MUST be
applied when using the link-local address option. applied when using the link-local address option.
* When uploading the link-local address to the local mobility * When uploading the link-local address to the local mobility
anchor, the value in the option MUST be set to the link-local anchor, the value in the option MUST be set to the link-local
address that is configured on the currently attached address that is configured on the currently attached
interface of the mobile node. interface of the mobile node.
* When querying the local mobility anchor for the mobile node's * When querying the local mobility anchor for the mobile node's
link-local address, the option MUST be set to ALL_ZERO value. link-local address, the option MUST be set to ALL_ZERO value.
This essentially serves as a request to the local mobility This essentially serves as a request to the local mobility
anchor to return the link-local address of the mobile node anchor to return the link-local address of the mobile node
from the binding cache entry corresponding to this mobility from the binding cache entry corresponding to this mobility
session. session.
9. 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.
10. 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 request.
6.9.1.2. Receiving Binding Registration Reply 6.9.1.2. Receiving Binding Registration Reply
On receiving a Proxy Binding Acknowledgement message from the local On receiving a Proxy Binding Acknowledgement message from the local
mobility anchor, the mobile access gateway MUST process the message mobility anchor, the mobile access gateway MUST process the message
as specified below. 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) MUST be Acknowledgement message with the 'P' flag set) MUST be
authenticated as described in Section 4.0. When IPsec is used authenticated as described in Section 4. When IPsec is used for
for message authentication, the SPI in the IPsec header [RFC- message authentication, the SPI in the IPsec header [RFC-4306]
4306] of the received packet is needed for locating the security of the received packet is needed for locating the security
association, for authenticating the Proxy Binding association, for authenticating the Proxy Binding
Acknowledgement message . Acknowledgement message .
2. The mobile access gateway MUST observe the rules described in 2. The mobile access gateway MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Headers in the Section 9.2 [RFC-3775] when processing Mobility Headers in the
received Proxy Binding Acknowledgement message. received Proxy Binding Acknowledgement message.
3. The mobile access gateway MUST apply the considerations 3. The mobile access gateway 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 message. field and the Timestamp option (if present), in the message.
skipping to change at page 45, line 35 skipping to change at page 46, 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 Interface Identifier Access Technology Type option, Mobile Node Interface 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. values in the reply message. Further, the mobile access gateway
MUST NOT retransmit the Proxy Binding Update message 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 binding registration requests again for
that mobile node. It MUST deny the mobility service to that that mobile node. It MUST deny the mobility service to that
mobile node. 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
skipping to change at page 50, line 7 skipping to change at page 50, line 42
2. If the local mobility anchor rejects the binding registration 2. If the local mobility anchor rejects the binding registration
request, or, if the mobile access gateway failed to complete the request, or, if the mobile access gateway failed to complete the
binding registration process for whatever reasons, the mobile binding registration process for whatever reasons, 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 in the Router Advertisement messages that it sends on the prefix in the Router Advertisement messages that it sends on the
access link. However, it MAY choose to advertise a local visited access link. However, it MAY choose to advertise a local visited
network prefix to enable the mobile node for regular IPv6 access. network prefix to enable the mobile node for regular IPv6 access.
6.9.3. Default-Router Lifetime 6.9.3. Default-Router Lifetime
This section is a non-normative section and only provides some
general guidance to implementations.
In Proxy Mobile IPv6, the mobile access gateway is typically the IPv6 In Proxy Mobile IPv6, the mobile access gateway is typically the IPv6
default-router for the mobile node on the access link, as it is the default-router for the mobile node on the access link, as it is the
entity that sends the Router Advertisements on the access link. entity that sends the Router Advertisements on the access link.
However, as the mobile node moves from one access link to another, However, as the mobile node moves from one access link to another,
the serving mobile access gateway on those respective links will send the serving mobile access gateway on those respective links will send
the Router Advertisements and using their own link-local address. the Router Advertisements and using their own link-local address.
The mobile node on each of the attached links will receive Router The mobile node on each of the attached links will receive Router
Advertisement messages with a different source address and this makes Advertisement messages with a different source address and this makes
the mobile node believe that there is a new default-router on that the mobile node believe that there is a new default-router on that
access link. access link.
skipping to change at page 69, line 9 skipping to change at page 70, line 9
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 request 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: PROXY_REG_NOT_ENABLED:
Proxy registration not enabled for the mobile node Proxy registration not enabled for the mobile node
NOT_LMA_FOR_THIS_MOBILE_NODE:
Not local mobility anchor for this mobile node
MAG_NOT_AUTHORIZED_FOR_PROXY_REG: MAG_NOT_AUTHORIZED_FOR_PROXY_REG:
The mobile access gateway is not authorized to send proxy binding The mobile access gateway is not authorized to send proxy binding
registrations registrations
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
The mobile node is not authorized for the requesting home network The mobile node is not authorized for the requesting home network
prefix prefix
skipping to change at page 70, line 14 skipping to change at page 71, line 17
also be used in Proxy Binding Acknowledgement message. also be used in 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
133 Not local mobility anchor for this mobile node
9. Protocol Configuration Variables 9. Protocol Configuration Variables
The local mobility anchor MUST allow the following variables to be The local mobility anchor MUST allow the following variables to be
configured by the system management. configured by the system management.
MinDelayBeforeBCEDelete MinDelayBeforeBCEDelete
This variable specifies the amount of time in milliseconds the This variable specifies the amount of time in milliseconds the
local mobility anchor MUST wait before it deletes a Binding Cache local mobility anchor MUST wait before it deletes a Binding Cache
entry of a mobile node, upon receiving a Proxy Binding Update entry of a mobile node, upon receiving a Proxy Binding Update
 End of changes. 36 change blocks. 
66 lines changed or deleted 105 lines changed or added

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