draft-ietf-netlmm-proxymip6-16.txt   draft-ietf-netlmm-proxymip6-17.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 22, 2008 V. Devarapalli Expires: November 28, 2008 V. Devarapalli
Wichorus Wichorus
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
B. Patil B. Patil
Nokia Siemens Networks Nokia Siemens Networks
May 21, 2008 May 27, 2008
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-16.txt draft-ietf-netlmm-proxymip6-17.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 22, 2008. This Internet-Draft will expire on November 28, 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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 17 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 Binding Registrations . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . 33 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 34
5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 36 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 37
5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 36 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 37
5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 37 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 38
5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels . . . 38 5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels . . . 39
5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 39 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 40
5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 39 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 40
5.9. Route Optimization Considerations . . . . . . . . . . . . 40 5.9. Route Optimization Considerations . . . . . . . . . . . . 41
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 40 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 41
6.1. Extensions to Binding Update List Entry Data Structure . . 41 6.1. Extensions to Binding Update List Entry Data Structure . . 42
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 42 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 43
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 42 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 44
6.4. Supported Address Configuration Modes . . . . . . . . . . 43 6.4. Supported Address Configuration Modes . . . . . . . . . . 44
6.5. Access Authentication & Mobile Node Identification . . . . 44 6.5. Access Authentication & Mobile Node Identification . . . . 45
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 44 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 45
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 45 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 46
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 45 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 46
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 46 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 48
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 46 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 48
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 55 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 56
6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 56 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 57
6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 56 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 58
6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 57 6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 59
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 58 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 60
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 59 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 60
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 59 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 60
6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 60 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 61
6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 60 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 62
6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 60 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 62
6.11. Supporting DHCP based Address Configuration on the 6.11. Supporting DHCP based Address Configuration on the
Access Link . . . . . . . . . . . . . . . . . . . . . . . 62 Access Link . . . . . . . . . . . . . . . . . . . . . . . 64
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 64 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 66
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 64 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 66
6.14. Allowing network access to other IPv6 nodes . . . . . . . 65 6.14. Allowing network access to other IPv6 nodes . . . . . . . 67
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 66 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 67
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 66 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 67
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 67 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 68
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 67 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 69
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 68 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 69
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 69 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 71
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 71 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 72
8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 72 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 73
8.5. Access Technology Type Option . . . . . . . . . . . . . . 73 8.5. Access Technology Type Option . . . . . . . . . . . . . . 74
8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 75 8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 76
8.7. Link-local Address Option . . . . . . . . . . . . . . . . 76 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 77
8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 77 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 78
8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 77 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 78
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 79 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 80
9.1. Local Mobility Anchor - Configuration Variables . . . . . 79 9.1. Local Mobility Anchor - Configuration Variables . . . . . 80
9.2. Mobile Access Gateway - Configuration Variables . . . . . 80 9.2. Mobile Access Gateway - Configuration Variables . . . . . 81
9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 81 9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 82
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
11. Security Considerations . . . . . . . . . . . . . . . . . . . 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 84
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 85
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.1. Normative References . . . . . . . . . . . . . . . . . . . 84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 85
13.2. Informative References . . . . . . . . . . . . . . . . . . 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 86
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 86 Infrastructure . . . . . . . . . . . . . . . . . . . 87
Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 86 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89
Intellectual Property and Copyright Statements . . . . . . . . . . 89 Intellectual Property and Copyright Statements . . . . . . . . . . 91
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 5, line 45 skipping to change at page 5, line 45
Proxy Mobile IPv6 domain. It is the topological anchor point for Proxy Mobile IPv6 domain. It is the topological anchor point for
the mobile node's home network prefix(es) and is the entity that the mobile node's home network prefix(es) and is the entity that
manages the mobile node's binding state. The local mobility manages the mobile node's binding state. The local mobility
anchor has the functional capabilities of a home agent as defined anchor has the functional capabilities of a home agent as defined
in Mobile IPv6 base specification [RFC-3775] with the additional in Mobile IPv6 base specification [RFC-3775] with the additional
capabilities required for supporting Proxy Mobile IPv6 protocol as capabilities required for supporting Proxy Mobile IPv6 protocol as
defined in this specification. defined in this specification.
Mobile Access Gateway (MAG) Mobile Access Gateway (MAG)
Mobile Access Gateway is a function that manages the mobility Mobile Access Gateway is a function on an access router that
related signaling for a mobile node that is attached to its access manages the mobility related signaling for a mobile node that is
link. It is responsible for tracking the mobile node's movements attached to its access link. It is responsible for tracking the
to and from the access link and for signaling the mobile node's mobile node's movements to and from the access link and for
local mobility anchor. signaling the mobile node's local mobility anchor.
Mobile Node (MN) Mobile Node (MN)
Throughout this document, the term mobile node is used to refer to Throughout this document, the term mobile node is used to refer to
an IP host or router whose mobility is managed by the network. an IP host or router whose mobility is managed by the network.
The mobile node may be an IPv4-only node, IPv6-only node or a The mobile node may be an IPv4-only node, IPv6-only node or a
dual-stack node and is not required to participate in any IP dual-stack node and is not required to participate in any IP
mobility related signaling for achieving mobility for an IP mobility related signaling for achieving mobility for an IP
address that is obtained in that Proxy Mobile IPv6 domain. address that is obtained in that Proxy Mobile IPv6 domain.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
directional tunnel established between the local mobility anchor directional tunnel established between the local mobility anchor
and the mobile access gateway. This is the address to where the and the mobile access gateway. This is the address to where the
mobile access gateway sends the Proxy Binding Update messages. mobile access gateway sends the Proxy Binding Update messages.
When supporting IPv4 traversal, i.e., when the network between the When supporting IPv4 traversal, i.e., when the network between the
local mobility anchor and the mobile access gateway is an IPv4 local mobility anchor and the mobile access gateway is an IPv4
network, this address will be an IPv4 address and will be referred network, this address will be an IPv4 address and will be referred
to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6]. to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6].
Proxy Care-of Address (Proxy-CoA) Proxy Care-of Address (Proxy-CoA)
Proxy-CoA is the global address configured on the interface of the Proxy-CoA is the global address configured on the egress interface
mobile access gateway and is the transport endpoint of the tunnel of the mobile access gateway and is the transport endpoint of the
between the local mobility anchor and the mobile access gateway. tunnel between the local mobility anchor and the mobile access
The local mobility anchor views this address as the Care-of gateway. The local mobility anchor views this address as the
Address of the mobile node and registers it in the Binding Cache Care-of Address of the mobile node and registers it in the Binding
entry for that mobile node. When the transport network between Cache entry for that mobile node. When the transport network
the mobile access gateway and the local mobility anchor is an IPv4 between the mobile access gateway and the local mobility anchor is
network and if the care-of address that is registered at the local an IPv4 network and if the care-of address that is registered at
mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is the local mobility anchor is an IPv4 address, the term, IPv4-
used, as specified in [ID-IPV4-PMIP6]. Proxy-CoA is used, as specified in [ID-IPV4-PMIP6].
Mobile Node's Home Network Prefix (MN-HNP) Mobile Node's Home Network Prefix (MN-HNP)
The MN-HNP is a prefix assigned to the link between the mobile The MN-HNP is a prefix assigned to the link between the mobile
node and the mobile access gateway. More than one prefix can be node and the mobile access gateway. More than one prefix can be
assigned to the link between the mobile node and the mobile access assigned to the link between the mobile node and the mobile access
gateway, in which case, all of the assigned prefixes are managed gateway, in which case, all of the assigned prefixes are managed
as a set associated with a mobility session. The mobile node as a set associated with a mobility session. The mobile node
configures its interface with one or more addresses from its home configures its interface with one or more addresses from its home
network prefix(es). If the mobile node connects to the Proxy network prefix(es). If the mobile node connects to the Proxy
Mobile IPv6 domain through multiple interfaces, simultaneously, Mobile IPv6 domain through multiple interfaces, simultaneously,
each of the attached interfaces will be assigned a unique set of each of the attached interfaces will be assigned a unique set of
home network prefixes and all the prefixes assigned to a given home network prefixes and all the prefixes assigned to a given
interface of a mobile node will be managed under one mobility interface of a mobile node will be managed under one mobility
session. Additionally, in some configurations the assigned prefix session. Ex: Home network prefixes P1, P2 assigned to interface
can be of 128-bit prefix length. Ex: Home network prefixes P1, P2 I1 will be managed under one mobility session and prefixes P3, P4,
assigned to interface I1 will be managed under one mobility P5 assigned to interface I2 of the mobile node will be managed
session and prefixes P3, P4, P5 assigned to interface I2 of the under a different mobility session. Additionally, in some
mobile node will be managed under a different mobility session. configurations the assigned prefix can be of 128-bit prefix
length.
Mobile Node's Home Address (MN-HoA) Mobile Node's Home Address (MN-HoA)
MN-HoA is an address from a mobile node's home network prefix. MN-HoA is an address from a mobile node's home network prefix.
The mobile node will be able to use this address as long as it is The mobile node will be able to use this address as long as it is
attached to the access network that is in the scope of that Proxy attached to the access network that is in the scope of that Proxy
Mobile IPv6 domain. If the mobile node uses more than one address Mobile IPv6 domain. If the mobile node uses more than one address
from its home network prefix(es), any one of these addresses is from its home network prefix(es), any one of these addresses is
referred to as mobile node's home address. Unlike in Mobile IPv6 referred to as mobile node's home address. Unlike in Mobile IPv6
where the home agent is aware of the home address of the mobile where the home agent is aware of the home address of the mobile
skipping to change at page 8, line 15 skipping to change at page 8, line 15
Mobile Node Link-layer Identifier (MN-LL-Identifier) Mobile Node Link-layer Identifier (MN-LL-Identifier)
An identifier that identifies the attached interface of a mobile An identifier that identifies the attached interface of a mobile
node. For those interfaces that have a link-layer identifier, node. For those interfaces that have a link-layer identifier,
this identifier can be based on that. The link-layer identifier this identifier can be based on that. The link-layer identifier
in some cases is generated by the mobile node and conveyed to the in some cases is generated by the mobile node and conveyed to the
mobile access gateway. This identifier of the attached interface mobile access gateway. This identifier of the attached interface
must be stable as seen by any of the mobile access gateways in a must be stable as seen by any of the mobile access gateways in a
given Proxy Mobile IPv6 domain. In some other cases, there might given Proxy Mobile IPv6 domain. In some other cases, there might
not be any link-layer identifier associated with the mobile node's not be any link-layer identifier associated with the mobile node's
interface. interface. An identifier value of ALL_ZERO is not considered a
valid identifier and cannot be used as an interface identifier.
Policy Profile Policy Profile
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.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
The core functional entities in the NETLMM infrastructure are the The core functional entities in the NETLMM infrastructure are the
Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The
local mobility anchor is responsible for maintaining the mobile local mobility anchor is responsible for maintaining the mobile
node's reachability state and is the topological anchor point for the node's reachability state and is the topological anchor point for the
mobile node's home network prefix(es). The mobile access gateway is mobile node's home network prefix(es). The mobile access gateway is
the entity that performs the mobility management on behalf of a the entity that performs the mobility management on behalf of a
mobile node and it resides on the access link where the mobile node mobile node and it resides on the access link where the mobile node
is anchored. The mobile access gateway is responsible for detecting is anchored. The mobile access gateway is responsible for detecting
the mobile node's movements to and from the access link and for the mobile node's movements to and from the access link and for
initiating binding registrations to the mobile node's local mobility initiating binding registrations to the mobile node's local mobility
anchor. The architecture of a Proxy Mobile IPv6 domain is shown in anchor. There can be multiple local mobility anchors in a Proxy
Figure 1. Mobile IPv6 domain each serving a different group of mobile nodes.
The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
LMAA1 -> | | <-- LMAA2 LMAA1 -> | | <-- LMAA2
| | | |
\\ //\\ \\ //\\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
skipping to change at page 10, line 44 skipping to change at page 10, line 44
mobility management service. mobility management service.
If the network determines that the network-based mobility management If the network determines that the network-based mobility management
service needs to be offered to that mobile node, the network will service needs to be offered to that mobile node, the network will
ensure that the mobile node using any of the address configuration ensure that the mobile node using any of the address configuration
mechanisms permitted by the network will be able to obtain the mechanisms permitted by the network will be able to obtain the
address configuration on the connected interface and move anywhere in address configuration on the connected interface and move anywhere in
that Proxy Mobile IPv6 domain. The obtained address configuration that Proxy Mobile IPv6 domain. The obtained address configuration
includes the address(es) from its home network prefix(es), the includes the address(es) from its home network prefix(es), the
default-router address on the link and other related configuration default-router address on the link and other related configuration
parameters. From the perspective of the mobile node, the entire parameters. From the perspective of each mobile node, the entire
Proxy Mobile IPv6 domain appears as a single link, the network Proxy Mobile IPv6 domain appears as a single link, the network
ensures that the mobile node does not detect any change with respect ensures that the mobile node does not detect any change with respect
to its layer-3 attachment even after changing its point of attachment to its layer-3 attachment even after changing its point of attachment
in the network. in the network.
The mobile node may be an IPv4-only node, IPv6-only node or a dual The mobile node may be an IPv4-only node, IPv6-only node or a dual
IPv4/IPv6 node. Based on what is enabled in the network for that IPv4/IPv6 node. Based on what is enabled in the network for that
mobile node, the mobile node will be able to obtain an IPv4, IPv6 or mobile node, the mobile node will be able to obtain an IPv4, IPv6 or
dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6 dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6
domain. However this specification only supports IPv6 address domain. However this specification only supports IPv6 address
mobility and when the transport network is IPv6 network. The support mobility and when the transport network is IPv6 network. The support
for IPv4 addressing or IPv4 transport network is specified in the for IPv4 addressing or IPv4 transport network is specified in the
companion document [ID-IPV4-PMIP6]. companion document [ID-IPV4-PMIP6].
If the mobile node connects to the Proxy Mobile IPv6 domain through If the mobile node connects to the Proxy Mobile IPv6 domain through
multiple interfaces and over multiple access networks, the network multiple interfaces and over multiple access networks, the network
will allocate a unique set of home network prefixes for each of the will allocate a unique set of home network prefixes for each of the
connected interfaces. The mobile node will be able to configure connected interfaces. The mobile node will be able to configure
address(es) on those interfaces from the respective home network address(es) on those interfaces from the respective home network
prefix(es). However, if the mobile node performs an inter-interface prefix(es). However, if the mobile node performs an handoff by
handoff by moving its address configuration from one interface to the moving its address configuration from one interface to the other and
other and if the local mobility anchor receives a handoff hint from if the local mobility anchor receives a handoff hint from the serving
the serving mobile access gateway about the same, the local mobility mobile access gateway about the same, the local mobility anchor will
anchor will assign the same home network prefix(es) that it assign the same home network prefix(es) that it previously assigned
previously assigned prior to the handoff. The mobile node will also prior to the handoff. The mobile node will also be able to perform
be able to perform an handoff by changing its point of attachment an handoff by changing its point of attachment from one mobile access
from one mobile access gateway to a different mobile access gateway gateway to a different mobile access gateway using the same interface
using the same interface and will be able to retain the address and will be able to retain the address configuration on the attached
configuration on the attached interface. interface.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | MN | | MAG | | LMA |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
MN Attached | | MN Attached | |
| | | | | |
| MN Attached Event from MN/Network | | MN Attached Event from MN/Network |
| (Acquire MN-Id and Profile) | | (Acquire MN-Id and Profile) |
| | | | | |
skipping to change at page 13, line 8 skipping to change at page 13, line 8
the mobile node, the mobile access gateway sends a Proxy Binding the mobile node, the mobile access gateway sends a Proxy Binding
Update message to the mobile node's local mobility anchor. Upon Update message to the mobile node's local mobility anchor. Upon
accepting this Proxy Binding Update message, the local mobility accepting this Proxy Binding Update message, the local mobility
anchor sends a Proxy Binding Acknowledgement message including the anchor sends a Proxy Binding Acknowledgement message including the
mobile node's home network prefix(es). It also creates the Binding mobile node's home network prefix(es). It also creates the Binding
Cache entry and sets up its endpoint of the bi-directional tunnel to Cache entry and sets up its endpoint of the bi-directional tunnel to
the mobile access gateway. the mobile access gateway.
The mobile access gateway on receiving the Proxy Binding The mobile access gateway on receiving the Proxy Binding
Acknowledgement message sets up its endpoint of the bi-directional Acknowledgement message sets up its endpoint of the bi-directional
tunnel to the local mobility anchor and also sets up the data path tunnel to the local mobility anchor and also sets up the forwarding
for the mobile node's traffic. At this point the mobile access for the mobile node's traffic. At this point the mobile access
gateway will have all the required information for emulating the gateway will have all the required information for emulating the
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. At the end of a successful that are permitted on that access link as indicated in Router
address configuration procedure, the mobile node will end up with one Advertisement messages. At the end of a successful address
or more addresses from its home network prefixes(es). configuration procedure, the mobile node will end up with one or more
addresses from its home network prefixes(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
sent to the mobile node by any node in the network. The local sent to the mobile node by any node in or outside the Proxy Mobile
mobility anchor forwards these received packets to the mobile access IPv6 domain. The local mobility anchor forwards these received
gateway through the bi-directional tunnel. The mobile access gateway packets to the mobile access gateway through the bi-directional
on other end of the tunnel, after receiving the packet, removes the tunnel. The mobile access gateway on other end of the tunnel, after
outer header and forwards the packet on the access link to the mobile receiving the packet, removes the outer header and forwards the
node. However, in some cases the traffic sent from a correspondent packet on the access link to the mobile node. However, in some cases
node that is locally connected to the mobile access gateway may not the traffic sent from a correspondent node that is locally connected
be received by the local mobility anchor and may be routed locally by to the mobile access gateway may not be received by the local
the mobile access gateway. mobility anchor and may be routed locally by the mobile access
gateway (Refer to Section 6.10.3).
The mobile access gateway acts as the default router on the access The mobile access gateway acts as the default router on the point-to-
link. Any packet that the mobile node sends to any correspondent point link shared with the mobile node. Any packet that the mobile
node will be received by the mobile access gateway and will be sent node sends to any correspondent node will be received by the mobile
to its local mobility anchor through the bi-directional tunnel. The access gateway and will be sent to its local mobility anchor through
local mobility anchor on the other end of the tunnel, after receiving the bi-directional tunnel. The local mobility anchor on the other
the packet, removes the outer header and routes the packet to the end of the tunnel, after receiving the packet, removes the outer
destination. However in some cases the traffic sent to a header and routes the packet to the destination. However in some
correspondent node that is locally connected to the mobile access cases the traffic sent to a correspondent node that is locally
gateway may be locally routed by the mobile access gateway. connected to the mobile access gateway may be locally routed by the
mobile access gateway (Refer to Section 6.10.3).
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | |p-MAG| | LMA | |n-MAG| | MN | |p-MAG| | LMA | |n-MAG|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | |
| |==Bi-Dir Tunnel=| | | |==Bi-Dir Tunnel=| |
MN Detached | | | MN Detached | | |
| MN Detached Event | | | MN Detached Event | |
| | | | | | | |
| |-- DeReg PBU -->| | | |-- DeReg PBU -->| |
skipping to change at page 16, line 37 skipping to change at page 16, line 41
4.1. Peer Authorization Database (PAD) Example Entries 4.1. Peer Authorization Database (PAD) Example Entries
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
is assumed to lma_identity_1 and the identity of the mobile access
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_SA 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)
and authorize CHILD_SAs for remote address mag_address_1 and authorize CHILD_SAs for remote address mag_address_1
Figure 4: PAD Entries Figure 4: PAD Entries
The list of authentication mechanisms in the above examples is not The list of authentication mechanisms in the above examples is not
exhaustive. There could be other credentials used for authentication exhaustive. There could be other credentials used for authentication
skipping to change at page 17, line 16 skipping to change at page 17, line 30
4.2. Security Policy Database (SPD) Example Entries 4.2. Security Policy Database (SPD) Example Entries
This section describes the security policy entries [RFC-4301] on the This section describes the security policy entries [RFC-4301] on the
mobile access gateway and the local mobility anchor required to mobile access gateway and the local mobility anchor required to
protect the Proxy Mobile IPv6 signaling messages. The SPD entries protect the Proxy Mobile IPv6 signaling messages. The SPD entries
are only example configurations. A particular mobile access gateway are only example configurations. A particular mobile access gateway
or a local mobility anchor implementation could configure different or a local mobility anchor implementation could configure different
SPD entries as long as they provide the required security. SPD entries as long as they provide the required security.
In the examples shown below, the identity of the mobile access In the example shown below, the identity of the mobile access gateway
gateway is assumed to be mag_1, the address of the mobile access is assumed to be mag_identity_1, the address of the mobile access
gateway is assumed to be mag_address_1, and the address of the local gateway is assumed to be mag_address_1, and the address of the local
mobility anchor is assumed to be lma_address_1. mobility anchor is assumed to be lma_address_1. The acronym MH
represents the protocol number for the Mobility Header [RFC-3775];
while the terms local_mh_type and remote_mh_type stand for local
mobility header type and remote mobility header type respectively.
mobile access gateway SPD-S: mobile access gateway SPD-S:
- IF local_address = mag_address_1 & - IF local_address = mag_address_1 &
remote_address = lma_address_1 & remote_address = lma_address_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BA proto = MH & (local_mh_type = BU | remote_mh_type = BA)
Then use SA ESP transport mode Then use SA ESP transport mode
Initiate using IDi = mag_1 to address lma_address_1 Initiate using IDi = mag_identity_1 to address lma_address_1
local mobility anchor SPD-S: local mobility anchor SPD-S:
- IF local_address = lma_address_1 & - IF local_address = lma_address_1 &
remote_address = mag_address_1 & remote_address = mag_address_1 &
proto = MH & local_mh_type = BA & remote_mh_type = BU proto = MH & (local_mh_type = BA | remote_mh_type = BU)
Then use SA ESP transport mode Then use SA ESP transport mode
Figure 5: SPD Entries Figure 5: SPD Entries
5. Local Mobility Anchor Operation 5. Local Mobility Anchor Operation
The local mobility anchor MUST support the home agent function as The local mobility anchor MUST support the home agent function as
defined in [RFC-3775] and additionally the extensions defined in this defined in [RFC-3775] and additionally the extensions defined in this
specification. A home agent with these modifications and enhanced specification. A home agent with these modifications and enhanced
capabilities for supporting the Proxy Mobile IPv6 protocol is capabilities for supporting the Proxy Mobile IPv6 protocol is
referred to as a local mobility anchor. referred to as a local mobility anchor.
skipping to change at page 18, line 8 skipping to change at page 18, line 20
specification. A home agent with these modifications and enhanced specification. A home agent with these modifications and enhanced
capabilities for supporting the Proxy Mobile IPv6 protocol is capabilities for supporting the Proxy Mobile IPv6 protocol is
referred to as a local mobility anchor. referred to as a local mobility anchor.
This section describes the operational details of the local mobility This section describes the operational details of the local mobility
anchor. anchor.
5.1. Extensions to Binding Cache Entry Data Structure 5.1. Extensions to Binding Cache Entry Data Structure
Every local mobility anchor MUST maintain a Binding Cache entry for Every local mobility anchor MUST maintain a Binding Cache entry for
each currently registered mobile node. Binding Cache entry is a each currently registered mobile node. A Binding Cache entry is a
conceptual data structure, described in Section 9.1 of [RFC-3775]. conceptual data structure, described in Section 9.1 of [RFC-3775].
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.
skipping to change at page 18, line 42 skipping to change at page 19, line 8
the local mobility anchor after accepting the initial Proxy the local mobility anchor after accepting the initial Proxy
Binding Update request. Binding Update request.
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 (If-Id) of the bi-directional o The tunnel interface identifier (tunnel-if-id) of the bi-
tunnel between the local mobility anchor and the mobile access directional tunnel between the local mobility anchor and the
gateway where the mobile node is currently anchored. This is mobile access gateway where the mobile node is currently anchored.
internal to the local mobility anchor. The tunnel interface This is internal to the local mobility anchor. The tunnel
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, using which the mobile node is
currently attached. This is obtained from the Access Technology currently attached. This is obtained from the Access Technology
Type option, present in the Proxy Binding Update request. Type option, present in the Proxy Binding Update request.
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 request 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 request (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 is the key for locating a Binding Cache entry in its mobility session may be used as a key for locating its Binding
all cases except when there has been an handoff of the mobile node's Cache entry in all cases except when there has been an handoff of the
session to a new mobile access gateway and that mobile access gateway mobile node's session to a new mobile access gateway and that mobile
is unaware of the home network prefix(es) assigned to that mobility access gateway is unaware of the home network prefix(es) assigned to
session. In such handoff cases, the Binding Cache entry can be that mobility session. In such handoff cases, the Binding Cache
located under the considerations specified in Section 5.4.1. entry can be located under the considerations specified in Section
5.4.1.
5.2. Supported Home Network Prefix Models 5.2. Supported Home Network Prefix Models
This specification supports the Per-MN-Prefix model and does not This specification supports the Per-MN-Prefix model and does not
support the Shared-Prefix model. As per the Per-MN-Prefix model, support the Shared-Prefix model. According to the Per-MN-Prefix
home network prefix(es) assigned to a mobile node are for that mobile model, home network prefix(es) assigned to a mobile node are for that
node's exclusive use and no other node shares an address from that mobile node's exclusive use and no other node shares an address from
prefix (other than the Subnet-Router anycast address [RFC-4291] which that prefix (other than the Subnet-Router anycast address [RFC-4291]
is used by the mobile access gateway hosting that prefix on that which is used by the mobile access gateway hosting that prefix on
link). that link).
There may be more than one prefix assigned to a given interface of There may be more than one prefix assigned to a given interface of
the mobile node and all of those assigned prefixes are unique to that the mobile node; all of those assigned prefixes MUST be unique to
mobile node and all are part of one mobility session. If the mobile that mobile node and all are part of exactly one mobility session.
node attaches to the Proxy Mobile IPv6 domain through multiple If the mobile node simultaneously attaches to the Proxy Mobile IPv6
interfaces and simultaneously, each of the attached interfaces will domain through multiple interfaces, each of the attached interfaces
be assigned one or more unique prefixes and all of the assigned MUST be assigned one or more unique prefixes. Prefixes that are not
prefixes to a given interface will be managed under a different assigned to the same interface MUST NOT be managed under the same
mobility session. mobility session.
The mobile node's home network prefix(es) assigned to a given The mobile node's home network prefix(es) assigned to a given
interface of a mobile node (part of a mobility session) will be interface of a mobile node (part of a mobility session) will be
hosted on the access link where the mobile node is attached (using hosted on the access link where the mobile node is attached (using
that interface). The local mobility anchor is not required to that interface). The local mobility anchor is not required to
perform any proxy ND operations [RFC-4861] for defending the mobile perform any proxy ND operations [RFC-4861] for defending the mobile
node's home address(es), as the prefixes are not locally hosted on node's home address(es), as the prefixes are not locally hosted on
the local mobility anchor. However, from the routing perspective, the local mobility anchor. However, from the routing perspective,
the home network prefix(es) is topologically anchored on the local the home network prefix(es) is topologically anchored on the local
skipping to change at page 20, line 24 skipping to change at page 20, line 36
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 Mobility Header in the Section 9.2 of [RFC-3775] when processing the Mobility Header in
received Proxy Binding Update request. the received Proxy Binding Update request.
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 request.
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 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
skipping to change at page 27, line 14 skipping to change at page 27, line 31
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 request 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. request.
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 request
and MUST NOT be present otherwise. 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
binding request is rejected, then the link-local address from the
request MUST be copied to the Link-local Address option in the
reply, otherwise the following considerations apply.
* If the received Proxy Binding Update request has the Link-local * If the received Proxy Binding Update request has the Link-local
Address option with any value other than ALL_ZERO, the same Address option with ALL_ZERO value and if there is an existing
value MUST be copied to the Link-local Address field of the Binding Cache entry associated with this request, then the
Binding Cache entry and it must also be copied to the Link- link-local address from the Binding Cache entry MUST be copied
local Address option in the reply. to the Link-local Address option in the reply.
* If there is no existing Binding Cache entry (i.e., if this is a * If the received Proxy Binding Update request has the Link-local
request for a new mobility session), then the local mobility Address option with ALL_ZERO value and if there is no existing
anchor MUST generate the link-local address that the mobile Binding Cache entry associated with this request, then the
access gateway can use on the point-to-point link shared with local mobility anchor MUST generate the link-local address that
the mobile node and the same must be copied to the Link-local the mobile access gateway can use on the point-to-point link
Address field of the Binding Cache entry and it must also be shared with the mobile node. This generated address MUST be
copied to the Link-local Address option in the reply. copied to the Link-local Address option in the reply. The same
address MUST also be copied to the link-local address field of
Binding Cache entry created for this mobility session.
* For all other cases, the link-local address in the option MUST * If the received Proxy Binding Update request has the Link-local
be copied from the Link-local Address field of the Binding Address option with NON_ZERO value, then the link-local address
Cache entry. from the request MUST be copied to the Link-local Address
option in the reply. The same address MUST also be copied to
the link-local address field of the Binding Cache entry
associated with this request (after creating the Binding Cache
entry, if 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.
o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST
NOT be present in the IPv6 header of the packet. NOT be present in the IPv6 header of the packet.
5.4. Multihoming Support 5.4. Multihoming Support
This specification allows mobile nodes to connect to a Proxy Mobile This specification allows mobile nodes to connect to a Proxy Mobile
IPv6 domain through multiple interfaces for simultaneous access. IPv6 domain through multiple interfaces for simultaneous access.
Following are the key aspects of this multihoming support. Following are the key aspects of this multihoming support.
o When a mobile node connects to a Proxy Mobile IPv6 domain through o When a mobile node connects to a Proxy Mobile IPv6 domain through
multiple interfaces for simultaneous access, the local mobility multiple interfaces for simultaneous access, the local mobility
anchor MUST allocate a mobility session for each of the attached anchor MUST allocate a mobility session for each of the attached
interfaces. Each of the mobility session should be managed under interfaces. Each mobility session should be managed under a
a separate Binding Cache entry and with its own lifetime. separate Binding Cache entry and with its own lifetime.
o The local mobility anchor MAY allocate more than one home network o The local mobility anchor MAY allocate more than one home network
prefix for a given interface of the mobile node. However, all the prefix for a given interface of the mobile node. However, all the
prefixes associated with a given interface MUST be managed as part prefixes associated with a given interface MUST be managed as part
of one mobility session, associated with that interface. of one mobility session, associated with that interface.
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 a mobile node. In such a scenario, all different interfaces of a mobile node. In such a scenario, all
the home network prefix(es) associated with one interface (part of the home network prefix(es) associated with one interface (part of
one mobility session) will be associated with a different one mobility session) will be associated with a different
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. 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 request 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.
skipping to change at page 29, line 4 skipping to change at page 29, line 28
| MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present | | MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present |
+=====================================================================+ +=====================================================================+
| HI | | HI |
+==================================+==================================+ +==================================+==================================+
| BCE Lookup Key: Any of the Home Network Prefixes from the request | | BCE Lookup Key: Any of the Home Network Prefixes from the request |
+=====================================================================+ +=====================================================================+
Figure 7: BCE lookup using home network prefix Figure 7: BCE lookup using home network prefix
If there is at least one Home Network Prefix option present in the If there is at least one Home Network Prefix option present in the
request with NON_ZERO prefix value, the following considerations MUST request with a NON_ZERO prefix value and irrespective of the presence
be applied. If there are more than one instances of the Home Network of the Mobile Node Link-layer Identifier option in the request, the
Prefix option, any one of the Home Network Prefix options present in following considerations MUST be applied. If there are more than one
the request (with NON_ZERO prefix value) can be used for locating the instances of the Home Network Prefix option, any one of the Home
Binding Cache entry. Network Prefix options present in the request (with NON_ZERO prefix
value) can be used for locating the Binding Cache entry.
1. The local mobility anchor MUST verify if there is an existing 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. [BCE(HNP) options of the received Proxy Binding Update request.
equals PBU(HNP)]
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 request), the request MUST be
considered as a request for creating a new mobility session. considered as a request for creating a new mobility session.
[BCE(HNP) not equals PBU(HNP)]
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 request) 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 request, 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). [BCE(MN-Identifier) not equals PBU(MN-Identifier)] 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 request), 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). [BCE(HNP1, HNP2, .. HNPn) not equals in the received PBU).
PBU(HNP1, HNP2, ..HNPn)] OR [BCE(Count(HNP))] not equals
PBU(Count(HNP))]
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 request) 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. [BCE(MN-Identifier) equals updating that Binding Cache entry.
PBU(MN-Identifier)] AND [BCE(HNP1, HNP2, .. HNPn) equals
PBU(HNP1, HNP2, ..HNPn)]
* 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). [PBU(HI) equals two different interfaces of the mobile node).
2]
* 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
type field in the Access Technology Type option present in the type field in the Access Technology Type option present in the
request matches the access technology type in the Binding request matches the access technology type in the Binding
Cache entry and if the Handoff Indicator field in the Handoff Cache entry and if the Handoff Indicator field in the Handoff
Indicator option present in the request is set to a value of 3 Indicator option present in the request is set to a value of 3
(Handoff between mobile access gateways for the same (Handoff between mobile access gateways for the same
interface). interface).
* 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.
[BCE(Proxy-CoA, ATT) equals PBU(Proxy-CoA, ATT)].
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. for creating a new mobility session. However, if the received
Proxy Binding Update request has the lifetime value of zero and
if the request cannot be associated with any existing mobility
session, the message MUST be silently ignored.
5.4.1.2. Mobile Node Link-layer Identifier Option present in the 5.4.1.2. Mobile Node Link-layer Identifier Option present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| HNP option with ALL_ZERO Value | | No HNP option with a NON_ZERO Value |
+=====================================================================+ +=====================================================================+
| ATT | | ATT |
+=====================================================================+ +=====================================================================+
| MN-LL-Identifier Option Present (NON_ZERO Value) | | MN-LL-Identifier Option Present (NON_ZERO Value) |
+=====================================================================+ +=====================================================================+
| HI | | HI |
+==================================+==================================+ +==================================+==================================+
| BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) | | BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) |
+=====================================================================+ +=====================================================================+
Figure 8: BCE Lookup using Link-layer Identifier Figure 8: BCE Lookup using Link-layer Identifier
If there is no Home Network Prefix option present in the request with
a NON_ZERO prefix value, but if there is a Mobile Node Link-layer
Identifier option present in the request then the following
considerations MUST be applied for locating the Binding Cache entry.
1. The local mobility anchor MUST verify if there is an existing 1. The local mobility anchor MUST verify if there is an existing
Binding Cache entry, with the mobile node identifier matching the Binding Cache entry, with the mobile node identifier matching the
identifier in the received Mobile Node Identifier option, access identifier in the received Mobile Node Identifier option, access
technology type matching the value in the received Access technology type matching the value in the received Access
Technology Type option and the link-layer identifier value Technology Type option and the link-layer identifier value
matching the identifier in the received Mobile Node Link-layer matching the identifier in the received Mobile Node Link-layer
Identifier option. [BCE(MN-Identifier, ATT, MN-LL-Identifier) Identifier option.
equals PBU(MN-Identifier, ATT, MN-LL-Identifier)]
2. If there exists a Binding Cache entry (matching MN-Identifier, 2. If there exists a Binding Cache entry (matching MN-Identifier,
ATT and MN-LL-Identifier), the request MUST be considered as a ATT and MN-LL-Identifier), the request MUST be considered as a
request for updating that Binding Cache entry. request for updating that Binding Cache entry.
3. If there does not exist a Binding Cache entry (matching MN- 3. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator
field in the Handoff Indicator option present in the request is field in the Handoff Indicator option present in the request is
set to a value of 2 (Handoff between two different interfaces of set to a value of 2 (Handoff between two different interfaces of
the mobile node). The local mobility anchor MUST apply the the mobile node). The local mobility anchor MUST apply the
following additional considerations. [PBU(HI) equals 2] following additional considerations.
* The local mobility anchor MUST verify if there exists one and * The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option matching the identifier in the Mobile Node Identifier option
present in the request and for any link-layer identifier present in the request and for any link-layer identifier
value. If there exists only one such entry (matching the MN- value. If there exists only one such entry (matching the MN-
Identifier), the request MUST be considered as a request for Identifier), the request MUST be considered as a request for
updating that Binding Cache entry. [BCE(MN-Identifier) equals updating that Binding Cache entry.
PBU(MN-Identifier)]
4. If there does not exist a Binding Cache entry (matching MN- 4. If there does not exist a Binding Cache entry (matching MN-
Identifier, ATT and MN-LL-Identifier) and if the Handoff Identifier, ATT and MN-LL-Identifier) and if the Handoff
Indicator field in the Handoff Indicator option present in the Indicator field in the Handoff Indicator option present in the
request is set to a value of 4 (Handoff state unknown), the local request is set to a value of 4 (Handoff state unknown), the local
mobility anchor MUST apply the following additional mobility anchor MUST apply the following additional
considerations. considerations.
* The local mobility anchor MUST verify if there exists one and * The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier only one Binding Cache entry with the mobile node identifier
skipping to change at page 32, line 17 skipping to change at page 32, line 43
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 and without waiting for a de-
registration message and this should be configurable on the registration message and this should be configurable on the
local mobility anchor. 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. However, if the received
Proxy Binding Update request has the lifetime value of zero and
if the request cannot be associated with any existing mobility
session, the message MUST be silently ignored.
5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the
request request
+=====================================================================+ +=====================================================================+
| Registration/De-Registration Message | | Registration/De-Registration Message |
+=====================================================================+ +=====================================================================+
| HNP option with ALL_ZERO Value | | No HNP option with a NON_ZERO Value |
+=====================================================================+ +=====================================================================+
| ATT | | ATT |
+=====================================================================+ +=====================================================================+
| MN-LL-Identifier Option Not Present | | MN-LL-Identifier Option Not Present |
+=====================================================================+ +=====================================================================+
| HI | | HI |
+==================================+==================================+ +==================================+==================================+
| BCE Lookup Key: (MN-Identifier) | | BCE Lookup Key: (MN-Identifier) |
+=====================================================================+ +=====================================================================+
Figure 9: BCE Lookup using Mobile Node Identifier Figure 9: BCE Lookup using Mobile Node Identifier
If there is no Home Network Prefix option present in the request with
a NON_ZERO prefix value and if there is also no Mobile Node Link-
layer Identifier option present in the request then the following
considerations MUST be applied for locating the Binding Cache entry.
1. The local mobility anchor MUST verify if there exists one and 1. The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option matching the identifier in the Mobile Node Identifier option
present in the request. present in the request.
2. If there exists only one such entry (matching the MN-Identifier) 2. If there exists only one such entry (matching the MN-Identifier)
and the Handoff Indicator field in the Handoff Indicator option and 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) or set to a value of two different interfaces of the mobile node) or set to a value of
3 (Handoff between mobile access gateways for the same 3 (Handoff between mobile access gateways for the same
interface), then the request MUST be considered as a request for interface), then the request MUST be considered as a request for
updating that Binding Cache entry. [PBU(HI) equals 2] or updating that Binding Cache entry.
[PBU(HI) equals 3]
3. If there exists only one such entry (matching the MN-Identifier) 3. If there exists only one such entry (matching the MN-Identifier)
and the Handoff Indicator field in the Handoff Indicator option and the Handoff Indicator field in the Handoff Indicator option
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 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. for creating a new mobility session. However, if the received
Proxy Binding Update request has the lifetime value of zero and
if the request cannot be associated with any existing mobility
session, the message MUST be silently ignored.
5.5. Timestamp Option for Message Ordering 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
skipping to change at page 33, line 47 skipping to change at page 34, line 39
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 binding registration 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 previously serving 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
skipping to change at page 35, line 37 skipping to change at page 36, line 28
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
the Proxy Binding Acknowledgement message. the Proxy Binding Acknowledgement message.
6. Upon receipt of a Proxy Binding Update message with the Timestamp 6. Upon receipt of a Proxy Binding Update message with the Timestamp
option, the local mobility anchor MUST check the timestamp field option, the local mobility anchor MUST check the timestamp field
for validity. In order for it to be considered valid, the for validity. In order for it to be considered valid, the
timestamp value contained in the Timestamp option MUST be close following MUST be true.
enough (within TimestampValidityWindow amount of time difference)
to the local mobility anchor's time-of-day clock and the * The timestamp value contained in the Timestamp option MUST be
timestamp MUST be greater than all previously accepted timestamps close enough (within TimestampValidityWindow amount of time
in the Proxy Binding Update messages sent for that mobile node. difference) to the local mobility anchor's time-of-day clock.
However, if the flag MobileNodeGeneratedTimestampInUse is set to However, if the flag MobileNodeGeneratedTimestampInUse is set
value of 1, this check MUST NOT be performed. to value of 1, the local mobility anchor MUST ignore this
check and perform only the following check.
* The timestamp MUST be greater than all previously accepted
timestamps in the Proxy Binding Update messages sent for that
mobile node.
7. If the timestamp value in the received Proxy Binding Update is 7. If the timestamp value in the received Proxy Binding Update is
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
skipping to change at page 37, line 11 skipping to change at page 38, line 8
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
when needed and removed when not needed. However, implementations when needed and removed when not needed. However, implementations
MAY choose to use static pre-established tunnels instead of MAY choose to use static pre-established tunnels instead of
dynamically creating and tearing them down on a need basis. The dynamically creating and tearing them down on a need basis. The
following considerations MUST be applied when using dynamic tunnels. following considerations MUST be applied when using dynamic tunnels.
o A bi-directional tunnel MUST be established between the local o A bi-directional tunnel MUST be established between the local
mobility anchor and the mobile access gateway with IPv6-in-IPv6 mobility anchor and the mobile access gateway with IPv6-in-IPv6
encapsulation, as described in [RFC-2473]. The tunnel end points encapsulation, as described in [RFC-2473]. The tunnel end points
are the Proxy-CoA and LMAA. When using IPv4 transport, the end are the Proxy-CoA and LMAA. However, when using IPv4 transport,
points of the tunnel are the IPv4-LMAA and IPv4-Proxy-CoA, as the end points of the tunnel are IPv4-LMAA and IPv4-Proxy-CoA with
specified in [ID-IPV4-PMIP6]. the encapsulation mode as specified in [ID-IPV4-PMIP6].
o Implementations MAY use a software timer for managing the tunnel o Implementations MAY use a software timer for managing the tunnel
lifetime and a counter for keeping a count of all the mobile nodes lifetime and a counter for keeping a count of all the mobile nodes
that are sharing the tunnel. The timer value can be set to the that are sharing the tunnel. The timer value can be set to the
accepted binding lifetime and can be updated after each periodic accepted binding lifetime and can be updated after each periodic
re-registration for extending the lifetime. If the tunnel is re-registration for extending the lifetime. If the tunnel is
shared for multiple mobile nodes, the tunnel lifetime must be set shared for multiple mobile nodes, the tunnel lifetime must be set
to the highest binding lifetime that is granted to any one of to the highest binding lifetime that is granted to any one of
those mobile nodes sharing that tunnel. those mobile nodes sharing that tunnel.
skipping to change at page 40, line 15 skipping to change at page 41, line 14
5.9. Route Optimization Considerations 5.9. Route Optimization Considerations
The Route Optimization in Mobile IPv6, as defined in [RFC-3775], The Route Optimization in Mobile IPv6, as defined in [RFC-3775],
enables a mobile node to communicate with a correspondent node enables a mobile node to communicate with a correspondent node
directly using its care-of address and further the Return Routability directly using its care-of address and further the Return Routability
procedure enables the correspondent node to have reasonable trust procedure enables the correspondent node to have reasonable trust
that the mobile node is reachable at both its home address and that the mobile node is reachable at both its home address and
care-of address. care-of address.
In Proxy Mobile IPv6, the mobile node is not involved in any IP This specification does not support the Route Optimization as
mobility related signaling. The mobile node uses address(es) from specified in Mobile IPv6 [RFC-3775]. However, this specification
its home network prefix(es) for all its communication and the Care-of does support some other form of route optimization as specified in
address (Proxy-CoA) is not visible to the mobile node. Hence, the Section 6.10.3.
Return Routability procedure as defined in Mobile IPv6 [RFC-3775]
cannot be used in Proxy Mobile IPv6.
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 binding registration requests 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.
skipping to change at page 40, line 49 skipping to change at page 41, line 46
o It is responsible for detecting the mobile node's movements on the o It is responsible for detecting the mobile node's movements on the
access link and for initiating the mobility signaling with the access link and for initiating the mobility signaling with the
mobile node's local mobility anchor. mobile node's local mobility anchor.
o Emulation of the mobile node's home link on the access link by o Emulation of the mobile node's home link on the access link by
sending Router Advertisement messages containing the mobile node's sending Router Advertisement messages containing the mobile node's
home network prefix(es), each prefix carried using the Prefix home network prefix(es), each prefix carried using the Prefix
Information option [RFC-4861]. Information option [RFC-4861].
o Responsible for setting up the data path for enabling the mobile o Responsible for setting up the forwarding for enabling the mobile
node to configure one or more addresses from its home network node to configure one or more addresses from its home network
prefix(es) and use it from the attached access link. prefix(es) and use it from the attached access link.
6.1. Extensions to Binding Update List Entry Data Structure 6.1. Extensions to Binding Update List Entry Data Structure
Every mobile access gateway MUST maintain a Binding Update List. Every mobile access gateway MUST maintain a Binding Update List.
Each entry in the Binding Update List represents a mobile node's Each entry in the Binding Update List represents a mobile node's
mobility binding with its local mobility anchor. The Binding Update mobility binding with its local mobility anchor. The Binding Update
List is a conceptual data structure, described in Section 11.1 of List is a conceptual data structure, described in Section 11.1 of
[RFC-3775]. [RFC-3775].
skipping to change at page 41, line 46 skipping to change at page 42, line 45
Each of these prefix entries will also includes the corresponding Each of these prefix entries will also includes the corresponding
prefix length. prefix length.
o The Link-local address of the mobile access gateway on the access o The Link-local address of the mobile access gateway on the access
link shared with the mobile node. link shared with the mobile node.
o The IPv6 address of the local mobility anchor serving the attached o The IPv6 address of the local mobility anchor serving the attached
mobile node. This address is acquired from the mobile node's mobile node. This address is acquired from the mobile node's
policy profile or from other means. policy profile or from other means.
o The interface identifier (If-Id) of the point-to-point link o The interface identifier (if-id) of the point-to-point link
between the mobile node and the mobile access gateway. This is between the mobile node and the mobile access gateway. This is
internal to the mobile access gateway and is used to associate the internal to the mobile access gateway and is used to associate the
Proxy Mobile IPv6 tunnel to the access link where the mobile node Proxy Mobile IPv6 tunnel to the access link where the mobile node
is attached. is attached.
o The tunnel interface identifier (If-Id) of the bi-directional o The tunnel interface identifier (tunnel-if-id) of the bi-
tunnel between the mobile node's local mobility anchor and the directional tunnel between the mobile node's local mobility anchor
mobile access gateway. This is internal to the mobile access and the mobile access gateway. This is internal to the mobile
gateway. The tunnel interface identifier is acquired during the access gateway. The tunnel interface identifier is acquired
tunnel creation. during the tunnel creation.
6.2. Mobile Node's Policy Profile 6.2. Mobile Node's Policy Profile
A mobile node's policy profile contains the essential operational A mobile node's policy profile contains the essential operational
parameters that are required by the network entities for managing the parameters that are required by the network entities for managing the
mobile node's mobility service. These policy profiles are stored in mobile node's mobility service. These policy profiles are stored in
a local or a remote policy store. The mobile access gateway and the a local or a remote policy store. The mobile access gateway and the
local mobility anchor MUST be able to obtain a mobile node's policy local mobility anchor MUST be able to obtain a mobile node's policy
profile. The policy profile MAY also be handed over to a serving profile. The policy profile MAY also be handed over to a serving
mobile access gateway as part of a context transfer procedure during mobile access gateway as part of a context transfer procedure during
skipping to change at page 42, line 35 skipping to change at page 43, line 35
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 mobile node's connected interface. These prefix(es) have to be
maintained on a per-interface basis. There can be multiple of
these entries one for each interface of the mobile node. The
specific details on how the network maintains this association
between the prefix set and the interfaces, specially during the
mobility session handoff between interfaces is outside the scope
of this 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. they all are part of one mobility session. This value can also be
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
This specification supports only point-to-point access link types and This specification supports only point-to-point access link types and
thus it assumes that the mobile node and the mobile access gateway thus it assumes that the mobile node and the mobile access gateway
are the only two nodes on the access link. The link is assumed to are the only two nodes on the access link. The link is assumed to
have multicast capability. have multicast capability.
skipping to change at page 46, line 32 skipping to change at page 47, line 38
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 session and can be provided to the serving mobile access gateway at
every mobile node's handoff, as part of the Proxy Mobile IPv6 every mobile node's handoff, as part of the Proxy Mobile IPv6
signaling messages. The specific method by which the local mobility signaling messages. The specific method by which the local mobility
anchor generates the link-local address is out of scope for this anchor generates the link-local address is out of scope for this
specification. specification.
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
before the mobile node completes the DAD operation [RFC-4862] on its
link-local address, the mobile access gateway on that link is aware
of its own link-local address provided by the local mobility anchor
that it needs to use on that access link. This essentially requires
a successful completion of the Proxy Mobile IPv6 signaling by the
mobile access gateway before the mobile node completes the DAD
operation. This can be achieved by ensuring that link layer
attachment does not complete until the Proxy Mobile IPv6 signaling is
completed. Alternatively, network and local mobility anchor capacity
and signaling retransmission timers can be provisioned in such a way
that signaling is extremely likely to complete during the default
waiting period associated with the DAD process.
Optionally, implementations MAY choose to configure a fixed link- Optionally, implementations MAY choose to configure a fixed link-
local address across all the access links in a Proxy Mobile IPv6 local address across all the access links in a Proxy Mobile IPv6
domain and without a need for carrying this address from the local domain and without a need for carrying this address from the local
mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 mobility anchor to the mobile access gateway in the Proxy Mobile IPv6
signaling messages. signaling messages. The configuration variable
FixedMAGLinkLocalAddressOnAllAccessLinks determines the enabled mode
in that Proxy Mobile IPv6 domain.
6.9. Signaling Considerations 6.9. Signaling Considerations
6.9.1. Binding Registrations 6.9.1. Binding Registrations
6.9.1.1. Mobile Node Attachment and Initial Binding Registration 6.9.1.1. Mobile Node Attachment and Initial Binding Registration
1. After detecting a new mobile node on its access link, the mobile 1. After detecting a new mobile node on its access link, the mobile
access gateway MUST identify the mobile node and acquire its MN- access gateway MUST identify the mobile node and acquire its MN-
Identifier. If it determines that the network-based mobility Identifier. If it determines that the network-based mobility
skipping to change at page 49, line 31 skipping to change at page 50, line 50
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 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.
9. The Link-local Address option MAY be present in the Proxy 9. The Link-local Address option MUST be present in the Proxy
Binding Update message. Considerations from Section 6.8 MUST be Binding Update request only if the value of the configuration
applied when using the link-local address option. variable FixedMAGLinkLocalAddressOnAllAccessLinks is set to a
value of ALL_ZERO, otherwise the Link-local Address option MUST
* When querying the local mobility anchor for the link-local NOT be present in the request. Considerations from Section 6.8
address that it should use on the point-to-point link shared MUST be applied when using the Link-local Address option.
with the mobile node, this option MUST be set to ALL_ZERO.
This essentially serves as a request to the local mobility
anchor to provide the link-local address that it can use on
the access link shared with the mobile node.
* When uploading the link-local address to the local mobility * For querying the local mobility anchor to provide the link-
anchor, the value in the option MUST be set to the link-local local address that it should use on the point-to-point link
address that is configured on the point-to-point link shared shared with the mobile node, this option MUST be set to
with the mobile node. This is allowed only during an initial ALL_ZERO value. This essentially serves as a request to the
mobile node's attachment. local mobility anchor to provide the link-local address that
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 request.
6.9.1.2. Receiving Binding Registration Reply 6.9.1.2. Receiving Binding Registration Reply
skipping to change at page 52, line 31 skipping to change at page 53, line 48
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 for reflecting the accepted binding registration
values. It MUST also advertise the mobile node's home network values. It MUST also advertise the mobile node's home network
prefix(es) as the hosted on-link prefixes, by including them in prefix(es) as the hosted on-link prefixes, by including them in
the Router Advertisement messages that it sends on that access the Router 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 MUST configure that link-local value, the mobile access gateway SHOULD configure that link-
address on that point-to-point link and MUST NOT configure any local address on that point-to-point link and SHOULD NOT
other link-local address on that point-to-point link. This will configure any other link-local address without performing a DAD
avoid any link-local address collisions with the mobile node on operation [RFC-4862]. This will avoid any potential link-local
that access link. address collisions on that access link. However, if the link-
local address generated by the local mobility anchor happens to
be already in use by the mobile node on that link, the mobile
access gateway MUST NOT use that address, but SHOULD configure a
different link-local address. It SHOULD also upload this link-
local address to the local mobility anchor by immediately
sending a Proxy Binding Update request and by including this
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 binding
registration message, under the considerations specified in registration message, under the considerations specified in
skipping to change at page 56, line 20 skipping to change at page 57, line 38
access gateway on those respective links will send the Router access gateway on those respective links will send the Router
Advertisement messages. If these Router Advertisements are sent Advertisement messages. If these Router Advertisements are sent
using a different link-local address or a different link-layer using a different link-local address or a different link-layer
address, the mobile node will always detect a new default-router address, the mobile node will always detect a new default-router
after every handoff. For solving this problem, this specification after every handoff. For solving this problem, this specification
requires all the mobile access gateways in the Proxy Mobile IPv6 requires all the mobile access gateways in the Proxy Mobile IPv6
domain to use the same link-local and link-layer address on any of domain to use the same link-local and link-layer address on any of
the access links where ever the mobile node attaches. These the access links where ever the mobile node attaches. These
addresses can be fixed addresses across the entire Proxy Mobile IPv6 addresses can be fixed addresses across the entire Proxy Mobile IPv6
domain and all the mobile access gateways can use these globally domain and all the mobile access gateways can use these globally
fixed address on any of the point-to-point links. Additionally, this fixed address on any of the point-to-point links. The configuration
specification allows the local mobility anchor to generate the link- variables FixedMAGLinkLocalAddressOnAllAccessLinks and
local address and provide it to the mobile access gateway as part of FixedMAGLinkLayerAddressOnAllAccessLinks SHOULD be used for this
the signaling messages. purpose. Additionally, this specification allows the local mobility
anchor to generate the link-local address and provide it to the
mobile access gateway as part of the signaling messages.
However, both of these approaches (a link-local address generated by However, both of these approaches (a link-local address generated by
the local mobility anchor or when using a globally fixed link-local the local mobility anchor or when using a globally fixed link-local
address) have implications on the deployment of SEcure Neighbor address) have implications on the deployment of SEcure Neighbor
Discovery (SEND) [RFC-3971]. In SEND, routers have certificates and Discovery (SEND) [RFC-3971]. In SEND, routers have certificates and
public key pairs, and their Router Advertisements are signed with the public key pairs, and their Router Advertisements are signed with the
private keys of these key pairs. When a number of different routers private keys of these key pairs. When a number of different routers
use the same addresses, the routers either all have to be able to use the same addresses, the routers either all have to be able to
construct these signatures for the same key pair, or the used key construct these signatures for the same key pair, or the used key
pair and the router's cryptographic identity must change after a pair and the router's cryptographic identity must change after a
skipping to change at page 66, line 22 skipping to change at page 67, line 47
This non-normative section explains the mobile node's operation in a This non-normative section explains the mobile node's operation in a
Proxy Mobile IPv6 domain. Proxy Mobile IPv6 domain.
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 data path 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, If the mobile node is IPv6 enabled, on attaching to the access link,
it will typically send a Router Solicitation message [RFC-4861]. The it will typically send a Router Solicitation message [RFC-4861]. The
mobile access gateway on the access link will respond to the Router mobile access gateway on the access link will respond to the Router
Solicitation message with a Router Advertisement message. The Router Solicitation 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.
skipping to change at page 80, line 19 skipping to change at page 81, line 19
The default value for this variable is 10000 milliseconds. The default value for this variable is 10000 milliseconds.
MaxDelayBeforeNewBCEAssign MaxDelayBeforeNewBCEAssign
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 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 500 milliseconds. The default value for this variable is 1500 milliseconds.
Note that there is a dependency between this value and the values
used in the retransmission algorithm for Proxy Binding Updates.
The retransmissions need to happen before
MaxDelayBeforeNewBCEAssign runs out, as otherwise there are
situations where a de-registration from and old mobile access
gateway may be lost, and the local mobility anchor creates
needlessly a new session and new prefixes for the mobile node.
This affects situations where there is no information from the
lower layers about the type of a handoff or other parameters 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 81, line 38 skipping to change at page 82, line 47
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.
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
This variable indicates the link-local address value that all the
mobile access gateways SHOULD use on any of the access links
shared with any of the mobile nodes in that Proxy Mobile IPv6
domain. If this variable is initialized to ALL_ZERO value, it
implies the use of fixed link-local address mode is not enabled
for that Proxy Mobile IPv6 domain.
FixedMAGLinkLayerAddressOnAllAccessLinks
This variable indicates the link-layer address value that all the
mobile access gateways SHOULD use on any of the access links
shared with any of the mobile nodes in that Proxy Mobile IPv6
domain. For access technologies where there is no link-layer
address, this variable MUST be initialized to ALL_ZERO value.
10. IANA Considerations 10. IANA Considerations
This document defines six new Mobility Header options, the Home This document defines six new Mobility Header options, the Home
Network Prefix option, Handoff Indicator option, Access Technology Network Prefix option, Handoff Indicator option, Access Technology
Type option, Mobile Node Link-layer Identifier option, Link-local Type option, Mobile Node Link-layer Identifier option, Link-local
Address option and Timestamp option. These options are described in Address option and Timestamp option. These options are described in
Section 8. The Type value for these options needs to be assigned Section 8. The Type value for these options needs to be assigned
from the same numbering space as allocated for the other mobility from the same numbering space as allocated for the other mobility
options, as defined in [RFC-3775]. options, as defined in [RFC-3775].
skipping to change at page 83, line 27 skipping to change at page 85, line 13
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, Fred Templin, Genadi Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Charlie Perkins, Fred
Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham Templin, Genadi Velev, George Tsirtsis, Gerardo Giaretta, Henrik
Soliman, James Kempf, Jean-Michel Combes, Jun Awano, John Zhao, Jong- Levkowetz, Hesham Soliman, James Kempf, Jean-Michel Combes, John
Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian Jason Brzozowski, Jun Awano, John Zhao, Jong-Hyouk Lee, Jonne
Weniger, Lars Eggert, Magnus Westerlund, Marco Liebsch, Mohamed Soininen, Jouni Korhonen, Kalin Getov, Kilian Weniger, Lars Eggert,
Khalil, Nishida Katsutoshi, Phil Roberts, Ralph Droms, Ryuji Magnus Westerlund, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi,
Wakikawa, Sangjin Jeong, Suresh Krishnan, Uri Blumenthal, Ved Kafle, Pierrick Seite, Phil Roberts, Ralph Droms, Ryuji Wakikawa, Sangjin
Vidya Narayanan, Youn-Hee Han and many others for their passionate Jeong, Suresh Krishnan, Uri Blumenthal, Ved Kafle, Vidya Narayanan,
discussions in the working group mailing list on the topic of Youn-Hee Han and many others for their passionate discussions in the
localized mobility management solutions. These discussions working group mailing list on the topic of localized mobility
stimulated much of the thinking and shaped the draft to the current management solutions. These discussions stimulated much of the
form and we acknowledge that ! thinking and shaped the draft to the current form and we acknowledge
that !
The authors would also like to thank Ole Troan, Akiko Hattori, Parviz The authors would also like to thank Ole Troan, Akiko Hattori, Parviz
Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer, Tim Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer, Tim
Stammers, Bernie Volz and Josh Littlefield for their input on this Stammers, Bernie Volz and Josh Littlefield for their input on this
document. document.
13. References 13. References
13.1. Normative References 13.1. Normative References
skipping to change at page 86, line 6 skipping to change at page 87, line 34
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941, September for Stateless Address Autoconfiguration in IPv6", RFC 4941, September
2007. 2007.
[RFC-5094] Devarapalli, V., Leung, K. and Patel, A., "Mobile IPv6 [RFC-5094] Devarapalli, V., Leung, K. and Patel, A., "Mobile IPv6
Vendor Specific Option", RFC 5094, December 2007. Vendor Specific Option", RFC 5094, December 2007.
[ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for
Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03.txt,
November 2007. 2008.
[ID-DNAV6] Narayanan, S., et al "Detecting Network Attachment in IPv6 [ID-DNAV6] Narayanan, S., et al "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, February 2008. Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, February 2008.
Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure
Every mobile node that roams in a proxy Mobile IPv6 domain, would Every mobile node that roams in a proxy Mobile IPv6 domain, would
typically be identified by an identifier, MN-Identifier, and that typically be identified by an identifier, MN-Identifier, and that
identifier will have an associated policy profile that identifies the identifier will have an associated policy profile that identifies the
mobile node's home network prefix(es) on a per-interface basis, mobile node's home network prefix(es) on a per-interface basis,
skipping to change at page 87, line 17 skipping to change at page 88, line 44
+==================================================================+ +==================================================================+
| MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 |
| (IPv6 Prefix or |----------------------------------------------| | (IPv6 Prefix or |----------------------------------------------|
| Input Interface) | Locally Connected | Tunnel0 | | Input Interface) | Locally Connected | Tunnel0 |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 |
+ (IPv6 Prefix or -----------------------------------------------| + (IPv6 Prefix or -----------------------------------------------|
| Input Interface | Locally Connected | direct | | Input Interface | Locally Connected | direct |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Figure 24: Example - Policy based Route Table Example - Policy based Route Table
+==================================================================+ +==================================================================+
| Interface | Source Address | Destination Address | Encapsulation | | Interface | Source Address | Destination Address | Encapsulation |
+==================================================================+ +==================================================================+
| Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 | | Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Figure 25: Example - Tunnel Interface Table Example - Tunnel Interface Table
Authors' Addresses Authors' Addresses
Sri Gundavelli Sri Gundavelli
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
 End of changes. 82 change blocks. 
275 lines changed or deleted 367 lines changed or added

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