draft-ietf-netlmm-proxymip6-08.txt   draft-ietf-netlmm-proxymip6-09.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: June 27, 2008 V. Devarapalli Expires: August 6, 2008 V. Devarapalli
Azaire Networks Azaire Networks
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
B. Patil B. Patil
Nokia Siemens Networks Nokia Siemens Networks
December 25, 2007 February 03, 2008
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-08.txt draft-ietf-netlmm-proxymip6-09.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 June 27, 2008. This Internet-Draft will expire on August 6, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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
behalf of the host. The mobility entities in the network are behalf of the host. The mobility entities in the network are
responsible for tracking the movements of the host and initiating the responsible for tracking the movements of the host and initiating the
required mobility signaling on its behalf. This specification required mobility signaling on its behalf. This specification
describes a network-based mobility management protocol and is describes a network-based mobility management protocol and is
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.1. Conventions used in this document . . . . . . . . . . . . 5 2.1. Conventions used in this document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 8 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 8
4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 14 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 14
4.1. Peer Authorization Database Entries . . . . . . . . . . . 15 4.1. Peer Authorization Database Entries . . . . . . . . . . . 15
4.2. Security Policy Database Entries . . . . . . . . . . . . . 15 4.2. Security Policy Database Entries . . . . . . . . . . . . . 15
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 16 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 16
5.1. Extensions to Binding Cache Entry Data Structure . . . . . 16 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 16
5.2. Supported Home Network Prefix Models . . . . . . . . . . . 18 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 18
5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 18 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 18
5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 24 5.3.1. Processing Binding Registrations . . . . . . . . . . . 18
5.5. Timestamp Option for Message Ordering . . . . . . . . . . 28 5.3.2. Initial Binding Registration (New Mobility Session) . 20
5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 30 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 21
5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 30 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 22
5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 31 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 22
5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 32 5.3.6. Constructing the Proxy Binding Acknowledgement
5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 32 Message . . . . . . . . . . . . . . . . . . . . . . . 23
5.9. Route Optimizations Considerations . . . . . . . . . . . . 33 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 25
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 33 5.4.1. Binding Cache entry lookup considerations . . . . . . 26
6.1. Extensions to Binding Update List Entry Data Structure . . 34 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 31
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 35 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 33
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 35 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 33
6.4. Supported Address Configuration Models . . . . . . . . . . 36 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 34
6.5. Access Authentication & Mobile Node Identification . . . . 36 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 35
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 36 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 36
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 37 5.9. Route Optimizations Considerations . . . . . . . . . . . . 36
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 38 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 36
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 39 6.1. Extensions to Binding Update List Entry Data Structure . . 37
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 39 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 38
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 45 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 38
6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 45 6.4. Supported Address Configuration Modes . . . . . . . . . . 39
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 46 6.5. Access Authentication & Mobile Node Identification . . . . 39
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 46 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 39
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 46 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 40
6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 47 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 41
6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 48 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 42
6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 49 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 42
6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 49 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 49
6.9.3. Default-Router Lifetime . . . . . . . . . . . . . . . 50
6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 51
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 52
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 52
6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 53
6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 53
6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 53
6.11. Supporting DHCPv6 based Address Configuration on the 6.11. Supporting DHCPv6 based Address Configuration on the
Access Link . . . . . . . . . . . . . . . . . . . . . . . 50 Access Link . . . . . . . . . . . . . . . . . . . . . . . 55
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 51 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 56
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 51 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 56
6.14. Allowing network access to other IPv6 nodes . . . . . . . 52 6.14. Allowing network access to other IPv6 nodes . . . . . . . 57
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 53 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 57
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 53 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 57
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 54 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 58
7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 54 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 59
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 55 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 59
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 56 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 61
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 57 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 62
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 58 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 63
8.4. Access Technology Type Option . . . . . . . . . . . . . . 60 8.5. Access Technology Type Option . . . . . . . . . . . . . . 64
8.5. Mobile Node Interface Identifier Option . . . . . . . . . 61 8.6. Mobile Node Interface Identifier Option . . . . . . . . . 66
8.6. Link-local Address Option . . . . . . . . . . . . . . . . 62 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 67
8.7. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 63 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 67
8.8. Status Values . . . . . . . . . . . . . . . . . . . . . . 64 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 68
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 66 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 70
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
11. Security Considerations . . . . . . . . . . . . . . . . . . . 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 72
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 73
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 73
13.2. Informative References . . . . . . . . . . . . . . . . . . 70 13.2. Informative References . . . . . . . . . . . . . . . . . . 74
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 71 Infrastructure . . . . . . . . . . . . . . . . . . . 75
Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 71 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 Appendix C. Routing State . . . . . . . . . . . . . . . . . . . . 76
Intellectual Property and Copyright Statements . . . . . . . . . . 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
Intellectual Property and Copyright Statements . . . . . . . . . . 79
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
located in the network. located in the network.
Network-based mobility is another approach to solving the IP mobility Network-based mobility is another approach to solving the IP mobility
challenge. It is possible to support mobility for IPv6 nodes without challenge. It is possible to support mobility for IPv6 nodes without
host involvement by extending Mobile IPv6 [RFC-3775] signaling host involvement by extending Mobile IPv6 [RFC-3775] signaling
messages and reusing the home agent. This approach to supporting messages between a network node and a home agent. This approach to
mobility does not require the mobile node to be involved in the supporting mobility does not require the mobile node to be involved
exchange of signaling messages between itself and the Home Agent. A in the exchange of signaling messages between itself and the home
proxy mobility agent in the network performs the signaling with the agent. A proxy mobility agent in the network performs the signaling
home agent and does the mobility management on behalf of the mobile with the home agent and does the mobility management on behalf of the
node attached to the network. Because of the use and extension of mobile node attached to the network. Because of the use and
Mobile IPv6 signaling and home agent functionality, this protocol is extension of Mobile IPv6 signaling and home agent functionality, this
referred to as Proxy Mobile IPv6 (PMIPv6). protocol is referred to as Proxy Mobile IPv6 (PMIPv6).
Network deployments which are designed to support mobility would be Network deployments which are designed to support mobility would be
agnostic to the capability in the IPv6 stack of the nodes which it agnostic to the capability in the IPv6 stack of the nodes which it
serves. IP mobility for nodes which have mobile IP client serves. IP mobility for nodes which have mobile IP client
functionality in the IPv6 stack as well as those hosts which do not, functionality in the IPv6 stack as well as those nodes which do not,
would be supported by enabling Proxy Mobile IPv6 protocol would be supported by enabling Proxy Mobile IPv6 protocol
functionality in the network. The advantages of developing a network functionality in the network. The advantages of developing a network
based mobility protocol based on Mobile IPv6 are: based mobility protocol based on Mobile IPv6 are:
o Reuse of home agent functionality and the messages/format used in o Reuse of home agent functionality and the messages/format used in
mobility signaling. Mobile IPv6 is a mature protocol with several mobility signaling. Mobile IPv6 is a mature protocol with several
implementations that have undergone interoperability testing. implementations that have undergone interoperability testing.
o A common home agent would serve as the mobility agent for all o A common home agent would serve as the mobility agent for all
types of IPv6 nodes. types of IPv6 nodes.
skipping to change at page 5, line 48 skipping to change at page 5, line 48
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 that manages the mobility
related signaling for a mobile node that is attached to its access related signaling for a mobile node that is attached to its access
link. It is responsible for tracking the mobile node's movements link. It is responsible for tracking the mobile node's movements
on the access link and for signaling the mobile node's local to and from the access link and for signaling the mobile node's
mobility anchor. 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 whose mobility is managed by the network. The mobile an IP host or router whose mobility is managed by the network.
node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual The mobile node may be operating in IPv6 mode, IPv4 mode or in
mode. The mobile node is not required to participate in any IP IPv4/IPv6 dual mode. The mobile node is not required to
mobility related signaling for achieving mobility for an IP participate in any IP mobility related signaling for achieving
address that is obtained in that Proxy Mobile IPv6 domain. This mobility for an IP address that is obtained in that Proxy Mobile
document further uses explicit text when referring to a mobile IPv6 domain.
node that is involved in mobility related signaling as per the
Mobile IPv6 specification [RFC-3775].
LMA Address (LMAA) LMA Address (LMAA)
The address that is configured on the interface of the local The address that is configured on the interface of the local
mobility anchor and is the transport endpoint of the bi- mobility anchor and is the transport endpoint of the bi-
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
skipping to change at page 6, line 44 skipping to change at page 6, line 42
local mobility anchor views this address as the Care-of Address of local mobility anchor views this address as the Care-of Address of
the mobile node and registers it in the Binding Cache entry for the mobile node and registers it in the Binding Cache entry for
that mobile node. When the transport network between the mobile that mobile node. When the transport network between the mobile
access gateway and the local mobility anchor is an IPv4 network access gateway and the local mobility anchor is an IPv4 network
and if the care-of address that is registered at the local and if the care-of address that is registered at the local
mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is
used, as specified in [ID-IPV4-PMIP6]. used, as specified in [ID-IPV4-PMIP6].
Mobile Node's Home Address (MN-HoA) Mobile Node's Home Address (MN-HoA)
MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6 MN-HoA is an address from a mobile node's home network prefix in a
domain. It is an address from its home network prefix obtained by Proxy Mobile IPv6 domain. The mobile node will be able to use
a mobile node in a Proxy Mobile IPv6 domain. The mobile node can this address as long as it is attached to the access network that
continue to use this address as long as it is attached to the is in the scope of that Proxy Mobile IPv6 domain. Unlike in
network that is in the scope of that Proxy Mobile IPv6 domain. Mobile IPv6 where the home agent is aware of the home address of
the mobile node, in Proxy Mobile IPv6, the mobility entities are
only aware of the mobile node's home network prefix and are not
always aware of the exact address(es) that the mobile node
configured on its interface from that prefix.
Mobile Node's Home Network Prefix (MN-HNP) Mobile Node's Home Network Prefix (MN-HNP)
This is the on-link IPv6 prefix that is always present in the This is the on-link IPv6 prefix that is always present in the
Router Advertisements that the mobile node receives when it is Router Advertisements that the mobile node receives when it is
attached to any of the access links in that Proxy Mobile IPv6 attached to any of the access links in that Proxy Mobile IPv6
domain. This home network prefix is topologically anchored at the domain. This home network prefix is topologically anchored at the
mobile node's local mobility anchor. The mobile node configures mobile node's local mobility anchor. The mobile node configures
its interface with an address from this prefix. If the mobile its interface with an address from this prefix. If the mobile
node connects to the Proxy Mobile IPv6 domain through multiple node connects to the Proxy Mobile IPv6 domain through multiple
interfaces, simultaneously, each of the connected interface will interfaces, simultaneously, each of the connected interface will
skipping to change at page 8, line 45 skipping to change at page 8, line 45
setup the required routing state. setup the required routing state.
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. The mobile access gateway is the mobile node's home network prefix. The mobile access gateway is the
entity that performs the mobility management on behalf of a mobile entity that performs the mobility management on behalf of a mobile
node and it resides on the access link where the mobile node is node and it resides on the access link where the mobile node is
anchored. The mobile access gateway is responsible for detecting the anchored. The mobile access gateway is responsible for detecting the
mobile node's movements on its access link and for sending binding mobile node's movements to and from the access link and for
registrations to the mobile node's local mobility anchor. The initiating binding registrations to the mobile node's local mobility
architecture of a Proxy Mobile IPv6 domain is shown in Figure 1. anchor. 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 19 skipping to change at page 10, line 19
IPv6 or dual IPv4/IPv6 addresses and move anywhere in that Proxy IPv6 or dual IPv4/IPv6 addresses and move anywhere in that Proxy
Mobile IPv6 domain. However, the specific details related to the Mobile IPv6 domain. However, the specific details related to the
IPv4 addressing or IPv4 transport support are specified in the IPv4 addressing or IPv4 transport support are 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 home network prefix for each of the connected will allocate a unique home network prefix for each of the connected
interfaces and the mobile node will be able to configure an interfaces and the mobile node will be able to configure an
address(es) on those interfaces from the respective home network address(es) on those interfaces from the respective home network
prefixes. If the mobile node performs a handover from one interface prefixes. However, if the mobile node performs an handoff from one
to another in the same Proxy Mobile IPv6 domain, then the local interface to another and if the local mobility anchor receives an
mobility anchor will assign the same prefix to the new interface, if handoff hint from the serving mobile access gateway about the same,
it receives the handover hints from the mobile access gateway in the the local mobility anchor will assign the same prefix to the new
signaling messages. interface.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | MN | | MAG | | LMA |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
MN Attached | | MN Attached | |
| | | | | |
| MN Attached Event | | MN Attached Event |
| (Acquire MN-Id and Profile) | | (Acquire MN-Id and Profile) |
| | | | | |
skipping to change at page 13, line 38 skipping to change at page 13, line 38
| | | | | | | |
|<------------------------------------ Rtr Adv ----| |<------------------------------------ Rtr Adv ----|
| | | | | | | |
MN retains HoA/HNP MN retains HoA/HNP
| | | | | | | |
Figure 3: Mobile Node Handoff - Signaling Call Flow Figure 3: Mobile Node Handoff - Signaling Call Flow
Figure 3 shows the signaling call flow for the mobile node's handoff Figure 3 shows the signaling call flow for the mobile node's handoff
from previously attached mobile access gateway (p-MAG) to the newly from previously attached mobile access gateway (p-MAG) to the newly
attached mobile access gateway (n-MAG). attached mobile access gateway (n-MAG). This call flow reflects only
a specific message ordering, it is possible the registration message
from the n-MAG may arrive before the de-registration message from the
p-MAG arrives.
After obtaining the initial address configuration in the Proxy Mobile After obtaining the initial address configuration in the Proxy Mobile
IPv6 domain, if the mobile node changes its point of attachment, the IPv6 domain, if the mobile node changes its point of attachment, the
mobile access gateway on the previous link will detect the mobile mobile access gateway on the previous link will detect the mobile
node's detachment from the link and will signal the local mobility node's detachment from the link and will signal the local mobility
anchor and will remove the binding and routing state for that mobile anchor and will remove the binding and routing state for that mobile
node. However, the local mobility anchor upon accepting the request node. However, the local mobility anchor upon accepting the request
will wait for certain amount of time before it deletes the binding, will wait for certain amount of time before it deletes the binding,
for allowing a smooth handoff. for allowing a smooth handoff.
skipping to change at page 14, line 20 skipping to change at page 14, line 24
4. Proxy Mobile IPv6 Protocol Security 4. Proxy Mobile IPv6 Protocol Security
The signaling messages, Proxy Binding Update and Proxy Binding The signaling messages, Proxy Binding Update and Proxy Binding
Acknowledgement, exchanged between the mobile access gateway and the Acknowledgement, exchanged between the mobile access gateway and the
local mobility anchor MUST be protected using end-to-end security local mobility anchor MUST be protected using end-to-end security
association(s) offering integrity and data origin authentication. association(s) offering integrity and data origin authentication.
The mobile access gateway and the local mobility anchor MUST The mobile access gateway and the local mobility anchor MUST
implement IPsec for protecting the Proxy Mobile IPv6 signaling implement IPsec for protecting the Proxy Mobile IPv6 signaling
messages [RFC-4301]. IPsec is the default security mechanism for messages [RFC-4301]. That is, IPsec is mandatory to implement
securing the signaling messages. However in certain deployments of security mechanism. However, additional documents may specify
this protocol, other security mechanisms MAY be applied and the alternative mechanisms.
signaling messages must be protected using the semantics provided by
that respective mechanism. The specification of the other security
mechanisms are beyond the scope of this document
IPsec ESP [RFC-4303] in transport mode with mandatory integrity IPsec ESP [RFC-4303] in transport mode with mandatory integrity
protection SHOULD be used for protecting the signaling messages. protection SHOULD be used for protecting the signaling messages.
Confidentiality protection of these messages is not required. Confidentiality protection of these messages is not required.
IKEv2 [RFC-4306] SHOULD be used to setup security associations IKEv2 [RFC-4306] SHOULD be used to setup security associations
between the mobile access gateway and the local mobility anchor to between the mobile access gateway and the local mobility anchor to
protect the Proxy Binding Update and Proxy Binding Acknowledgement protect the Proxy Binding Update and Proxy Binding Acknowledgement
messages. The mobile access gateway and the local mobility anchor messages. The mobile access gateway and the local mobility anchor
can use any of the authentication mechanisms, as specified in IKEv2, can use any of the authentication mechanisms, as specified in IKEv2,
for mutual authentication. for mutual authentication.
The Mobile IPv6 specification [RFC-3775] requires the home agent to The Mobile IPv6 specification [RFC-3775] requires the home agent to
prevent a mobile node from creating security associations or creating prevent a mobile node from creating security associations or creating
binding cache entries for another mobile node's home address. In the binding cache entries for another mobile node's home address. In the
protocol described in this document, the mobile node is not involved protocol described in this document, the mobile node is not involved
in creating security associations for protecting the signaling in creating security associations for protecting the signaling
messages or sending binding updates. Therefore, the local mobility messages or sending binding updates. Therefore, the local mobility
anchor MUST allow only authorized mobile access gateways to create anchor MUST restrict the creation and manipulation of proxy bindings
binding cache entries on behalf of the mobile nodes. The actual to specifically authorized mobile access gateways and prefixes. The
mechanism by which the local mobility anchor verifies if a specific local mobility anchor MUST be locally configurable to authorize such
mobile access gateway is authorized to send Proxy Binding Updates on specific combinations. Additional mechanisms such as a policy store
behalf of a mobile node is outside the scope of this document. One or AAA may be employed, but these are outside the scope of this
possible way this could be achieved is by sending a query to the specification.
policy store, such as AAA.
4.1. Peer Authorization Database Entries 4.1. Peer Authorization Database 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.
skipping to change at page 16, line 43 skipping to change at page 16, line 43
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. Binding Cache entry is a
conceptual data structure, described in Section 9.1 [RFC-3775]. conceptual data structure, described in Section 9.1 [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 enabled for created due to a proxy registration. This flag is enabled for
Binding Cache entries that are proxy registrations and is turned Binding Cache entries that are proxy registrations and is turned
off for all other entries that are created due to the off for all other entries.
registrations directly sent by the mobile node.
o The identifier of the registered mobile node, MN-Identifier. This o The identifier of the registered mobile node, MN-Identifier. This
identifier is obtained from the Mobile Node Identifier Option identifier is obtained from the Mobile Node Identifier Option
[RFC-4283] present in the received Proxy Binding Update request. [RFC-4283] present in the received Proxy Binding Update request.
o The interface identifier of the mobile node's connected interface o The interface identifier of the mobile node's connected interface
on the access link. This identifier can be acquired from the on the access link. This identifier can be acquired from the
Mobile Node Interface Identifier option, present in the received Mobile Node Interface Identifier option, present in the received
Proxy Binding Update request. If the option was not present in Proxy Binding Update request. If the option was not present in
the request, this value MUST be set to ALL_ZERO. the request, the value MUST be set to ALL_ZERO.
o The Link-local address of the mobile node on the interface o The Link-local address of the mobile node on the interface
attached to the access link. This is obtained from the Link-local attached to the access link. This is obtained from the Link-local
Address option, present in the Proxy Binding Update request. Address option, present in the Proxy Binding Update request. If
the option was not present in the request, the value MUST be set
to ALL_ZERO.
o The IPv6 home network prefix of the registered mobile node. The o The IPv6 home network prefix that is assigned to the mobile node's
home network prefix of the mobile node may have been statically connected interface. The home network prefix of the mobile node
configured in the mobile node's policy profile, or, it may have may have been statically configured in the mobile node's policy
been dynamically allocated by the local mobility anchor. The IPv6 profile, or, it may have been dynamically allocated by the local
home network prefix also includes the corresponding prefix length. mobility anchor. The IPv6 home network prefix also includes the
corresponding prefix length.
o The interface identifier of the bi-directional tunnel established o The interface identifier (If-Id) of the bi-directional tunnel
between the local mobility anchor and the mobile access gateway between the local mobility anchor and the mobile access gateway
where the mobile node is currently anchored. The tunnel interface where the mobile node is currently anchored. This is internal to
identifier is acquired during the tunnel creation. the local mobility anchor. The tunnel interface identifier is
acquired during the tunnel creation.
o The access technology through which the mobile node is currently o The access technology type, using which the mobile node is
connected. This is obtained from the Access Technology Type currently attached. This is obtained from the Access Technology
option, present in the Proxy Binding Update message. 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 Binding Update request sent for this mobile node. This is the
obtained from the Timestamp option, present in the request. time-of-day on the local mobility anchor, when the message was
received. If the Timestamp option is not present in the Proxy
Typically, the MN-Identifier is the key for locating a Binding Cache Binding Update request (i.e., when sequence number based scheme is
entry. However, when supporting multihoming there MAY be more than in use), the value MUST be set to ALL_ZERO.
one Binding Cache entry with the same MN-Identifier and in such cases
the entry can be located using any of the following key combinations:
o MN-Identifier, MN-HNP
o MN-Identifier, Proxy-CoA
o MN-Identifier, MN-Interface-Identifier
o MN-Identifier, Access Technology Type (When MN-Interface- Typically, the mobile node's home network prefix is the key for
Identifier is not present) locating a Binding Cache entry in all cases except when there has
been an handoff of the mobile node's session to a new mobile access
gateway and that mobile access gateway is unaware of the home network
prefix that was assigned to the handed of session. In such handoff
cases, the Binding Cache entry can be located under the
considerations specified in Section 5.4.1.
5.2. Supported Home Network Prefix Models 5.2. Supported Home Network Prefix Models
This specification supports Per-MN-Prefix model and does not support This specification supports Per-MN-Prefix model and does not support
Shared-Prefix model. As per the Per-MN-Prefix model, there will be a Shared-Prefix model. As per the Per-MN-Prefix model, there will be a
unique home network prefix assigned to each mobile node and no other unique home network prefix assigned to each mobile node and no other
node shares an address from that prefix. The assigned prefix is node shares an address from that prefix. The assigned prefix is
unique to a mobile node and also unique to a given interface of the unique to a mobile node and also unique to a given interface of the
mobile node. If the mobile node attaches to the Proxy Mobile IPv6 mobile node. If the mobile node attaches to the Proxy Mobile IPv6
domain through multiple interfaces and simultaneously, each of those domain through multiple interfaces and simultaneously, each of those
skipping to change at page 18, line 33 skipping to change at page 18, line 33
anchored on the local mobility anchor. anchored on the local mobility anchor.
5.3. Signaling Considerations 5.3. Signaling Considerations
This section provides the rules for processing the signaling This section provides the rules for processing the signaling
messages. The processing rules specified in this section and other messages. The processing rules specified in this section and other
related sections are chained and are in a specific order. When related sections are chained and are in a specific order. When
applying these considerations for processing the signaling messages, applying these considerations for processing the signaling messages,
the specified order MUST be maintained. the specified order MUST be maintained.
Processing Binding Registrations 5.3.1. Processing Binding Registrations
Upon receiving a Proxy Binding Update request (a Binding Update 1. The received Proxy Binding Update message (a Binding Update
Request with the 'P' flag set) from a mobile access gateway on behalf message with the 'P' flag set) MUST be authenticated as
of a mobile node, the local mobility anchor MUST process the request described in Section 4.0. When IPsec is used for message
as defined in Section 10.3 [RFC-3775]; additionally the following authentication, the SPI in the IPsec header [RFC-4306] of the
considerations must be applied. received packet is needed for locating the security association,
for authenticating the Proxy Binding Update message.
1. The local mobility anchor MUST observe the rules described in 2. The local mobility anchor MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Headers in the Section 9.2 [RFC-3775] when processing Mobility Header in the
received Proxy Binding Update request. received Proxy Binding Update request. Additionally, the rules
specified in Section 10.3 [RFC-3775] MUST be applied when
processing this message.
2. The local mobility anchor MUST identify the mobile node from the 3. The local mobility anchor MUST ignore the check, specified in
Section 10.3.1 [RFC-3775], related to the presence of Home
Address destination option in the Proxy Binding Update request.
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
send a Proxy Binding Acknowledgement message with Status field send a Proxy Binding Acknowledgement message with Status field
set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node
identifier) and the identifier in the Mobile Node Identifier identifier option) and the identifier in the Mobile Node
Option MUST be set to a zero length identifier. Identifier Option carried in the message MUST be set to a zero
length identifier.
3. If the local mobility anchor cannot authorize the mobile node 5. The local mobility anchor MUST apply the required policy checks,
based on the Mobile Node Identifier option [RFC-4283] present in as explained in Section 4.0, to verify the sender is a trusted
the request, it MUST reject the Proxy Binding Update request and mobile access gateway, authorized to send Proxy Binding Update
send a Proxy Binding Acknowledgement message with Status field requests on behalf of this mobile node.
set to 133 (Not home agent for this mobile node).
4. If the local mobility anchor determines that the mobile node is 6. If the local mobility anchor determines that the requesting node
is not authorized to send Proxy Binding Update requests for the
identified mobile node, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to
MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy
binding registrations).
7. If the local mobility anchor cannot identify the mobile node
based on the identifier present in the Mobile Node Identifier
option [RFC-4283] of Proxy Binding Update request, it MUST
reject the request and send a Proxy Binding Acknowledgement
message with Status field set to 133 (Not local mobility anchor
for this mobile node).
8. If the local mobility anchor determines that the mobile node is
not authorized for the network-based mobility management not authorized for the network-based mobility management
service, it MUST reject the request and send a Proxy Binding service, it MUST reject the request and send a Proxy Binding
Acknowledgement message with Status field set to Acknowledgement message with Status field set to
PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).
5. The local mobility anchor MUST ignore the check, specified in 9. The local mobility anchor MUST apply the considerations
Section 10.3.1 [RFC-3775], related to the presence of Home specified in Section 5.5, for processing the Sequence Number
Address destination option in the Proxy Binding Update request. field and the Timestamp option (if present), in the Proxy
Binding Update request.
6. The local mobility anchor MUST authenticate the Proxy Binding
Update request as described in Section 4.0. When IPsec is used
for message authentication, the SPI in the IPsec header [RFC-
4306] of the received packet is needed for locating the security
association, for authenticating the Proxy Binding Update
request.
7. The local mobility anchor MUST apply the required policy checks,
as explained in Section 4.0, to verify the sender is a trusted
mobile access gateway, authorized to send Proxy Binding Update
requests on behalf of this mobile node.
8. If the local mobility anchor determines that the requesting node 10. If the Home Network Prefix option (containing either ALL_ZERO or
is not authorized to send Proxy Binding Update requests, it MUST some prefix value) is not present in the Proxy Binding Update
reject the request and send a Proxy Binding Acknowledgement request, the local mobility anchor MUST reject the request and
message with Status field set to send a Proxy Binding Acknowledgement message with Status field
MAG_NOT_AUTHORIZED_FOR_PROXY_REG (Not authorized to send proxy set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network
registrations). prefix option).
9. If the Home Network Prefix option is not present in the Proxy 11. If the Handoff Indicator option is not present in the Proxy
Binding Update request, the local mobility anchor MUST reject Binding Update request, the local mobility anchor MUST reject
the request and send a Proxy Binding Acknowledgement message the request and send a Proxy Binding Acknowledgement message
with Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION with Status field set to MISSING_HANDOFF_INDICATOR_OPTION
(Missing mobile node's home network prefix option). (Missing handoff indicator option).
10. If the Access Technology Type option is not present in the Proxy 12. If the Access Technology Type option is not present in the Proxy
Binding Update request, the local mobility anchor MUST reject Binding Update request, the local mobility anchor MUST reject
the request and send a Proxy Binding Acknowledgement message the request and send a Proxy Binding Acknowledgement message
with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION
(Missing mobile node's access technology type). (Missing access technology type option).
11. The local mobility anchor MUST apply the considerations 13. Considerations specified in Section 5.4.1 MUST be applied for
specified in Section 5.5, for processing the Sequence Number performing the Binding Cache entry existence test. If those
field and the Timestamp option, in the Proxy Binding Update checks specified in Section 5.4.1, result in associating the
request. received Proxy Binding Update request to a new mobility session
creation request, considerations from Section 5.3.2 (Initial
Binding Registration - New Mobility Session), MUST be applied.
If those checks result in associating the request to an existing
mobility session, the following checks determine the next set of
processing rules that needs to be applied.
12. The local mobility anchor MUST use the identifier from the * If the Handoff Indicator field in the Handoff Indicator
Mobile Node Identifier Option [RFC-4283] present in the Proxy option present in the request is set to a value of 5 (Handoff
Binding Update request and MUST apply multihoming considerations state not changed), considerations from Section 5.3.3
specified in Section 5.4 for performing the Binding Cache entry (Binding Lifetime Extension- No handoff) MUST be applied.
existence test or for identifying the mobility session. If the
entry does not exist, the local mobility anchor MUST consider
this request as an initial binding registration request. If the
entry exists, the local mobility anchor MUST consider this
request as a binding re-registration request. However, from the
perspective of the mobile access gateway that sent the request,
this binding re-registration request may be an initial Binding
Update request after the mobile node's attachment to that mobile
access gateway.
Initial Binding Registration: * If the received Proxy Binding Update request has the lifetime
value of zero, considerations from Section 5.3.5 (Binding De-
Registration) MUST be applied.
* For all other cases, considerations from Section 5.3.4
(Binding Lifetime Extension - After handoff) MUST be applied.
14. When sending the Proxy Binding Acknowledgement message with any
Status field value, the message MUST be constructed as specified
in Section 5.3.6.
5.3.2. Initial Binding Registration (New Mobility Session)
1. If the Home Network Prefix option present in the Proxy Binding 1. If the Home Network Prefix option present in the Proxy Binding
Update request has the value 0::/0, the local mobility anchor Update request has the value set to ALL_ZERO, the local mobility
SHOULD allocate a prefix for the mobile node and send a Proxy anchor MUST allocate a prefix and assign it to a new mobility
Binding Acknowledgement message including the Home Network Prefix session created for the mobile node. The local mobility anchor
option containing the allocated prefix value. The local mobility MUST ensure the allocated prefix is not in use by any other node
anchor MUST ensure the allocated prefix is not in use by any or mobility session.
other node.
2. If the local mobility anchor is unable to allocate a home network 2. If the local mobility anchor is unable to allocate any home
prefix for the mobile node, it MUST reject the request and send a network prefix for the mobile node, it MUST reject the request
Proxy Binding Acknowledgement message with Status field set to and send a Proxy Binding Acknowledgement message with Status
130 (Insufficient resources). field set to 130 (Insufficient resources).
3. If the Home Network Prefix option present in the request has a 3. If the Home Network Prefix option present in the request has a
specific prefix hint, the local mobility anchor before accepting specific prefix hint, the local mobility anchor before accepting
that request, MUST ensure the prefix is owned by the local that request, MUST ensure the prefix is owned by the local
mobility anchor and further the mobile node is authorized to use mobility anchor and further the mobile node is authorized to use
that prefix. If the mobile node is not authorized to use that that prefix. If the mobile node is not authorized to use that
prefix, the local mobility anchor MUST reject the request and prefix, the local mobility anchor MUST reject the request and
send a Proxy Binding Acknowledgement message with Status field send a Proxy Binding Acknowledgement message with Status field
set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not
authorized to use that prefix). authorized to use that prefix).
4. Upon accepting the request, the local mobility anchor MUST create 4. Upon accepting the request, the local mobility anchor MUST create
a Binding Cache entry for the mobile node. It must set the a Binding Cache entry for the mobile node. It must set the
fields in the Binding Cache entry to the accepted values for that fields in the Binding Cache entry to the accepted values for that
binding. If there is a Link-local Address option present in the registration.
request, the address must be copied to the link-local address
field in the Binding Cache entry.
5. Upon accepting the Proxy Binding Update request, the local 5. The local mobility anchor MUST establish a bi-directional tunnel
mobility anchor MUST establish a bi-directional tunnel to the to the mobile access gateway (if there does not exist one) that
mobile access gateway, as described in [RFC-2473]. sent the request and setup the routing state. Considerations
Considerations from Section 5.6 must be applied. from Section 5.6 MUST be applied for creating the routing state.
Binding Re-Registration: 6. The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6.
1. If the requesting prefix in the Home Network Prefix option is a 5.3.3. Binding Lifetime Extension (No handoff)
non 0::/0 value and is different from what is present in the
currently active Binding Cache entry for that mobile node, the
local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to 129
(Administratively Prohibited).
2. If there is a Link-local Address option present in the request 1. Upon accepting the Proxy Binding Update request for extending the
with a value other than ALL_ZERO (not set), and upon accepting binding lifetime, received from the same mobile access gateway
the binding re-registration request, the local mobility anchor that last updated the binding (i.e., when there is no handoff),
MUST update the link-local address field in the Binding Cache the local mobility anchor MUST update the Binding Cache entry
entry to the address value received in the request. with the accepted registration values. However, if the link-
local address value in the Link-local address option is ALL_ZERO
value, the link-local address field in the Binding Cache entry
MUST NOT be updated.
3. Upon accepting a Proxy Binding Update request for extending the 2. The local mobility anchor MUST send the Proxy Binding
lifetime of a currently active binding for a mobile node, the Acknowledgement message with the Status field set to 0 (Proxy
local mobility anchor MUST update the existing Binding Cache Binding Update Accepted). The message MUST be constructed as
entry for this mobile node. Unless there exists an established specified in Section 5.3.6.
bi-directional tunnel to the mobile access gateway with the same
transport and encapsulation mode, the local mobility anchor MUST
create a tunnel to the mobile access gateway, as described in
[RFC-2473] and also delete the existing tunnel route to the
previous mobile access gateway. It MUST also send a Proxy
Binding Acknowledgement message to the mobile access gateway with
the Status field set to 0 (Proxy Binding Update Accepted).
Binding De-Registration: 5.3.4. Binding Lifetime Extension (After handoff)
1. Upon accepting the Proxy Binding Update request for extending the
binding lifetime, received from a new mobile access gateway where
the mobile node's session is handed off, the local mobility
anchor MUST update the Binding Cache entry with the accepted
registration values. However, if the link-local address value in
the Link-local address option is ALL_ZERO value, the link-local
address field in the Binding Cache entry MUST NOT be updated.
2. The local mobility anchor MUST remove the previously created
route for the mobile node's home network prefix. Additionally,
if there are no other mobile node's sessions sharing the tunnel
to the previous mobile access gateway, the tunnel MUST be
deleted.
3. The local mobility anchor MUST establish a bi-directional tunnel
to the mobile access gateway that sent the request.
Considerations from Section 5.6 MUST be applied for creating the
routing state.
4. The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6.
5.3.5. Binding De-Registration
1. If the received Proxy Binding Update request with the lifetime 1. If the received Proxy Binding Update request with the lifetime
value of zero and the prefix in the Home Network Prefix option is value of zero, has a Source Address in the IPv6 header (or the
a non 0::/0 value and is different from what is present in the address in the Alternate Care-of Address option, if the option is
currently active Binding Cache entry for that mobile node, the present) different from what is present in the Proxy-CoA address
local mobility anchor MUST reject the request and send a Proxy field in the Binding Cache entry, the local mobility anchor MUST
Binding Acknowledgement message with Status field set to 129 ignore the request.
(Administratively Prohibited).
2. If the received Proxy Binding Update request with the lifetime 2. Upon accepting the Proxy Binding Update request with the lifetime
value of zero, has a Source Address in the IPv6 header different value of zero, the local mobility anchor MUST wait for
from what is present in the Proxy-CoA address field in the MinDelayBeforeBCEDelete amount of time, before it deletes the
Binding Cache entry existing for that mobile node, the local Binding Cache entry. However, it MUST send the Proxy Binding
mobility anchor SHOULD ignore the request. Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as
specified in Section 5.3.6.
3. Upon accepting the Proxy Binding Update request for a mobile * During this wait period, the local mobility anchor SHOULD drop
node, with the lifetime value of zero, the local mobility anchor the mobile node's data traffic.
MUST wait for MinDelayBeforeBCEDelete amount of time, before it
deletes the mobile node's Binding Cache entry. Within this wait
period, if the local mobility anchor receives a Proxy Binding
Update request message for the same mobile node with the lifetime
value of greater than zero, and if that request is accepted, then
the Binding Cache entry MUST NOT be deleted, but must be updated
with the newly accepted registration values. The local mobility
anchor MUST send the Proxy Binding Acknowledgement message,
immediately upon accepting the request. However, within this
wait period, if the local mobility anchor does not receive any
valid binding registration request for that mobile node, then at
the end of this wait period, it MUST delete the mobile node's
Binding Cache entry and remove the routing state created for that
mobile node. In addition, during this MinDelayBeforeBCEDelete
wait period, the local mobility anchor MUST continue to route the
mobile node's data traffic.
Constructing the Proxy Binding Acknowledgement Message: * During this wait period, if the local mobility anchor receives
a valid Proxy Binding Update request for the same mobility
session with the lifetime value of greater than zero, and if
that request is accepted, then the Binding Cache entry MUST
NOT be deleted, but must be updated with the newly accepted
registration values and additionally the wait period should be
ended.
* By the end of this wait period, if the local mobility anchor
did not receive any valid Proxy Binding Update request for
this mobility session, then it MUST delete the Binding Cache
entry and remove the routing state created for that mobility
session.
5.3.6. Constructing the Proxy Binding Acknowledgement Message
o The local mobility anchor when sending the Proxy Binding o The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST Acknowledgement message to the mobile access gateway MUST
construct the message as specified below. construct the message as specified below.
IPv6 header (src=LMAA, dst=Proxy-CoA) IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header Mobility header
-BA /*P flag is set*/ - BA /* P flag must be set */
Mobility Options Mobility Options
- Home Network Prefix Option - Mobile Node Identifier Option (mandatory)
- Link-local Address Option (optional) - Home Network Prefix option (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp Option (optional) - Timestamp Option (optional)
- Mobile Node Identifier Option (Mandatory) - Mobile Node Interface Identifier option (optional)
- Access Technology Type option (Mandatory) - Link-local Address option (optional)
- Mobile Node Interface Identifier option
(Optional)
Figure 6: Proxy Binding Acknowledgement message format Figure 6: Proxy Binding Acknowledgement message format
o The Source Address field in the IPv6 header of the message MUST be o The Source Address field in the IPv6 header of the message MUST be
set to the destination address of the received Proxy Binding set to the destination address of the received Proxy Binding
Update request. Update request.
o The Destination Address field in the IPv6 header of the message o The Destination Address field in the IPv6 header of the message
MUST be set to the source address of the received Proxy Binding MUST be set to the source address of the received Proxy Binding
Update request. Update request. When there is no Alternate Care-of Address option
present in the request, the destination address is the same as the
Proxy-CoA address, otherwise, the address may not be the same as
the Proxy-CoA.
o The Home Network Prefix option MUST be present in the Proxy o The Mobile Node Identifier option [RFC-4283] MUST be present. The
Binding Acknowledgement message. If the option was not present in identifier field in the option MUST be copied from the Mobile Node
the request and if the Status field value is set to Identifier option in the received Proxy Binding Update request.
MISSING_HOME_NETWORK_PREFIX_OPTION, the value MUST be set to If the option was not present in the request, the identifier in
the option MUST be set to a zero length identifier.
o The Home Network Prefix option MUST be present.
* If the Status field is set to a value greater than or equal to
128, i.e., if the binding request is rejected, then the prefix
value in the Home Network Prefix option MUST be set to the
prefix value in the Home Network Prefix option of the received
Proxy Binding Update request. But, if the option was not
present in the request, the value in the option MUST be set to
ALL_ZERO. ALL_ZERO.
* For all other cases, the prefix value in the option MUST be set
to the allocated prefix value for that mobility session.
o The Handoff Indicator option MUST be present. The handoff
indicator field in the option MUST be copied from the Handoff
Indicator option in the received Proxy Binding Update request. If
the option was not present in the request, the value in the option
MUST be set to zero.
o The Access Technology Type option MUST be present. The access o The Access Technology Type option MUST be present. The access
technology type value in the option MUST be copied from the Access technology type field in the option MUST be copied from the Access
Technology Type option in the received Proxy Binding Update Technology Type option in the received Proxy Binding Update
request. If the option was not present in the request and if the request. If the option was not present in the request, the value
Status field value is set to MISSING_ACCESS_TECH_TYPE_OPTION, the in the option MUST be set to zero.
value MUST be set to 0.
o The Mobile Node Interface Identifier option MAY be present, if the
same option was present in the corresponding Proxy Binding Update
request message.
o If the Status field is set to a value greater than or equal to o The Timestamp option MUST be present, if the same option was
128, i.e., if the binding request was rejected, then the prefix present in the received Proxy Binding Update request.
value in the Home Network Prefix option MUST be set to the prefix Considerations from Section 5.5 must be applied for constructing
value from the received Home Network Prefix option. For all other the Timestamp option.
cases, the prefix value MUST be set to the allocated prefix value
for that mobile node.
o The Link-local Address option MUST be present in the Proxy Binding o The Mobile Node Interface Identifier option MUST be present, if
Acknowledgement message if and only if the same option was present the same option was present in the received Proxy Binding Update
in the corresponding Proxy Binding Update request message. request. The interface identifier value MUST be copied from the
Mobile Node Interface Indicator option present in the received
Proxy Binding Update request.
o If the Status field is set to a value greater than or equal to o The Link-local Address option MUST be present, if the same option
128, i.e., if the binding request was rejected, then the link- was present in the received Proxy Binding Update request.
local address value in the Link-local Address option MUST be set
to the value from the received Link-local Address option.
o If there is an existing Binding Cache entry for the mobile node * If the received Proxy Binding Update request has the Link-local
with the link-local address value of ALL_ZERO (value not set), or Address option with any value other than ALL_ZERO, the same
if there was no existing Binding Cache entry, then the link-local value MUST be copied to the Link-local Address option in the
address MUST be copied from the Link-local Address option in the reply.
received Proxy Binding Update request. For all other cases, it
MUST be copied from the mobile node's Binding Cache entry.
o Considerations from Section 5.5 must be applied for constructing * If there is no existing Binding Cache entry (i.e., if this is a
the Timestamp option. request for a new mobility session), or if there is an existing
Binding Cache entry with the link-local address value set to
ALL_ZERO, then the link-local address in the option MUST be
copied from the Link-local Address option present in the
received Proxy Binding Update request.
o The identifier in the Mobile Node Identifier option [RFC-4283] * For all other cases, the link-local address in the option MUST
MUST be copied from the received Proxy Binding Update request. If be copied from the Link-local Address field of the Binding
the Status field value is set to MISSING_MN_IDENTIFIER_OPTION, the Cache entry.
identifier in the Mobile Node Identifier Option MUST be set to a
zero length identifier.
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 The Type 2 Routing header MUST NOT be present in the IPv6 header o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST
of the packet. NOT be present in the IPv6 header of the packet.
5.4. Multihoming Support 5.4. Multihoming Support
When a mobile node connects to a Proxy Mobile IPv6 domain through This specification allows mobile nodes to connect to a Proxy Mobile
multiple interfaces simultaneously, the local mobility anchor MUST IPv6 domain through multiple interfaces and for simultaneous access.
allocate a unique home network prefix for each of the connected Following are the key aspects of this multihoming support.
interfaces.
The local mobility anchor MUST manage each of the allocated home o When a mobile node connects to a Proxy Mobile IPv6 domain through
network prefixes as part of a separate mobility session, each under a multiple interfaces and for simultaneous access, the local
separate Binding Cache entry and with its own lifetime. mobility anchor MUST allocate a unique home network prefix for
each of the connected interfaces.
The local mobility anchor MUST allow for a handover between two o The local mobility anchor MUST manage each of the allocated home
network prefixes as part of a separate mobility session, each
under a separate Binding Cache entry and with its own lifetime.
o The local mobility anchor MUST allow for an handoff between two
different interfaces of the mobile node. In such a case, the home different interfaces of the mobile node. In such a case, the home
network prefix that is associated with a specific interface network prefix that is associated with a specific interface
identifier of a mobile node will be updated with the new interface identifier of a mobile node will be updated with the new interface
identifier. The decision on when to create a new mobility session identifier. The decision on when to create a new mobility session
and when to update an existing mobility session MUST be based on the and when to update an existing mobility session MUST be based on
Handover hint present in the signaling messages and under the the Handover hint present in the signaling messages and under the
considerations specified in this section. considerations specified in this section.
The local mobility anchor MUST apply the following multihoming 5.4.1. Binding Cache entry lookup considerations
considerations when processing a received Proxy Binding Update
request message.
Processing De-Registration Message: There can be multiple Binding Cache entries for a given mobile node.
When doing a lookup for a mobile node's Binding Cache entry for
processing a received Proxy Binding Update request message, the local
mobility anchor MUST apply the following multihoming considerations
(in the specified order). These rules are chained with the
processing rules specified in Section 5.3.
1. If the received Proxy Binding Update message has lifetime value 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the
of zero, the local mobility anchor MUST verify if there is an request
existing Binding Cache entry for the mobile node, identified by
the MN-Identifier and with the Proxy-CoA address matching the
source address in the IPv6 header of the received packet. If
there exists a Binding Cache entry, the local mobility anchor
MUST consider the message as a request for de-registering that
specific mobility session. If there does not exist a Binding
Cache entry, the message MUST be ignored.
Home Network Prefix Option (Non-Zero Prefix) present in the request: +=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| HNP (NON_ZERO Value) |
+=====================================================================+
| ATT |
+=====================================================================+
| IID Option Present | IID Option Not present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: (Home Network Prefix) |
+=====================================================================+
Figure 7: BCE lookup using home network prefix
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 for the mobile node, identified by the MN- Binding Cache entry with the home network prefix value matching
Identifier and with the home network prefix value matching the the prefix value in the Home Network Prefix option of the
prefix value in the Home Network Prefix Option of the request. received Proxy Binding Update request. [BCE(HNP) == PBU(HNP)]
If there is a Mobile Node Interface Identifier Option present in
the request, it MUST be ignored for this search. If there exists
a Binding Cache entry matching the specified criteria, the local
mobility anchor MUST consider the message as a request for
updating that specific mobility session. The local mobility
anchor upon accepting the request MUST update the existing
Binding Cache entry and assign the home network prefix present in
the Binding Cache entry. If there does not exist a Binding Cache
entry matching this specified criteria, the below considerations
MUST be applied.
Mobile Node Interface Identifier Option not present in the request: 2. If there does not exist a Binding Cache entry (matching the MN-
HNP), the request MUST be considered as a request for creating a
new mobility session.
1. The local mobility anchor MUST verify if there is an existing 3. If there exists a Binding Cache entry (matching MN-HNP), and if
Binding Cache entry for the mobile node, identified by the MN- the mobile node identifier in the entry does not match the mobile
Identifier and with the interface identifier value set to node identifier in the Mobile Node Identifier option of the
ALL_ZERO. received Proxy Binding Update request, the local mobility anchor
MUST reject the request with the Status field value set to
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not
authorized for the requesting home network prefix). [BCE(MN-
Identifier) != PBU(MN-Identifier)]
4. If there exists a Binding Cache entry (matching MN-Identifier and
MN-HNP) and if any one or more of these below stated conditions
match, the request MUST be considered as a request for updating
that Binding Cache entry. [BCE(MN-Identifier) == PBU(MN-
Identifier)]
2. If there does not exist a Binding Cache entry, the local mobility * If there is a Mobile Node Interface Identifier option present
anchor upon accepting the request MUST assign a new home network in the request, and if the interface identifier value in that
prefix and create a new Binding Cache entry. option matches the interface identifier value in the Binding
Cache entry and the access technology type field in the Access
Technology Type option present in the request matches the
access technology type in the Binding Cache entry . [BCE(ATT,
MN-Interface-Identifier) == PBU(ATT, MN-Interface-Identifier)]
3. If there exists a Binding Cache entry and if the Handoff * If the Handoff Indicator field in the Handoff Indicator option
Indicator field in the Access Technology Type option present in present in the request is set to a value of 2 (Handoff between
the received Proxy Binding Update message is set to value 1 two different interfaces of the mobile node).
(Attachment over a new interface), the local mobility anchor upon
accepting the request MUST assign a new home network prefix and
create a new Binding Cache entry.
4. If there exists a Binding Cache entry and if the Handoff * If there is no Mobile Node Interface Identifier option present
Indicator field in the Access Technology Type option present in in the request, the interface identifier value in the Binding
the received Proxy Binding Update message is set to either value Cache entry is set to ALL_ZERO, the access technology type
2 (Handoff between interfaces) or 3 (Handoff between mobile field in the Access Technology Type option present in the
access gateways for the same mobile node's interface), the local request matches the access technology type in the Binding
mobility anchor upon accepting the request MUST update the Cache entry and if the Handoff Indicator field in the Handoff
existing Binding Cache entry and assign the home network prefix Indicator option present in the request is set to a value of 3
present in the Binding Cache entry. (Handoff between mobile access gateways for the same
interface).
5. If there exists a Binding Cache entry and if the Handoff * If the Proxy-CoA address in the Binding Cache entry matches
Indicator field in the Access Technology Type option present in the source address of the request (or the address in the
the received Proxy Binding Update message is set to value 4 alternate Care-of Address option, if the option is present)
(Handoff state unknown), the local mobility anchor SHOULD wait and if the access technology type field in the Access
till the existing Binding Cache entry is de-registered by the Technology Type option present in the request matches the
previously serving mobile access gateway, before it assigns the access technology type in the Binding Cache entry.
same home network prefix or updates the existing Binding Cache [BCE(Proxy-CoA, ATT) == PBU(Proxy-CoA, ATT)].
entry. However, if there is no de-registration message that is
received within MinDelayBeforeNewBCEAssign amount of time, the
local mobility anchor upon accepting the request MUST assign a
new home network prefix and create a new Binding Cache entry.
The local mobility anchor MAY also choose to assign a new home
network prefix and without waiting for a de-registration message.
It can use the access technology type value present in the
request and as inputs for this decision.
6. Either upon creating a new Binding Cache entry or from matching 5. For all other cases, the message MUST be considered as a request
an existing Binding Cache entry, after applying the above for creating a new mobility session.
considerations, the access technology field in the Binding Cache
entry MUST be copied from the Access Technology type option
present in the received Proxy Binding Update message. The
interface identifier field in the Binding Cache entry MUST be set
to ALL_ZERO.
Mobile Node Interface Identifier Option present in the request: 5.4.1.2. Mobile Node Interface Identifier Option present in the request
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| HNP (ALL_ZERO Value) |
+=====================================================================+
| ATT |
+=====================================================================+
| IID Option Present (NON_ZERO Value) |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Keys: (MN-Identifier + Access Technology Type + |
| MN-Interface-Identifier) |
+=====================================================================+
Figure 8: BCE Lookup using Interface Identifier
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 for the mobile node, identified by the MN- Binding Cache entry, with the mobile node identifier matching the
Identifier and with the interface identifier value matching the identifier in the received Mobile Node Identifier option, access
identifier value present in the received Mobile Node Interface technology type matching the value in the received Access
Identifier Option. Technology Type option and the interface identifier value
matching the identifier in the received Mobile Node Interface
Identifier option. [BCE(MN-Identifier, ATT, MN-Interface-
Identifier) == PBU(MN-Identifier, ATT, MN-Interface-Identifier)]
2. If there exists a Binding Cache entry, the local mobility anchor 2. If there exists a Binding Cache entry (matching MN-Identifier,
upon accepting the request MUST update the existing Binding Cache ATT and MN-Interface-Identifier), the request MUST be considered
entry and assign the home network prefix present in the Binding as a request for updating that Binding Cache entry.
Cache entry.
3. If there does not exist a Binding Cache entry and if the Handoff 3. If there does not exist a Binding Cache entry (matching MN-
Indicator field in the Access Technology Type option present in Identifier, ATT and MN-Interface-Identifier) and the Handoff
the received Proxy Binding Update message is set to value 1 Indicator field in the Handoff Indicator option present in the
(Attachment over a new interface), the local mobility anchor upon request is set to a value of 2 (Handoff between two different
accepting the request MUST assign a new home network prefix and interfaces of the mobile node). The local mobility anchor MUST
create a new Binding Cache entry. apply the following additional considerations. [PBU(HI) == 2]
4. If there does not exist a Binding Cache entry and if the Handoff * The local mobility anchor MUST verify if there exists one and
Indicator field in the Access Technology Type option present in only one Binding Cache entry with the mobile node identifier
the received Proxy Binding Update message is set to value 2 matching the identifier in the Mobile Node Identifier option
(Handoff between interfaces), the local mobility anchor MUST present in the request and for any interface identifier value.
verify if there exists one and only one Binding Cache entry for If there exists only one such entry (matching the MN-
the mobile node, identified by the MN-Identifier and with any Identifier), the request MUST be considered as a request for
interface identifier value. If there exists such an entry, the updating that Binding Cache entry. [BCE(MN-Identifier) ==
local mobility anchor upon accepting the request MUST update the PBU(MN-Identifier)]
existing Binding Cache entry and assign the home network prefix
present in the Binding Cache entry.
5. If there does not exist a Binding Cache entry and if the Handoff 4. If there does not exist a Binding Cache entry (matching MN-
Indicator field in the Access Technology Type option present in Identifier, ATT and MN-Interface-Identifier) and if the Handoff
the received Proxy Binding Update message is set to value 2 Indicator field in the Handoff Indicator option present in the
(Handoff between interfaces), the local mobility anchor MUST request is set to a value of 4 (Handoff state unknown), the local
verify if there exists a Binding Cache entry for the mobile node, mobility anchor MUST apply the following additional
identified by the MN-Identifier and with the home network prefix considerations.
value matching the prefix value in the received Home Network
Prefix option. If there exists a Binding Cache entry, the local
mobility anchor upon accepting the request MUST assign the same
prefix, else it MUST assign a new home network prefix and create
a new Binding Cache entry.
6. If there exists a Binding Cache entry and if the Handoff * The local mobility anchor MUST verify if there exists one and
Indicator field in the Access Technology Type option present in only one Binding Cache entry with the mobile node identifier
the received Proxy Binding Update message is set to value 4 matching the identifier in the Mobile Node Identifier option
(Handoff state unknown), the local mobility anchor SHOULD wait present in the request and for any interface identifier value.
till the existing Binding Cache entry is de-registered by the If there exists only one such entry (matching the MN-
previously serving mobile access gateway. However, if there is Identifier), the local mobility anchor SHOULD wait till the
no de-registration message that is received within a given time, existing Binding Cache entry is de-registered by the
the local mobility anchor upon accepting the request MUST assign previously serving mobile access gateway, before the request
a new home network prefix and create a new Binding Cache entry. can be considered as a request for updating that Binding Cache
The local mobility anchor MAY also choose to assign a new home entry. However, if there is no de-registration message that
network prefix and without waiting for a de-registration message. is received within MaxDelayBeforeNewBCEAssign amount of time,
the local mobility anchor upon accepting the request MUST
consider the request as a request for updating that Binding
Cache entry. The local mobility anchor MAY also choose to
create a new mobility session and without waiting for a de-
registration message.
7. Either upon creating a new Binding Cache entry or from matching 5. For all other cases, the message MUST be considered as a request
an existing Binding Cache entry, after applying the above for creating a new mobility session.
considerations, the interface identifier field in the Binding
Cache entry MUST be set to the value present in the received 5.4.1.3. Mobile Node Interface Identifier Option not present in the
Mobile Node Interface Identifier Option and the access technology request
type MUST be copied from the Access Technology type option +=====================================================================+
present in the received Proxy Binding Update message. | Registration/De-Registration Message |
+=====================================================================+
| HNP (ALL_ZERO Value) |
+=====================================================================+
| ATT |
+=====================================================================+
| IID Option Not Present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: (MN-Identifier) |
+=====================================================================+
Figure 9: BCE Lookup using Mobile Node Identifier
1. The local mobility anchor MUST verify if there exists one and
only one Binding Cache entry with the mobile node identifier
matching the identifier in the Mobile Node Identifier option
present in the request.
2. If there exists only one such entry (matching the MN-Identifier)
and the Handoff Indicator field in the Handoff Indicator option
present in the request is set to a value of 2 (Handoff between
two different interfaces of the mobile node), the request MUST be
considered as a request for updating that Binding Cache entry.
[PBU(HI) == 2]
3. If there exists only one such entry (matching the MN-Identifier)
and the Handoff Indicator field in the Handoff Indicator option
present in the request is set to a value of 4 (Handoff state
unknown), the local mobility anchor SHOULD wait till the existing
Binding Cache entry is de-registered by the previously serving
mobile access gateway, before the request can be considered as a
request for updating that Binding Cache entry. However, if there
is no de-registration message that is received within
MaxDelayBeforeNewBCEAssign amount of time, the local mobility
anchor upon accepting the request MUST consider the request as a
request for updating that Binding Cache entry. The local
mobility anchor MAY also choose to create a new mobility session
and without waiting for a de-registration message.
4. For all other cases, the message MUST be considered as a request
for creating a new mobility session.
5.5. Timestamp Option for Message Ordering 5.5. Timestamp Option for Message Ordering
Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding
registration messages as a way for the home agent to process the registration messages as a way for the home agent to process the
binding updates in the order they were sent by a mobile node. The binding updates in the order they were sent by a mobile node. The
home agent and the mobile node are required to manage this counter home agent and the mobile node are required to manage this counter
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 29, line 38 skipping to change at page 32, line 38
mobile access gateway (Ex: The timestamp option in the SEND mobile access gateway (Ex: The timestamp option in the SEND
messages that the mobile node sends), the mobile access gateway messages that the mobile node sends), the mobile access gateway
can use this timestamp or sequence number in the Proxy Binding can use this timestamp or sequence number in the Proxy Binding
Update messages and does not have to depend on any external clock Update messages and does not have to depend on any external clock
source. However, the specific details on how this is achieved is source. However, the specific details on how this is achieved is
outside the scope of this document. outside the scope of this document.
4. When generating the timestamp value for building the Timestamp 4. When generating the timestamp value for building the Timestamp
option, the mobility entities MUST ensure that the generated option, the mobility entities MUST ensure that the generated
timestamp is the elapsed time past the same reference epoch, as timestamp is the elapsed time past the same reference epoch, as
specified in the format for the Timestamp option [Section 8.7]. specified in the format for the Timestamp option [Section 8.8].
5. If the Timestamp option is present in the received Proxy Binding 5. If the Timestamp option is present in the received Proxy Binding
Update message, the local mobility anchor MUST ignore the Update message, the local mobility anchor MUST ignore the
sequence number field in the message. However, it MUST copy the sequence number field in the message. However, it MUST copy the
sequence number from the received Proxy Binding Update message to sequence number from the received Proxy Binding Update message to
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 timestamp value contained in the Timestamp option MUST be close
enough to the local mobility anchor's time-of-day clock and the enough (within TimestampValidityWindow amount of time difference)
to the local mobility anchor's time-of-day clock and the
timestamp MUST be greater than all previously accepted timestamps timestamp MUST be greater than all previously accepted timestamps
in the Proxy Binding Update messages sent for that mobile node. 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), the valid (validity as specified in the above considerations), 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 Acknowledgement Timestamp option included in the Proxy Binding Acknowledgement
message that it sends to the mobile access gateway. message that it sends to the mobile access 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 32, line 9 skipping to change at page 35, line 11
the local mobility anchor MUST forward the packet through the bi- the local mobility anchor MUST forward the packet through the bi-
directional tunnel setup for that mobile node. The format of the directional tunnel setup for that mobile node. The format of the
tunneled packet is shown below. However, when using IPv4 tunneled packet is shown below. However, when using IPv4
transport, the format of the packet is as described in [ID-IPV4- transport, the format of the packet is as described in [ID-IPV4-
PMIP6]. PMIP6].
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/ Upper layer protocols /* Packet Content*/
Figure 7: Tunneled Packets from LMA to MAG Figure 10: Tunneled Packets from LMA to MAG
Forwarding Packets Sent by the Mobile Node: Forwarding Packets Sent by the Mobile Node:
o All the reverse tunneled packets that the local mobility anchor o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner header MUST be routed to the destination specified in the inner
packet header. These routed packets will have the source address packet header. These routed packets will have the source address
field set to the mobile node's home address. field set to the mobile node's home address.
5.7. Local Mobility Anchor Address Discovery 5.7. Local Mobility Anchor Address Discovery
skipping to change at page 32, line 46 skipping to change at page 36, line 7
Dynamic Home Agent Address Discovery protocol. Dynamic Home Agent Address Discovery protocol.
In Proxy Mobile IPv6, the address of the local mobility anchor In Proxy Mobile IPv6, the address of the local mobility anchor
configured to serve a mobile node can be discovered by the mobility configured to serve a mobile node can be discovered by the mobility
entities in other ways. This may be a configured entry in the mobile entities in other ways. This may be a configured entry in the mobile
node's policy profile, or it may be obtained through mechanisms node's policy profile, or it may be obtained through mechanisms
outside the scope of this document. outside the scope of this document.
5.8. Mobile Prefix Discovery Considerations 5.8. Mobile Prefix Discovery Considerations
The ICMP Mobile Prefix Advertisement message, described in Section This specification does not support mobile prefix discovery. The
6.8 and Section 11.4.3 of [RFC-3775], allows a home agent to send a mobile prefix discovery mechanism as specified in [RFC-3775] is not
Mobile Prefix Advertisement to the mobile node. applicable to Proxy Mobile IPv6.
In Proxy Mobile IPv6, the mobile node's home network prefix is hosted
on the access link connected to the mobile access gateway, but it is
topologically anchored on the local mobility anchor. Since there is
no physical home-link for the mobile node's home network prefix on
the local mobility anchor and as the mobile node is always on the
link where the prefix is hosted, any prefix change messages can just
be advertised by the mobile access gateway on the access link and
thus there is no applicability of this message for Proxy Mobile IPv6.
Hence, this specification does not support Mobile Prefix Discovery.
5.9. Route Optimizations Considerations 5.9. Route Optimizations 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 In Proxy Mobile IPv6, the mobile node is not involved in any IP
mobility related signaling. The mobile node uses only its home mobility related signaling. The mobile node uses only its home
address for all its communication and the Care-of address (Proxy-CoA) address for all its communication and the Care-of address (Proxy-CoA)
is not visible to the mobile node. Hence, the Return Routability is not visible to the mobile node. Hence, the Return Routability
procedure as defined in Mobile IPv6 cannot be used in Proxy Mobile procedure as defined in Mobile IPv6 [RFC-3775] cannot be used in
IPv6. 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 on its access link and sending the binding mobile node's movements to and from the access link and sending the
registration requests to the local mobility anchor. In essence, the binding registration requests to the local mobility anchor. In
mobile access gateway performs mobility management on behalf of a essence, the mobile access gateway performs mobility management on
mobile node. behalf of a mobile node.
The mobile access gateway is a function that typically runs on an The mobile access gateway is a function that typically runs on an
access router. However, implementations MAY choose to split this access router. However, implementations MAY choose to split this
function and run it across multiple systems. The specifics on how function and run it across multiple systems. The specifics on how
that is achieved or the signaling interactions between those that is achieved or the signaling interactions between those
functional entities are beyond the scope of this document. functional entities are beyond the scope of this document.
The mobile access gateway has the following key functional roles: The mobile access gateway has the following key functional roles:
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
skipping to change at page 34, line 35 skipping to change at page 37, line 31
o The Identifier of the attached mobile node, MN-Identifier. This o The Identifier of the attached mobile node, MN-Identifier. This
identifier is acquired during the mobile node's attachment to the identifier is acquired during the mobile node's attachment to the
access link through mechanisms outside the scope of this document. access link through mechanisms outside the scope of this document.
o The interface identifier of the mobile node's connected interface. o The interface identifier of the mobile node's connected interface.
This address can be acquired from the received Router Solicitation This address can be acquired from the received Router Solicitation
messages from the mobile node or during the mobile node's messages from the mobile node or during the mobile node's
attachment to the access network. This is typically a Layer-2 attachment to the access network. This is typically a Layer-2
identifier conveyed by the mobile node; however, the specific identifier conveyed by the mobile node; however, the specific
details on how that is conveyed is out of scope for this details on how that is conveyed is out of scope for this
specification. specification. If this identifier is not available, the value
MUST be set to ALL_ZERO.
o The IPv6 home network prefix of the attached mobile node. The o The IPv6 home network prefix of the attached mobile node. The
home network prefix of the mobile node is acquired from the mobile home network prefix of the mobile node is acquired from the mobile
node's local mobility anchor through the received Proxy Binding node's local mobility anchor through the received Proxy Binding
Acknowledgement messages. The IPv6 home network prefix also Acknowledgement messages. The IPv6 home network prefix also
includes the corresponding prefix length. includes the corresponding prefix length.
o The Link-local address of the mobile node on the interface o The Link-local address of the mobile node on the interface
attached to the access link. attached to the access link.
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 access link where the o The interface identifier (If-Id) of the access link where the
mobile node is currently attached. This is internal to the mobile mobile node is currently attached. This is internal to the mobile
access gateway and is used to associate the Proxy Mobile IPv6 access gateway and is used to associate the Proxy Mobile IPv6
tunnel to the right access link where the mobile node is attached. tunnel to the access link where the mobile node is attached.
o The interface identifier (If-Id) of the bi-directional tunnel o The interface identifier (If-Id) of the bi-directional tunnel
between the mobile node's local mobility anchor and the mobile between the mobile node's local mobility anchor and the mobile
access gateway. This is internal to the mobile access gateway. access gateway. This is internal to the mobile access gateway.
The tunnel interface identifier is acquired during the tunnel The tunnel interface identifier is acquired during the tunnel
creation. 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
skipping to change at page 35, line 38 skipping to change at page 38, line 36
The following are the mandatory fields of the policy profile: The following are the mandatory fields of the policy profile:
o The mobile node's identifier (MN-Identifier) o The mobile node's identifier (MN-Identifier)
o The IPv6 address of the local mobility anchor (LMAA) o The IPv6 address of the local mobility anchor (LMAA)
The following are the optional fields of the policy profile: The following are the optional fields of the policy profile:
o The mobile node's IPv6 home network prefix (MN-HNP) o The mobile node's IPv6 home network prefix (MN-HNP)
o The mobile node's IPv6 home network Prefix lifetime
o Supported address configuration procedures (Stateful, Stateless or o Supported address configuration procedures (Stateful, Stateless or
both) on the access links 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. This protocol may also be used on other have multicast capability. This protocol may also be used on other
link types, as long as the link is configured in such a way that it link types, as long as the link is configured in such a way that it
guarantees a point-to-point delivery between the mobile node and the guarantees a point-to-point delivery between the mobile node and the
mobile access gateway for all the protocol traffic. mobile access gateway for all the protocol traffic.
6.4. Supported Address Configuration Models 6.4. Supported Address Configuration Modes
A mobile node in the Proxy Mobile IPv6 domain can configure one or A mobile node in the Proxy Mobile IPv6 domain can configure one or
more IPv6 addresses on its interface using Stateless or Stateful more IPv6 addresses on its interface using Stateless or Stateful
address autoconfiguration procedures. The Router Advertisement address autoconfiguration procedures. The Router Advertisement
messages sent on the access link specify the address configuration messages sent on the access link specify the address configuration
methods permitted on that access link for that mobile node. However, methods permitted on that access link for that mobile node. However,
the advertised flags with respect to the address configuration will the advertised flags with respect to the address configuration will
be consistent for a mobile node, on any of the access links in that be consistent for a mobile node, on any of the access links in that
Proxy Mobile IPv6 domain. Typically, these configuration settings Proxy Mobile IPv6 domain. Typically, these configuration settings
will be based on the domain wide policy or based on a policy specific will be based on the domain wide policy or based on a policy specific
to each mobile node. to each mobile node.
When stateless address autoconfiguration is supported on the link, When stateless address autoconfiguration is supported on the access
the mobile node can generate one or more IPv6 addresses by combining link, the mobile node can generate one or more IPv6 addresses by
the network prefix advertised on the access link with an interface standard IPv6 mechanisms such as Stateless Autoconfiguration
identifier, using the techniques described in Stateless specification [RFC-4862] or Privacy extension specification [RFC-
Autoconfiguration specification [RFC-4862] or as per Privacy 4941].
extension specification [RFC-4941].
When stateful address autoconfiguration is supported on the link, the When stateful address autoconfiguration is supported on the link, the
mobile node can obtain the address configuration from the DHCPv6 mobile node can obtain the address configuration from the DHCPv6
server using DHCPv6 client protocol, as specified in DHCPv6 server by standard DHCPv6 mechanisms, as specified in DHCPv6
specification [RFC-3315]. specification [RFC-3315].
Additionally, other address configuration mechanisms specific to the Additionally, other address configuration mechanisms specific to the
access link between the mobile node and the mobile access gateway may access link between the mobile node and the mobile access gateway may
also be used for pushing the address configuration to the mobile also be used for pushing the address configuration to the mobile
node. node. This specification does not change the behavior of address
configuration mechanisms in any way.
6.5. Access Authentication & Mobile Node Identification 6.5. Access Authentication & Mobile Node Identification
When a mobile node attaches to an access link connected to the mobile When a mobile node attaches to an access link connected to the mobile
access gateway, the deployed access security protocols on that link access gateway, the deployed access security protocols on that link
SHOULD ensure that the network-based mobility management service is SHOULD ensure that the network-based mobility management service is
offered only after authenticating and authorizing the mobile node for offered only after authenticating and authorizing the mobile node for
that service. The exact specifics on how this is achieved or the that service. The exact specifics on how this is achieved or the
interactions between the mobile access gateway and the access interactions between the mobile access gateway and the access
security service is outside the scope of this document. This security service is outside the scope of this document. This
specification goes with the stated assumption of having an specification goes with the stated assumption of having an
established trust between the mobile node and mobile access gateway, established trust between the mobile node and the mobile access
before the protocol operation begins. gateway, before the protocol operation begins.
6.6. Acquiring Mobile Node's Identifier 6.6. Acquiring Mobile Node's Identifier
All the network entities in a Proxy Mobile IPv6 domain MUST be able All the network entities in a Proxy Mobile IPv6 domain MUST be able
to identify a mobile node, using its MN-Identifier. This identifier to identify a mobile node, using its MN-Identifier. This identifier
MUST be stable across the Proxy Mobile IPv6 domain and the entities MUST be stable across the Proxy Mobile IPv6 domain and the entities
must be able to use this identifier in the signaling messages. must be able to use this identifier in the signaling messages.
Typically, this identifier is obtained as part of the access Typically, this identifier is obtained as part of the access
authentication or through other means as specified below. authentication or through other means as specified below.
o The identifier of the mobile node that the mobile access gateway o The identifier of the mobile node that the mobile access gateway
obtains typically as part of the access authentication or from the obtains typically as part of the access authentication or from the
notified network attachment event, can be a temporary identifier notified network attachment event, can be a temporary identifier
and this identifier may also change at each re-authentication. and further that temporary identifier may be different at each re-
However, the mobile access gateway MUST be able to use this authentication. The mobile access gateway MUST be able to use
identifier and obtain the mobile node's MN-Identifier from the this temporary identifier and obtain the mobile node's stable
policy store, such as from the RADIUS attribute, Chargeable-User- identifier from the policy store. For instance, in AAA-based
Identifier [RFC-4372]. systems the RADIUS attribute, Chargeable-User-Identifier [RFC-
4372] may be used.
o The MN-Identifier that the policy store delivers to the mobile o The MN-Identifier that the policy store delivers to the mobile
access gateway may not be the true identifier of the mobile node. access gateway may not be the true identifier of the mobile node.
However, the mobility access gateway MUST be able to use this However, the mobility access gateway MUST be able to use this
identifier in the signaling messages exchanged with the local identifier in the signaling messages exchanged with the local
mobility anchor. mobility anchor.
o The mobile access gateway MUST be able identify the mobile node by o The mobile access gateway MUST be able to identify the mobile node
its MN-Identifier and it MUST be able to associate this identity by its MN-Identifier and it MUST be able to associate this
to the sender of any IPv4 or IPv6 packets on the access link. identity to the point-to-point link sharing with the mobile node.
6.7. Home Network Emulation 6.7. Home Network Emulation
One of the key functions of a mobile access gateway is to emulate the One of the key functions of a mobile access gateway is to emulate the
mobile node's home network on the access link. It must ensure, the mobile node's home network on the access link. It must ensure, the
mobile node believes it is still connected to its home link or on the mobile node believes it is still connected to its home link or on the
link where it obtained its initial address configuration after it link where it obtained its initial address configuration after it
moved into that Proxy Mobile IPv6 domain. moved into that Proxy Mobile IPv6 domain.
For emulating the mobile node's home link on the access link, the For emulating the mobile node's home link on the access link, the
skipping to change at page 38, line 21 skipping to change at page 41, line 22
A mobile node in the Proxy Mobile IPv6 domain, as it moves from one A mobile node in the Proxy Mobile IPv6 domain, as it moves from one
mobile access gateway to the other, will continue to detect its home mobile access gateway to the other, will continue to detect its home
network and thus making it believe it is still on the same link. network and thus making it believe it is still on the same link.
Every time the mobile node attaches to a new link, the event related Every time the mobile node attaches to a new link, the event related
to the interface state change will trigger the mobile node to perform to the interface state change will trigger the mobile node to perform
DAD operation on the link-local and global addresses. However, if DAD operation on the link-local and global addresses. However, if
the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may
not detect the link change due to DNAv6 optimizations and may not not detect the link change due to DNAv6 optimizations and may not
trigger the duplicate address detection (DAD) procedure for trigger the duplicate address detection (DAD) procedure for
establishing the link-local address uniqueness on that new link. establishing the link-local address uniqueness on that new link.
Further, if the mobile node uses an interface identifier that is not This leaves a room for link-local address collision between the two
based on EUI-64 identifier, such as specified in IPv6 Stateless
Autoconfiguration specification [RFC-4862], there is a very low
possibility of a link-local address collision between the two
neighbors on that access link. neighbors on that access link.
For solving this problem, this specification allows the mobile access For solving this problem, this specification allows the mobile access
gateway to upload the mobile node's link-local address to the local gateway to upload the mobile node's link-local address to the local
mobility anchor using the Link-local Address option, exchanged in the mobility anchor using the Link-local Address option, exchanged in the
binding registration messages. The mobile access gateway can learn binding registration messages. The mobile access gateway can learn
the mobile node's link-local address, by snooping the DAD messages the mobile node's link-local address, by snooping the DAD messages
sent by the mobile node for establishing the link-local address sent by the mobile node for establishing the link-local address
uniqueness on the access link. Subsequently, at each handoff, the uniqueness on the access link. Subsequently, at each handoff, the
mobile access gateway can obtain this address from the local mobility mobile access gateway can obtain this address from the local mobility
anchor to ensure link-local address uniqueness and change its own anchor to ensure link-local address uniqueness and change its own
link-local address, if it detects a collision. link-local address, if it detects a collision.
Alternatively, one of the workarounds for this issue is to set the Alternatively, one of the workarounds for this issue is to set the
DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that
will force the mobile node to redo DAD operation on the global and will force the mobile node to redo DAD operation on the global and
link-local addresses every time the interface detects a handover, link-local addresses every time the interface detects an handoff,
even when DNAv6 does not detect a link change. even when DNAv6 does not detect a link change.
However, this issue will not impact point-to-point links based on a However, this issue may not impact point-to-point links based on PPP.
PPP session. Each time the mobile node moves and attaches to a new Each time the mobile node moves and attaches to a new mobile access
mobile access gateway, either the PPP session [RFC-1661] is gateway, the PPP session [RFC-1661] can be re-established, or if
reestablished or the PPP session may be moved as part of context there are context transfer procedures in place, the entire PPP
transfer procedures between the old and the new mobile access session can be moved to the new link and the link-local addresses of
gateway. both the peers will continue to remain the same. In either of these
approaches, the link-local address uniqueness on the link is assured.
When the mobile node tries to establish a PPP session with the mobile The specific details of how the PPP session is re-established without
access gateway, the PPP goes through the Network layer Protocol phase impacting any layer-3 sessions or how the PPP session can be moved
and the IPv6 Control Protocol, IPV6CP [RFC-5072] gets triggered. between the mobile access gateways is outside the scope of this
Both the PPP peers negotiate a unique identifier using Interface- document.
Identifier option in IPV6CP and the negotiated identifier is used for
generating a unique link-local address on that link. Now, if the
mobile node moves to a new mobile access gateway, the PPP session
gets torn down with the old mobile access gateway and a new PPP
session gets established with the new mobile access gateway, and the
mobile node obtains a new link-local address. So, even if the mobile
node is DNAv6 capable, the mobile node always configures a new link-
local address whenever it moves to a new link.
If the PPP session state is moved to the new mobile access gateway as
part of context transfer procedures that are in place, there will not
be any change to the interface identifiers of the two nodes on that
point-to-point change. The whole link is moved to the new mobile
access gateway and there will not be any need for establishing link-
local address uniqueness on that link.
The issue of address collision is not relevant to the mobile node's The issue of address collision is not relevant to the mobile node's
global address. Since there is a unique home network prefix assigned global address. Since there is a unique home network prefix assigned
for each mobile node, the uniqueness for the mobile node's global for each mobile node, the uniqueness for the mobile node's global
address is assured on the access link. address is assured on the access link.
6.9. Signaling Considerations 6.9. Signaling Considerations
6.9.1. Binding Registrations 6.9.1. Binding Registrations
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
management service needs to be offered to the mobile node, it management service needs to be offered to the mobile node, it
MUST send a Proxy Binding Update message to the local mobility MUST send a Proxy Binding Update message to the local mobility
anchor. If there is no existing Binding Update List entry for anchor.
that mobile node, the mobile access gateway MUST create a
Binding Update List entry upon sending the Proxy Binding Update
request.
2. The Proxy Binding Update message MUST include the Mobile Node 2. The Proxy Binding Update message MUST include the Mobile Node
Identifier option [RFC-4283], identifying the mobile node, the Identifier option [RFC-4283], carrying the MN-Identifier for
Home Network Prefix option, either the Timestamp option or a identifying the mobile node.
valid sequence number and optionally the Link-local Address
option. When Timestamp option is added to the message, the
mobile access gateway MAY set the Sequence Number field to a
value of a monotonically increasing counter and the local
mobility anchor will ignore this field, but will return the same
value in the Proxy Binding Acknowledgement message. This will
be useful for matching the reply to the request message.
3. The Home Address option MUST NOT be present in the Destination 3. The Home Network Prefix option MUST be present in the Proxy
Option extension header of the Proxy Binding Update message. Binding Update message. If the mobile access gateway learns the
mobile node's home network prefix either from its policy store
or from other means, the mobile access gateway MAY choose to
specify the same in the Home Network Prefix option for
requesting the local mobility anchor to allocate that prefix,
otherwise it MUST specify a value of ALL_ZERO. If the specified
value is ALL_ZERO, then the local mobility anchor will do the
prefix assignment.
4. The Access Technology Type option MUST be present in the Proxy 4. The Handoff Indicator option MUST be present in the Proxy
Binding Update message. The access technology Type field in the Binding Update message. The Handoff Indicator field in the
option MUST be set to the access technology using which the Handoff Indicator option MUST be set to a value indicating the
mobile node is currently attached to the mobile access gateway. handoff hint. The specific details on how the mobile access
The Handoff Indicator field in the Access Technology Type option gateway determines if the mobile node's current attachment is
MUST be set to the appropriate value. The specific details on due to an handoff of an existing mobility session or if it is as
how the mobile access gateway is able to determine if the mobile a result of an attachment over a different interface is outside
node's current attachment is due to a handoff of an existing the scope of this document.
mobility session or if it is as a result of an attachment over a
different interface is outside the scope of this document.
5. The Handoff Indicator field in the Access Technology Type option * The Handoff Indicator field MUST be set to value 1
MUST be set to value 1 (Attachment over a new interface), if the (Attachment over a new interface), if the mobile access
mobile access gateway predictably knows that the mobile node's gateway predictably knows that the mobile node's current
attachment to the network using the current interface is due to attachment to the network over this interface is not as a
neither a handover between two interfaces of the mobile node nor result of an handoff of an existing mobility session (over
a handover of the mobility session for the same interface of the the same interface or through a different interface), but as
mobile node between two mobile access gateways. This a result of an attachment over a new interface. This
essentially serves as a request to the local mobility anchor to essentially serves as a request to the local mobility anchor
allocate a new home network prefix for this mobility session and to create a new mobility session and not update any existing
not update any existing Binding Cache entry created for the same Binding Cache entry created for the same mobile node
mobile node connected to the Proxy Mobile IPv6 domain through a connected to the Proxy Mobile IPv6 domain through a different
different interface. interface.
6. The Handoff Indicator field in the Access Technology Type option * The Handoff Indicator field MUST be set to value 2 (Handoff
MUST be set to value 2 (Handoff between interfaces), if the between two different interfaces of the mobile node), if the
mobile access gateway definitively knows the mobile node's mobile access gateway definitively knows the mobile node's
current attachment is due to a handoff of the mobility session current attachment is due to an handoff of an existing
between two interfaces of the mobile node. mobility session, between two different interfaces of the
mobile node.
7. The Handoff Indicator field in the Access Technology Type option * The Handoff Indicator field MUST be set to value 3 (Handoff
MUST be set to value 3 (Handoff between mobile access gateways between mobile access gateways for the same interface), if
for the same interface), if the mobile access gateway the mobile access gateway definitively knows the mobile
definitively knows the mobile node's current attachment is due node's current attachment is due to an handoff of an existing
to a handoff of the mobility session between different mobile mobility session between two mobile access gateways and for
access gateways and for the same interface of the mobile node. the same interface of the mobile node.
8. The Handoff Indicator field in the Access Technology Type option * The Handoff Indicator field MUST be set to value 4 (Handoff
MUST be set to value 4 (Handoff State Unknown), if the mobile state unknown), if the mobile access gateway cannot determine
access gateway cannot predictably know if the mobile node's if the mobile node's current attachment is due to an handoff
session is due to a handoff. of an existing mobility session.
9. The Mobile Node Interface Identifier option carrying the 5. Either the Timestamp option or a valid sequence number
identifier of the currently attached interface MUST be present maintained on a per mobile node basis (if Sequence Number based
in the Proxy Binding Update message, if the mobile access scheme is in use) MUST be present. When Timestamp option is
gateway knows the interface identifier of the mobile node's added to the message, the mobile access gateway SHOULD also set
currently attached interface. The "P" Flag in the option MUST the Sequence Number field to a value of a monotonically
be set to 0, indicating that the carried identifier is the increasing counter (not to be confused with the per mobile node
currently attached interface identifier. If the interface sequence number specified [RFC-3775]). The local mobility
identifier is not known, this identifier MUST NOT be present. anchor will ignore this field when there is a Timestamp option
present in the request, but will return the same value in the
Proxy Binding Acknowledgement message. This will be useful for
matching the reply to the request message.
10. If the mobile access gateway learns the mobile node's home 6. The Mobile Node Interface Identifier option carrying the
network prefix either from its policy store or from other means, interface identifier of the currently attached interface MUST be
the mobile access gateway MAY choose to specify the same in the present in the Proxy Binding Update message, if the mobile
Home Network Prefix option for requesting the local mobility access gateway knows the interface identifier of the mobile
anchor to allocate that prefix. If the specified value is node's currently attached interface. If the interface
0::/0, then the local mobility anchor will consider this as a identifier is not known or if the identifier value is ALL_ZERO,
request for prefix allocation. this option MUST NOT be present.
Receiving Binding Registration Reply: 7. The Access Technology Type option MUST be present in the Proxy
Binding Update message. The access technology type field in the
option SHOULD be set to the type of access technology using
which the mobile node is currently attached to the mobile access
gateway.
1. The mobile access gateway MUST observe the rules described in 8. The Link-local Address option MAY be present in the Proxy
Section 9.2 [RFC-3775] when processing Mobility Headers in the Binding Update message. Considerations from Section 6.8 MUST be
received Proxy Binding Acknowledgement message (a Binding applied when using the link-local address option.
Acknowledgement message with the 'P' flag set).
2. The message MUST be authenticated as described in Section 4.0. * When uploading the link-local address to the local mobility
When IPsec is used for message authentication, the SPI in the anchor, the value in the option MUST be set to the link-local
IPsec header [RFC-4306] of the received packet is needed for address that is configured on the currently attached
locating the security association, for authenticating the Proxy interface of the mobile node.
Binding Acknowledgement reply.
* When querying the local mobility anchor for the mobile node's
link-local address, the option MUST be set to ALL_ZERO value.
This essentially serves as a request to the local mobility
anchor to return the link-local address of the mobile node
from the binding cache entry corresponding to this mobility
session.
9. The Proxy Binding Update message MUST be constructed as
specified in Section 6.9.1.5.
10. If there is no existing Binding Update List entry for that
mobile node, the mobile access gateway MUST create a Binding
Update List entry for the mobile node upon sending the Proxy
Binding Update request.
6.9.1.2. Receiving Binding Registration Reply
On receiving a Proxy Binding Acknowledgement message from the local
mobility anchor, the mobile access gateway MUST process the message
as specified below.
1. The received Proxy Binding Acknowledgement message (a Binding
Acknowledgement message with the 'P' flag set) MUST be
authenticated as described in Section 4.0. When IPsec is used
for message authentication, the SPI in the IPsec header [RFC-
4306] of the received packet is needed for locating the security
association, for authenticating the Proxy Binding
Acknowledgement message .
2. The mobile access gateway MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Headers in the
received Proxy Binding Acknowledgement message.
3. The mobile access gateway MUST apply the considerations 3. The mobile access gateway MUST apply the considerations
specified in Section 5.5 for processing the Sequence Number specified in Section 5.5 for processing the Sequence Number
field and the Timestamp option, in the message. field and the Timestamp option (if present), in the message.
4. The mobile access gateway MUST ignore any checks, specified in 4. The mobile access gateway MUST ignore any checks, specified in
[RFC-3775] related to the presence of Type 2 Routing header in [RFC-3775] related to the presence of Type 2 Routing header in
the Proxy Binding Acknowledgement message. the Proxy Binding Acknowledgement message.
5. If the Timestamp option is present in the received Proxy Binding 5. The mobile access gateway MAY use the mobile node identifier
Acknowledgement message and with the Status field value set to present in the Mobile Node Identifier option for matching the
any value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the response to the request messages that it sent recently .
mobile access gateway MAY use the timestamp value for matching However, if there are more than one request message in its
the response to the request message that it sent recently. For request queue for the same mobile node, the sequence number
all other cases, it MAY use the sequence number in combination field can be used for identifying the exact message from those
with the identifier present in the Mobile Node Identifier option messages. There are other ways to achieve this and
for matching the response to the request. implementations are free to adopt the best approach that suits
their implementation. Additionally, if the received Proxy
Binding Acknowledgement message does not match any of the Proxy
Binding Update messages that it sent recently, the message MUST
be ignored.
6. If the received Proxy Binding Acknowledgement message has the 6. If the received Proxy Binding Acknowledgement message has any
one or more of the following options, Handoff Indicator option,
Access Technology Type option, Mobile Node Interface Identifier
option, Mobile Node Identifier option, carrying option values
that are different from the option values present in the
corresponding request (Proxy Binding Update) message, the
message MUST be ignored as the local mobility anchor is expected
to echo back all these listed options and with the same option
values in the reply message.
7. If the received Proxy Binding Acknowledgement message has the
Status field value set to PROXY_REG_NOT_ENABLED (Proxy Status field value set to PROXY_REG_NOT_ENABLED (Proxy
registration not enabled for the mobile node), the mobile access registration not enabled for the mobile node), the mobile access
gateway SHOULD NOT send binding registration requests again for gateway SHOULD NOT send binding registration requests again for
that mobile node. It must also deny the mobility service to that mobile node. It MUST deny the mobility service to that
that mobile node. mobile node.
7. If the received Proxy Binding Acknowledgement message has the 8. If the received Proxy Binding Acknowledgement message has the
Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED
(Timestamp lower than previously accepted timestamp), the mobile (Timestamp value lower than previously accepted value), the
access gateway SHOULD try to register again to reassert the mobile access gateway SHOULD try to register again to reassert
mobile node's presence to the mobility anchor. The mobile the mobile node's presence on its access link. The mobile
access gateway is not specifically required to synchronize its access gateway is not specifically required to synchronize its
clock upon receiving this error code. clock upon receiving this error code.
8. If the received Proxy Binding Acknowledgement message has the
Status field value set to TIMESTAMP_MISMATCH (Invalid
Timestamp), the mobile access gateway SHOULD try to register
again only after it has synchronized its clock to a common time
source that is used by all the mobility entities in that domain
for their clock synchronization. The mobile access gateway
SHOULD NOT synchronize its clock to the local mobility anchor's
system clock, based on the timestamp present in the received
message.
9. If the received Proxy Binding Acknowledgement message has the 9. If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp
(Not authorized for that prefix), the mobile access gateway value), the mobile access gateway SHOULD try to register again
SHOULD try to request for that prefix in the binding only after it has synchronized its clock to a common time source
registration request, only after it learned the validity of that that is used by all the mobility entities in that domain for
prefix. their clock synchronization. The mobile access gateway SHOULD
NOT synchronize its clock to the local mobility anchor's system
clock, based on the timestamp present in the received message.
10. If the received Proxy Binding Acknowledgement message has the 10. If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
(mobile node is not authorized for the requesting home network
prefix), the mobile access gateway SHOULD NOT request for the
same prefix again, but can request the local mobility anchor to
dynamically assign a prefix, by specifying a ALL_ZERO value in
the Home Network Prefix option carried in the subsequent Proxy
Binding Update message.
11. If the received Proxy Binding Acknowledgement message has the
Status field value set to any value greater than or equal to 128 Status field value set to any value greater than or equal to 128
(i.e., if the binding is rejected), the mobile access gateway (i.e., if the binding is rejected), the mobile access gateway
MUST NOT advertise the mobile node's home network prefix in the MUST NOT advertise the mobile node's home network prefix in the
Router Advertisements sent on that access link and there by Router Advertisements sent on that access link and there by
denying mobility service to the mobile node. denying mobility service to the mobile node.
11. If the received Proxy Binding Acknowledgement message has the 12. If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted), the Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST setup the routing state, as explained mobile access gateway MUST update the routing state, as
in section 6.10, and MUST also update the Binding Update List explained in section 6.10, and MUST also update the Binding
entry for reflecting the accepted binding registration status. Update List entry for reflecting the accepted binding
registration status.
12. If the received Proxy Binding Acknowledgement message has the 13. If the received Proxy Binding Acknowledgement message has the
address in the Link-local Address option set to a value that address in the Link-local Address option set to a value that
matches its own link-local address on that access interface matches its own link-local address on that access interface
where the mobile node is anchored, the mobile access gateway where the mobile node is anchored, the mobile access gateway
MUST change its link-local address on that interface. MUST change its link-local address on that interface, to avoid
link-local address collision on that access link.
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., if there exists a Binding Update List entry for that (i.e., after a successful initial binding registration from the
mobile node), the mobile access gateway MUST send a Proxy Binding same mobile access gateway), the mobile access gateway can send a
Update message to the local mobility anchor. The prefix value in Proxy Binding Update message to the local mobility anchor with a
the Home Network Prefix option present in the request SHOULD be new lifetime value. This re-registration message MUST be
set to the currently registered home network prefix and the value constructed with the same set of options as the initial binding
in the Link-local Address option MAY be set to ALL_ZERO or to the registration message, under the considerations specified in
link-local address of the mobile node. Section 6.9.1.1. However the following exceptions apply.
Mobile Node Detachment and Binding De-Registration: 2. The prefix value in the Home Network Prefix option MUST be set to
the currently assigned home network prefix.
1. At any point, if the mobile access gateway detects that the 3. The Handoff Indicator field in the Handoff Indicator option MUST
mobile node has moved away from its access link, it SHOULD send a be set to a value of 5 (Handoff state not changed - Re-
Registration).
4. The value in the Link-local Address option (if the option was
present in the initial registration message) MUST be set to the
link-local address of the mobile node's attached interface.
6.9.1.4. Mobile Node Detachment and Binding De-Registration
1. At any point, the mobile access gateway detects that the mobile
node has moved away from its access link, or if it decides to
terminate the mobile node's mobility session, it SHOULD send a
Proxy Binding Update message to the local mobility anchor with Proxy Binding Update message to the local mobility anchor with
the lifetime value set to zero. the lifetime value set to zero. This de-registration message
MUST be constructed with the same set of options as the initial
binding registration message, under the considerations specified
in Section 6.9.1.1. However, the following exceptions apply.
2. Either upon receipt of a Proxy Binding Acknowledgement message 2. The prefix value in the Home Network Prefix option MUST be set to
from the local mobility anchor or after a MinPBUReplyTime timeout the currently assigned home network prefix.
waiting for the reply, the mobile access gateway MUST remove the
Binding Cache entry for that mobile node from its Binding Update
List and withdraw the mobile node's home network prefix as the
hosted on-link prefix on that access link.
Constructing the Proxy Binding Update Message: 3. The Handoff Indicator field in the Handoff Indicator option MUST
be set to a value of 4 (Handoff state unknown).
4. The value in the Link-local Address option (if the option was
present in the initial registration message) MUST be set to the
link-local address of the mobile node's attached interface.
Either upon receipt of a Proxy Binding Acknowledgement message from
the local mobility anchor or after INITIAL_BINDINGACK_TIMEOUT [RFC-
3775] timeout waiting for the reply, the mobile access gateway MUST
do the following:
1. It MUST remove the Binding Update List entry for the mobile node
from its Binding Update List.
2. It MUST withdraw the mobile node's home network prefix as the
hosted on-link prefix, by sending a Router Advertisement message
with the prefix lifetime value set to zero.
3. It MUST remove the created routing state for tunneling the mobile
node's traffic.
4. It SHOULD teardown the point-to-point link shared with the mobile
node. This action will force the mobile node to remove any IPv6
address configuration on the interface connected to this point-
to-point link.
6.9.1.5. Constructing the Proxy Binding Update Message
o The mobile access gateway when sending the Proxy Binding Update o The mobile access gateway when sending the Proxy Binding Update
request to the local mobility anchor MUST construct the message as request to the local mobility anchor MUST construct the message as
specified below. specified below.
IPv6 header (src=Proxy-CoA, dst=LMAA) IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header Mobility header
-BU /*P & A flags are set*/ - BU /* P & A flags MUST be set */
Mobility Options Mobility Options
- Home Network Prefix option - Mobile Node Identifier option (mandatory)
- Link-local Address option (Optional) - Home Network Prefix option (mandatory)
- Timestamp Option (optional) - Handoff Indicator option (mandatory)
- Mobile Node Identifier option - Access Technology Type option (mandatory)
- Access Technology Type option (Mandatory) - Timestamp option (optional)
- Mobile Node Interface Identifier option - Mobile Node Interface Identifier option (optional)
(Optional) - Link-local Address option (optional)
Figure 8: Proxy Binding Update message format Figure 11: Proxy Binding Update message format
o The Source Address field in the IPv6 header of the message MUST be o The Source Address field in the IPv6 header of the message MUST be
set to the address of the mobile access gateway. set to the address configured on the interface of the mobile
access gateway. When there is no Alternate Care-of Address option
present in the request, this address will be considered as the
Proxy-CoA address for this binding registration request. However,
when there is Alternate Care-of Address option present in the
request, this address will be not be the considered as the Proxy-
CoA address, but the address in the alternate Care-of Address
option will be considered as the Proxy-CoA address.
o The Destination Address field in the IPv6 header of the message o The Destination Address field in the IPv6 header of the message
MUST be set to the local mobility anchor address. MUST be set to the local mobility anchor address.
o The Home Network Prefix option MUST be present. The prefix value o The Mobile Node Identifier option [RFC-4283] MUST be present.
MAY be set 0::/0 or to a specific prefix value.
o The Link-local Address option MAY be present. The value MAY be o The Home Network Prefix option MUST be present.
set to ALL_ZERO or the mobile node's link-local address.
o The Access Technology Type option MUST be present. The value MUST o The Handoff Indicator option MUST be present.
be set to the type of the access technology using which the mobile
node is currently attached to the mobile access gateway.
o The Mobile Node Interface Identifier option MAY be present. o The Access Technology Type option MUST be present.
o Considerations from Section 5.5 must be applied for constructing o The Timestamp option MAY be present.
the Timestamp option.
o The Mobile Node Identifier option [RFC-4283] MUST be present, the o The Mobile Node Interface Identifier option MAY be present.
identifier field in the option MUST be set to mobile node's
identifier, MN-Identifier. o The Link-local Address option MAY be present.
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 Home Address option [RFC-
3775] MUST NOT be present in the IPv6 Destination Options
extension header of the Proxy Binding Update message.
6.9.2. Router Solicitation Messages 6.9.2. Router Solicitation Messages
The mobile node may send a Router Solicitation message on the access The mobile node may send a Router Solicitation message on the access
link whenever the link-layer detects a media change. The Source link whenever the link-layer detects a media change. The Source
Address in the IPv6 header of the Router Solicitation message may Address in the IPv6 header of the Router Solicitation message may
either be the link-local address of the mobile node or an unspecified either be the link-local address of the mobile node or an unspecified
address (::). address (::). The Router Solicitation message that the mobile node
sends is as specified in [RFC-4861].
1. The mobile access gateway on receiving the Router Solicitation 1. The mobile access gateway on receiving the Router Solicitation
message SHOULD send a Router Advertisement containing the mobile message SHOULD send a Router Advertisement containing the mobile
node's home network prefix as the on-link prefix. However, node's home network prefix as the on-link prefix. However,
before sending the Router Advertisement message containing the before sending the Router Advertisement message containing the
mobile node's home network prefix, it SHOULD complete the binding mobile node's home network prefix, it SHOULD complete the binding
registration process with the mobile node's local mobility registration process with the mobile node's local mobility
anchor. anchor.
2. If the local mobility anchor rejects the binding registration 2. If the local mobility anchor rejects the binding registration
request, or, if the mobile access gateway failed to complete the request, or, if the mobile access gateway failed to complete the
binding registration process for whatever reasons, the mobile binding registration process for whatever reasons, the mobile
access gateway MUST NOT advertise the mobile node's home network access gateway MUST NOT advertise the mobile node's home network
prefix in the Router Advertisement messages that it sends on the prefix in the Router Advertisement messages that it sends on the
access link. However, it MAY choose to advertise a local visited access link. However, it MAY choose to advertise a local visited
network prefix to enable the mobile node for regular IPv6 access. network prefix to enable the mobile node for regular IPv6 access.
6.9.3. Retransmissions and Rate Limiting 6.9.3. Default-Router Lifetime
This section is a non-normative section and only provides some
general guidance to implementations.
In Proxy Mobile IPv6, the mobile access gateway is typically the IPv6
default-router for the mobile node on the access link, as it is the
entity that sends the Router Advertisements on the access link.
However, as the mobile node moves from one access link to another,
the serving mobile access gateway on those respective links will send
the Router Advertisements and using their own link-local address.
The mobile node on each of the attached links will receive Router
Advertisement messages with a different source address and this makes
the mobile node believe that there is a new default-router on that
access link.
The mobile node will certainly detect the previous default-router
loss by performing the Neighbor Unreachability Detection procedure
per the standard IPv6 ND mechanisms, but it is important that the
mobile access gateway enables the mobile node to withdraw the
previous default-router entry at the earliest. This action will help
in minimizing packet losses during a hand off switch. Following are
some considerations that implementations can apply.
The Router Lifetime field in the Router Advertisement messages that
the mobile access gateway sends on the access link SHOULD be kept to
low.
In access networks where SEND [RFC-3971] is not deployed, the mobile
access gateway can withdraw the previous default-router entry, by
sending a Router Advertisement using the link-local address that of
the previous mobile access gateway and with the Router Lifetime field
set to value zero, then this will force the flush of the previous
default-router entry from the mobile node's cache, as specified in
Section 6.3.5 [RFC-4861]. However, this approach requires the
serving mobile access gateway to learn the link-local address of the
previous mobile access gateway where the mobile node was handed off.
There are other solutions possible for this problem, including the
assignment of a fixed link-local address for all the mobility
entities in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is
not deployed. In such scenario, the mobile node is not required to
update the default-router entry. However, this is an implementation
choice and has no bearing on the protocol interoperability.
Implementations are free to adopt the best approach that suits their
target deployments.
6.9.4. Retransmissions and Rate Limiting
The mobile access gateway is responsible for retransmissions and rate The mobile access gateway is responsible for retransmissions and rate
limiting the binding registration requests that it sends for updating limiting the binding registration requests that it sends to the local
a mobile node's binding. Implementations MUST follow the below mobility anchor. The Retransmission and the Rate Limiting rules are
guidelines. as specified in [RFC-3775]. However, the following considerations
MUST be applied.
1. When the mobile access gateway sends a Proxy Binding Update 1. When the mobile access gateway sends a Proxy Binding Update
request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT
[RFC-3775], for configuring the retransmission timer. [RFC-3775], for configuring the retransmission timer, as
specified in Section 11.8 [RFC-3775]. However, the mobile access
gateway is not required to use a longer retransmission interval
of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for
the initial binding registration request.
2. If the mobile access gateway fails to receive a valid matching 2. If the mobile access gateway fails to receive a valid matching
response within the retransmission interval, it SHOULD retransmit response for a registration or re-registration message within the
the message until a response is received. However, the mobile retransmission interval, it SHOULD retransmit the message until a
access gateway MUST ensure the mobile node is still attached to response is received. However, the mobile access gateway MUST
the connected link before retransmitting the message. ensure the mobile node is still attached to the connected link
before retransmitting the message.
3. As specified in Section 11.8 [RFC-3775], the mobile access 3. As specified in Section 11.8 [RFC-3775], the mobile access
gateway MUST use an exponential back-off process in which the gateway MUST use an exponential back-off process in which the
timeout period is doubled upon each retransmission, until either timeout period is doubled upon each retransmission, until either
the node receives a response or the timeout period reaches the the node receives a response or the timeout period reaches the
value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway
MAY continue to send these messages at this slower rate MAY continue to send these messages at this slower rate
indefinitely. indefinitely.
4. If Timestamp based scheme is in use, the retransmitted Proxy 4. If Timestamp based scheme is in use, the retransmitted Proxy
skipping to change at page 46, line 27 skipping to change at page 52, line 12
traffic to/from the mobile node that is attached to one of its access traffic to/from the mobile node that is attached to one of its access
interface. interface.
Proxy-CoA LMAA Proxy-CoA LMAA
| | | |
+--+ +---+ +---+ +--+ +--+ +---+ +---+ +--+
|MN|----------|MAG|======================|LMA|----------|CN| |MN|----------|MAG|======================|LMA|----------|CN|
+--+ +---+ +---+ +--+ +--+ +---+ +---+ +--+
IPv6 Tunnel IPv6 Tunnel
Figure 9: Proxy Mobile IPv6 Tunnel Figure 12: Proxy Mobile IPv6 Tunnel
6.10.1. Transport Network 6.10.1. Transport Network
The transport network between the local mobility anchor and the The transport network between the local mobility anchor and the
mobile access gateway can be either an IPv6 or IPv4 network. mobile access gateway can be either an IPv6 or IPv4 network.
However, this specification only deals with the IPv6 transport and However, this specification only deals with the IPv6 transport and
the companion document [ID-IPV4-PMIP6] specifies the required the companion document [ID-IPV4-PMIP6] specifies the required
extensions for negotiating IPv4 transport and the corresponding extensions for negotiating IPv4 transport and the corresponding
encapsulation mode for supporting this protocol operation. encapsulation mode for supporting this protocol operation.
skipping to change at page 47, line 32 skipping to change at page 53, line 15
o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC-
2473]. 2473].
o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The
details on how this mode is negotiated is specified in [ID-IPV4- details on how this mode is negotiated is specified in [ID-IPV4-
PMIP6]. PMIP6].
o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP
packet. This mode is specified in [ID-IPV4-PMIP6]. packet. This mode is specified in [ID-IPV4-PMIP6].
6.10.3. Routing State 6.10.3. Local Routing
The following section explains the routing state for a mobile node on
the mobile access gateway. This routing state reflects only one
specific way of implementation and one MAY choose to implement it in
other ways. The policy based route defined below acts as a traffic
selection rule for routing a mobile node's traffic through a specific
tunnel created between the mobile access gateway and that mobile
node's local mobility anchor and with the specific encapsulation
mode, as negotiated.
The below example identifies the routing state for two visiting
mobile nodes, MN1 and MN2 with their respective local mobility
anchors LMA1 and LMA2.
For all traffic from the mobile node, identified by the mobile node's
MAC address, ingress interface or source prefix (MN-HNP) to
_ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA.
+==================================================================+
| Packet Source | Destination Address | Destination Interface |
+==================================================================+
| MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 |
| (IPv6 Prefix or |----------------------------------------------|
| Input Interface) | Locally Connected | Tunnel0 |
+------------------------------------------------------------------+
| MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 |
+ (IPv6 Prefix or -----------------------------------------------|
| Input Interface | Locally Connected | direct |
+------------------------------------------------------------------+
Figure 10: Example - Policy based Route Table
+==================================================================+
| Interface | Source Address | Destination Address | Encapsulation |
+==================================================================+
| Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
| Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 |
+------------------------------------------------------------------+
Figure 11: Example - Tunnel Interface Table
6.10.4. Local Routing
If there is data traffic between a visiting mobile node and a If there is data traffic between a visiting mobile node and a
correspondent node that is locally attached to an access link correspondent node that is locally attached to an access link
connected to the mobile access gateway, the mobile access gateway MAY connected to the mobile access gateway, the mobile access gateway MAY
optimize on the delivery efforts by locally routing the packets and optimize on the delivery efforts by locally routing the packets and
by not reverse tunneling them to the mobile node's local mobility by not reverse tunneling them to the mobile node's local mobility
anchor. The configuration variable, EnableMAGLocalRouting MAY be anchor. The configuration variable, EnableMAGLocalRouting MAY be
used for controlling this aspect. However, in some systems, this may used for controlling this aspect. However, in some systems, this may
have an implication on the mobile node's accounting and policy have an implication on the mobile node's accounting and policy
enforcement as the local mobility anchor is not in the path for that enforcement as the local mobility anchor is not in the path for that
traffic and it will not be able to apply any traffic policies or do traffic and it will not be able to apply any traffic policies or do
any accounting for those flows. any accounting for those flows.
This decision of path optimization SHOULD be based on the policy This decision of path optimization SHOULD be based on the policy
configured on the mobile access gateway, but enforced by the mobile configured on the mobile access gateway, but enforced by the mobile
node's local mobility anchor. The specific details on how this is node's local mobility anchor. The specific details on how this is
achieved are beyond of the scope of this document. achieved are beyond of the scope of this document.
6.10.5. Tunnel Management 6.10.4. Tunnel Management
All the considerations mentioned in Section 5.6.1 for the tunnel All the considerations mentioned in Section 5.6.1 for the tunnel
management on the local mobility anchor apply for the mobile access management on the local mobility anchor apply for the mobile access
gateway as well. gateway as well.
6.10.6. Forwarding Rules 6.10.5. Forwarding Rules
Forwarding Packets sent to the Mobile Node's Home Network: Forwarding Packets sent to the Mobile Node's Home Network:
o On receiving a packet from the bi-directional tunnel established o On receiving a packet from the bi-directional tunnel established
with the mobile node's local mobility anchor, the mobile access with the mobile node's local mobility anchor, the mobile access
gateway MUST use the destination address of the inner packet for gateway MUST use the destination address of the inner packet for
forwarding it on the interface where the destination network forwarding it on the interface where the destination network
prefix is hosted. The mobile access gateway MUST remove the outer prefix is hosted. The mobile access gateway MUST remove the outer
header before forwarding the packet. If the mobile access gateway header before forwarding the packet. If the mobile access gateway
cannot find the connected interface for that destination address, cannot find the connected interface for that destination address,
skipping to change at page 50, line 15 skipping to change at page 54, line 44
established between itself and the mobile node's local mobility established between itself and the mobile node's local mobility
anchor. Otherwise, it can route the packet directly to the anchor. Otherwise, it can route the packet directly to the
destination. destination.
o On receiving a packet from the mobile node connected to its access o On receiving a packet from the mobile node connected to its access
link, to a destination that is not directly connected, the packet link, to a destination that is not directly connected, the packet
MUST be forwarded to the local mobility anchor through the bi- MUST be forwarded to the local mobility anchor through the bi-
directional tunnel established between itself and the mobile directional tunnel established between itself and the mobile
node's local mobility anchor. However, the packets that are sent node's local mobility anchor. However, the packets that are sent
with the link-local source address MUST NOT be forwarded. The with the link-local source address MUST NOT be forwarded. The
format of the tunneled packet is shown below. However, when using format of the tunneled packet is shown below. Additionally, when
IPv4 transport, the format of the tunneled packet is as described using IPv4 transport, the format of the tunneled packet is as
in [ID-IPV4-PMIP6]. described in [ID-IPV4-PMIP6].
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/ Upper layer protocols /* Packet Content*/
Figure 13: Tunneled Packets from MAG to LMA
Figure 12: Tunneled Packets from MAG to LMA
6.11. Supporting DHCPv6 based Address Configuration on the Access Link 6.11. Supporting DHCPv6 based Address Configuration on the Access Link
This section explains how Stateful Address Configuration using DHCPv6 This section explains how Stateful Address Configuration using DHCPv6
can be enabled on the access link attached to a mobile access gateway can be enabled on the access link attached to a mobile access gateway
and how a mobile node attached to that link can obtain an address and how a mobile node attached to that link can obtain an address
from its home network prefix using DHCPv6. from its home network prefix using DHCPv6.
o For supporting Stateful Address Configuration using DHCPv6, the o For supporting Stateful Address Configuration using DHCPv6, the
DHCPv6 relay agent [RFC-3315] service MUST be enabled on each of DHCPv6 relay agent [RFC-3315] service MUST be enabled on each of
skipping to change at page 52, line 10 skipping to change at page 56, line 36
anchor for extending the lifetime of a currently existing binding of anchor for extending the lifetime of a currently existing binding of
a mobile node, the mobile access gateway MUST make sure the mobile a mobile node, the mobile access gateway MUST make sure the mobile
node is still attached to the connected link by using some reliable node is still attached to the connected link by using some reliable
method. If the mobile access gateway cannot predictably detect the method. If the mobile access gateway cannot predictably detect the
presence of the mobile node on the connected link, it MUST NOT presence of the mobile node on the connected link, it MUST NOT
attempt to extend the registration lifetime of the mobile node. attempt to extend the registration lifetime of the mobile node.
Further, in such scenario, the mobile access gateway SHOULD terminate Further, in such scenario, the mobile access gateway SHOULD terminate
the binding of the mobile node by sending a Proxy Binding Update the binding of the mobile node by sending a Proxy Binding Update
message to the mobile node's local mobility anchor with lifetime message to the mobile node's local mobility anchor with lifetime
value set to 0. It MUST also remove any local state such as the value set to 0. It MUST also remove any local state such as the
Binding Update List created for that mobile node. Binding Update List entry created for that mobile node.
The specific detection mechanism of the loss of a visiting mobile The specific detection mechanism of the loss of a visiting mobile
node on the connected link is specific to the access link between the node on the connected link is specific to the access link between the
mobile node and the mobile access gateway and is outside the scope of mobile node and the mobile access gateway and is outside the scope of
this document. Typically, there are various link-layer specific this document. Typically, there are various link-layer specific
events specific to each access technology that the mobile access events specific to each access technology that the mobile access
gateway can depend on for detecting the node loss. In general, the gateway can depend on for detecting the node loss. In general, the
mobile access gateway can depend on one or more of the following mobile access gateway can depend on one or more of the following
methods for the detection presence of the mobile node on the methods for the detection presence of the mobile node on the
connected link: connected link:
skipping to change at page 53, line 19 skipping to change at page 57, line 45
to its access link and with out impacting its host-based mobility to its access link and with out impacting its host-based mobility
protocol operation. protocol operation.
7. Mobile Node Operation 7. Mobile Node Operation
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
Once 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 setup the data path for gateway will create the required state and setup the data path 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 Router Solicitation message [RFC-4861]. The it will typically send 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
skipping to change at page 54, line 9 skipping to change at page 58, line 35
its IPv6 address as a lease from its home network prefix. its IPv6 address as a lease from its home network prefix.
If the received Router Advertisement does not have the Managed If the received Router Advertisement does not have the Managed
Address Configuration flag set and if the mobile node is allowed to Address Configuration flag set and if the mobile node is allowed to
use an autoconfigured address, the mobile node will be able to obtain use an autoconfigured address, the mobile node will be able to obtain
an IPv6 address using an interface identifier generated as per the an IPv6 address using an interface identifier generated as per the
Autoconf specification [RFC-4862] or as per the Privacy Extensions Autoconf specification [RFC-4862] or as per the Privacy Extensions
specification [RFC-4941]. specification [RFC-4941].
If the mobile node is IPv4 enabled and if the network permits, it If the mobile node is IPv4 enabled and if the network permits, it
will be able to obtain the IPv4 address configuration for the will be able to obtain the IPv4 address configuration as specified in
connected interface by using DHCP [RFC-2131]. The details related to the companion document [ID-IPV4-PMIP6].
IPv4 support is specified in the companion document [ID-IPV4-PMIP6].
Once the address configuration is complete, the mobile node can Once the address configuration is complete, the mobile node can
continue to use this address configuration as long as it is attached continue to use this address configuration as long as it is attached
to the network that is in the scope of that Proxy Mobile IPv6 domain. to the network that is in the scope of that Proxy Mobile IPv6 domain.
7.2. Roaming in the Proxy Mobile IPv6 Domain 7.2. Roaming in the Proxy Mobile IPv6 Domain
After obtaining the address configuration in the Proxy Mobile IPv6 After obtaining the address configuration in the Proxy Mobile IPv6
domain, as the mobile node moves and changes its point of attachment domain, as the mobile node moves and changes its point of attachment
from one mobile access gateway to the other, it can still continue to from one mobile access gateway to the other, it can still continue to
skipping to change at page 54, line 33 skipping to change at page 59, line 10
network is in the scope of that Proxy Mobile IPv6 domain, the mobile network is in the scope of that Proxy Mobile IPv6 domain, the mobile
node will always detect the same link, where it obtained its initial node will always detect the same link, where it obtained its initial
address configuration. If the mobile node performs DHCP operation, address configuration. If the mobile node performs DHCP operation,
it will always obtain the same address as before. it will always obtain the same address as before.
However, the mobile node will always detect a new default-router on However, the mobile node will always detect a new default-router on
each connected link, but still advertising the mobile node's home each connected link, but still advertising the mobile node's home
network prefix as the on-link prefix and with the other configuration network prefix as the on-link prefix and with the other configuration
parameters consistent with its home link properties. parameters consistent with its home link properties.
7.3. IPv6 Host Protocol Parameters
This specification does not require any changes to the mobile node's
IP stack. It assumes the mobile node to be a normal IPv4/IPv6 node,
with its protocol operation consistent with the respective
specifications.
However, for achieving protocol efficiency and for faster hand-offs,
implementations may choose to adjust the following IPv6 operating
parameters on the mobile node be adjusted to the below recommended
values.
Lower Default-Router List Cache Time-out:
As per the base IPv6 specification [RFC-4861], each IPv6 host is
required to maintain certain host data structures including a
Default-Router list. This is the list of on-link routers that have
sent Router Advertisement messages and are eligible to be default
routers on that link. The Router Lifetime field in the received
Router Advertisement defines the life of this entry.
In case of Proxy Mobile IPv6, when a mobile node moves from one link
to another, the source address of the received Router Advertisement
messages advertising the mobile node's home network prefix will be
from a different link-local address and thus making the mobile node
believe that there is a new default-router on the link. It is
important that the mobile node uses the newly learnt default-router
and not the previously known default-router. The mobile node must
update its default-router list with the new default router entry and
must age out the previously learnt default router entry from its
cache, just as specified in Section 6.3.5 [RFC-4861]. This action
will help in minimizing packet losses during a hand off switch.
On detecting a reachability problem, the mobile node will certainly
detect the default-router loss by performing the Neighbor
Unreachability Detection procedure, but it is important that the
mobile node times out the previous default router entry at the
earliest. If a given IPv6 host implementation has the provision to
adjust these flush timers, still conforming to the base IPv6 ND
specification, it is desirable to keep the flush-timers to suit the
above consideration.
In access network where SEND [RFC-3971] is not deployed, the mobile
access gateway may withdraw the previous default-router entry, by
sending a Router Advertisement using the link-local address that of
the previous mobile access gateway and with the Router Lifetime field
set to value 0, then this will force the flush of the Previous
Default-Router entry from the mobile node's cache. This certainly
requires context-transfer mechanisms in place for notifying the link-
local address of the default-router on the previous link to the
mobile access gateway on the new link.
There are other solutions possible for this problem, including the
assignment of a fixed link-local address for all the mobility
entities in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is
not deployed. In such scenario, the mobile node is not required to
update the default-router entry. However, this is an implementation
choice and has no bearing on the protocol interoperability.
Implementations are free to adopt the best approach that suits their
target deployments.
8. Message Formats 8. Message Formats
This section defines extensions to the Mobile IPv6 [RFC-3775] This section defines extensions to the Mobile IPv6 [RFC-3775]
protocol messages. protocol messages.
8.1. Proxy Binding Update Message 8.1. Proxy Binding Update Message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 57, line 8 skipping to change at page 60, line 22
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 [RFC- and format of defined options are described in Section 6.2 [RFC-
3775]. The local mobility anchor MUST ignore and skip any options 3775]. The local mobility anchor MUST ignore and skip any options
which it does not understand. which it does not understand.
As per this specification, the following mobility options are As per this specification, the following mobility options are
valid in a Proxy Binding Update message: valid in a Proxy Binding Update message:
Home Network Prefix option Mobile Node Identifier option
Link-local Address option Home Network Prefix option
Mobile Node Identifier Option Handoff Indicator option
Access Technology Type option Access Technology Type option
Timestamp option
Mobile Node Interface Identifier option Mobile Node Interface Identifier option
Timestamp option Link-local Address option
For descriptions of other fields present in this message, refer to For descriptions of other fields present in this message, refer to
section 6.1.7 [RFC-3775]. section 6.1.7 [RFC-3775].
8.2. Proxy Binding Acknowledgement Message 8.2. Proxy Binding Acknowledgement Message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved | | Status |K|R|P|Reserved |
skipping to change at page 58, line 23 skipping to change at page 62, line 8
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 [RFC- and format of defined options are described in Section 6.2 [RFC-
3775]. The mobile access gateway MUST ignore and skip any options 3775]. The mobile access gateway MUST ignore and skip any options
which it does not understand. which it does not understand.
As per this specification, the following mobility options are As per this specification, the following mobility options are
valid in a Proxy Binding Acknowledgement message: valid in a Proxy Binding Acknowledgement message:
Home Network Prefix option Mobile Node Identifier option
Link-local Address option Home Network Prefix option
Mobile Node Identifier option Handoff Indicator option
Access Technology Type option Access Technology Type option
Timestamp option
Mobile Node Interface Identifier option Mobile Node Interface Identifier option
Timestamp option Link-local Address option
Status Status
8-bit unsigned integer indicating the disposition of the Proxy 8-bit unsigned integer indicating the disposition of the Proxy
Binding Update. Values of the Status field less than 128 indicate Binding Update. Values of the Status field less than 128 indicate
that the Proxy Binding Update was accepted by the local mobility that the Proxy Binding Update was accepted by the local mobility
anchor. Values greater than or equal to 128 indicate that the anchor. Values greater than or equal to 128 indicate that the
binding registration was rejected by the local mobility anchor. binding registration was rejected by the local mobility anchor.
Section 8.8 defines the Status values that can used in Proxy Section 8.9 defines the Status values that can used in Proxy
Binding Acknowledgement message. Binding Acknowledgement message.
For descriptions of other fields present in this message, refer to For descriptions of other fields present in this message, refer to
the section 6.1.8 [RFC-3775]. the section 6.1.8 [RFC-3775].
8.3. Home Network Prefix Option 8.3. Home Network Prefix Option
A new option, Home Network Prefix Option is defined for using it in A new option, Home Network Prefix Option is defined for using it in
the Proxy Binding Update and Proxy Binding Acknowledgement messages the Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access exchanged between a local mobility anchor and a mobile access
skipping to change at page 60, line 5 skipping to change at page 63, line 44
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the 8-bit unsigned integer indicating the prefix length of the
IPv6 prefix contained in the option. IPv6 prefix contained in the option.
Home Network Prefix Home Network Prefix
A sixteen-byte field containing the mobile node's IPv6 Home A sixteen-byte field containing the mobile node's IPv6 Home
Network Prefix. Network Prefix.
8.4. Access Technology Type Option 8.4. Handoff Indicator Option
A new option, Handoff Indicator Option is defined for using it in the
Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the mobile node's
handoff related hints.
The Handoff Indicator Option has no alignment requirement. Its
format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) | HI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<IANA>
Length
8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field
MUST be set to 2.
Reserved (R)
This 8-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
Handoff Indicator (HI)
A 8-bit field that specifies the type of handoff. The values
(0 - 255) will be allocated and managed by IANA. The following
values are currently reserved.
0: Reserved
1: Attachment over a new interface
2: Handoff between two different interfaces of the mobile node
3: Handoff between mobile access gateways for the same interface
4: Handoff state unknown
5: Handoff state not changed (Re-registration)
8.5. Access Technology Type Option
A new option, Access Technology Type Option is defined for using it A new option, Access Technology Type Option is defined for using it
in the Proxy Binding Update and Proxy Binding Acknowledgement in the Proxy Binding Update and Proxy Binding Acknowledgement
messages exchanged between a local mobility anchor and a mobile messages exchanged between a local mobility anchor and a mobile
access gateway. This option is used for exchanging the type of the access gateway. This option is used for exchanging the type of the
access technology using which the mobile node is currently attached access technology using which the mobile node is currently attached
to the mobile access gateway. to the mobile access gateway.
The Access Technology Type Option has no alignment requirement. Its The Access Technology Type Option has no alignment requirement. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Acc Tech | HI | Reserved| | Type | Length | Reserved (R) | ATT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<IANA> <IANA>
Length Length
8-bit unsigned integer indicating the length of the option 8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field in octets, excluding the type and length fields. This field
MUST be set to 2. MUST be set to 2.
Access Technology Type (Acc Tech) Reserved (R)
This 8-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
Access Technology Type (ATT)
A 8-bit field that specifies the access technology through A 8-bit field that specifies the access technology through
which the mobile node is connected to the access link on the which the mobile node is connected to the access link on the
mobile access gateway. mobile access gateway.
The values 0-255 will be allocated and managed by IANA. The The values (0 - 255) will be allocated and managed by IANA. The
following values are currently reserved for the below specified following values are currently reserved for the below specified
access technology types. access technology types.
0x00: Reserved
0x01: Virtual
0x02: PPP
0x02: 802.3 (Ethernet)
0x03: 802.11a
0x04: 802.11b
0x05: 802.11g
0x06: 802.16e
0x07: CDMA2000 1xEV-DO Release 0
0x08: CDMA2000 1xEV-DO Revision A
0x09: CDMA2000 1xEV-DO Revision B
0x0a: 3GPP LTE
Handoff Indicator (HI)
A 3-bit field that specifies the type of handoff. The values
(0-3) will be allocated and managed by IANA. The following
values are currently reserved.
0: Reserved 0: Reserved
1: Attachment over a new interface 1: Virtual
2: Handoff between interfaces 2: PPP
3: Handoff between mobile access gateways for the same interface 3: 802.3 (Ethernet)
4: Handoff state unknown 4: 802.11a/b/g
5: 802.16e
Reserved (R)
This 5-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
8.5. Mobile Node Interface Identifier Option 8.6. Mobile Node Interface Identifier Option
A new option, Mobile Node Interface Identifier Option is defined for A new option, Mobile Node Interface Identifier Option is defined for
using it in the Proxy Binding Update and Proxy Binding using it in the Proxy Binding Update and Proxy Binding
Acknowledgement messages exchanged between a local mobility anchor Acknowledgement messages exchanged between a local mobility anchor
and a mobile access gateway. This option is used for exchanging the and a mobile access gateway. This option is used for exchanging the
mobile node's interface identifier. mobile node's interface identifier.
The format of the Interface Identifier option when the interface The format of the Interface Identifier option when the interface
identifier is 8 bytes is shown below. When the size is different, identifier is 8 bytes is shown below. When the size is different,
the option MUST be aligned appropriately, as per mobility option the option MUST be aligned appropriately, as per mobility option
alignment requirements specified in [RFC-3775]. alignment requirements specified in [RFC-3775].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Interface Identifier + + Interface Identifier +
. ... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
<IANA> <IANA>
Length Length
8-bit unsigned integer indicating the length of the option 8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field in octets, excluding the type and length fields.
MUST be set to 10.
Reserved Reserved
This field is unused for now. The value MUST be initialized to This field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver. 0 by the sender and MUST be ignored by the receiver.
Interface Identifier Interface Identifier
A variable length field containing the mobile node's interface A variable length field containing the mobile node's interface
identifier. identifier.
8.6. Link-local Address Option The content and format of this field (including byte and bit
ordering) is as specified in Section 4.6 [RFC-4861] for
carrying Link-Layer Address.
8.7. Link-local Address Option
A new option, Link-local Address Option is defined for using it in A new option, Link-local Address Option is defined for using it in
the Proxy Binding Update and Proxy Binding Acknowledgement messages the Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the mobile node's link- gateway. This option is used for exchanging the mobile node's link-
local address. local address.
The Link-local Address option has an alignment requirement of 8n+6. The Link-local Address option has an alignment requirement of 8n+6.
Its format is as follows: Its format is as follows:
skipping to change at page 63, line 33 skipping to change at page 67, line 44
8-bit unsigned integer indicating the length of the option 8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field in octets, excluding the type and length fields. This field
MUST be set to 16. MUST be set to 16.
Link-local Address Link-local Address
A sixteen-byte field containing the mobile node's link-local A sixteen-byte field containing the mobile node's link-local
address. address.
8.7. Timestamp Option 8.8. Timestamp Option
A new option, Timestamp Option is defined for use in the Proxy A new option, Timestamp Option is defined for use in the Proxy
Binding Update and Proxy Binding Acknowledgement messages. Binding Update and Proxy Binding Acknowledgement messages.
The Timestamp option has an alignment requirement of 8n+2. Its The Timestamp option has an alignment requirement of 8n+2. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 64, line 33 skipping to change at page 68, line 36
Timestamp Timestamp
A 64-bit unsigned integer field containing a timestamp. The value A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1, 1970, 00:00 UTC, indicates the number of seconds since January 1, 1970, 00:00 UTC,
by using a fixed point format. In this format, the integer number by using a fixed point format. In this format, the integer number
of seconds is contained in the first 48 bits of the field, and the of seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/65536 fractions of a remaining 16 bits indicate the number of 1/65536 fractions of a
second. second.
8.8. Status Values 8.9. Status Values
This document defines the following new Status values for use in This document defines the following new Status values for use in
Proxy Binding Acknowledgement message. These values are to be Proxy Binding Acknowledgement message. These values are to be
allocated from the same number space, as defined in Section 6.1.8 allocated from the same number space, as defined in Section 6.1.8
[RFC-3775]. [RFC-3775].
Status values less than 128 indicate that the Proxy Binding Update Status values less than 128 indicate that the Proxy Binding Update
request was accepted by the local mobility anchor. Status values request was accepted by the local mobility anchor. Status values
greater than 128 indicate that the Proxy Binding Update was rejected greater than 128 indicate that the Proxy Binding Update was rejected
by the local mobility anchor. by the local mobility anchor.
PROXY_REG_NOT_ENABLED: PROXY_REG_NOT_ENABLED:
Proxy Registration not enabled for the mobile node. Proxy registration not enabled for the mobile node
MAG_NOT_AUTHORIZED_FOR_PROXY_REG: MAG_NOT_AUTHORIZED_FOR_PROXY_REG:
The mobile access gateway is not authorized to send proxy binding. The mobile access gateway is not authorized to send proxy binding
updates. registrations
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
The mobile node is not authorized for the requesting home network The mobile node is not authorized for the requesting home network
prefix. prefix
TIMESTAMP_MISMATCH: TIMESTAMP_MISMATCH:
Invalid timestamp value in the received Proxy Binding Update Invalid timestamp value (the clocks are out of sync)
message (the clocks are out of sync).
TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: TIMESTAMP_LOWER_THAN_PREV_ACCEPTED:
The timestamp value in the received Proxy Binding Update message The timestamp value is lower than the previously accepted value
is lower than the previously accepted value.
MISSING_HOME_NETWORK_PREFIX_OPTION MISSING_HOME_NETWORK_PREFIX_OPTION
Missing mobile node home network prefix option. Missing home network prefix option
MISSING_MN_IDENTIFIER_OPTION: MISSING_MN_IDENTIFIER_OPTION:
Missing mobile node identifier in the Proxy Binding Update Missing mobile node identifier option
message.
MISSING_HANDOFF_INDICATOR_OPTION
Missing handoff indicator option
MISSING_ACCESS_TECH_TYPE_OPTION MISSING_ACCESS_TECH_TYPE_OPTION
Missing mobile node's access technology type in the Proxy Binding Missing access technology type option
Update message.
Additionally, the following Status values defined in [RFC-3775] can Additionally, the following Status values defined in [RFC-3775] can
also be used in Proxy Binding Acknowledgement message. also be used in Proxy Binding Acknowledgement message.
0 Proxy Binding Update accepted 0 Proxy Binding Update accepted
128 Reason unspecified 128 Reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Insufficient resources 130 Insufficient resources
133 Not local mobility anchor for this mobile node 133 Not local mobility anchor for this mobile node
9. Protocol Configuration Variables 9. Protocol Configuration Variables
The local mobility anchor MUST allow the following variables to be The local mobility anchor MUST allow the following variables to be
configured by the system management. configured by the system management.
MinDelayBeforeBCEDelete MinDelayBeforeBCEDelete
skipping to change at page 66, line 32 skipping to change at page 70, line 40
with the accepted binding values. By the end of this wait-time, with the accepted binding values. By the end of this wait-time,
if the local mobility anchor did not receive any valid Proxy if the local mobility anchor did not receive any valid Proxy
Binding Update message for that mobility binding, it MUST delete Binding Update message for that mobility binding, it MUST delete
the Binding Cache entry. This delay essentially ensures a mobile the Binding Cache entry. This delay essentially ensures a mobile
node's Binding Cache entry is not deleted too quickly and allows node's Binding Cache entry is not deleted too quickly and allows
some time for the new mobile access gateway to complete the some time for the new mobile access gateway to complete the
signaling for the mobile node. signaling for the mobile node.
The default value for this variable is 10000 milliseconds. The default value for this variable is 10000 milliseconds.
MinDelayBeforeNewBCEAssign 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 500 milliseconds.
TimestampValidityWindow
This variable specifies the maximum amount of time difference in
milliseconds between the timestamp in the received Proxy Binding
Update message and the current time-of-day on the local mobility
anchor, that is allowed by the local mobility anchor for the
received message to be considered valid.
The default value for this variable is 300 milliseconds. This
variable MUST be adjusted to suit the deployments.
The mobile access gateway MUST allow the following variables to be The mobile access gateway MUST allow the following variables to be
configured by the system management. configured by the system management.
EnableMAGLocalrouting EnableMAGLocalrouting
This flag indicates whether or not the mobile access gateway is This flag indicates whether or not the mobile access gateway is
allowed to enable local routing of the traffic exchanged between a allowed to enable local routing of the traffic exchanged between a
visiting mobile node and a correspondent node that is locally visiting mobile node and a correspondent node that is locally
connected to one of the interfaces of the mobile access gateway. connected to one of the interfaces of the mobile access gateway.
The correspondent node can be another visiting mobile node as The correspondent node can be another visiting mobile node as
well, or a local fixed node. well, or a local fixed node.
The default value for this flag is set to "FALSE", indicating that The default value for this flag is set to "FALSE", indicating that
the mobile access gateway MUST reverse tunnel all the traffic to the mobile access gateway MUST reverse tunnel all the traffic to
the mobile node's local mobility anchor. the mobile node's local mobility anchor.
skipping to change at page 67, line 21 skipping to change at page 71, line 40
The default value for this flag is set to "FALSE", indicating that The default value for this flag is set to "FALSE", indicating that
the mobile access gateway MUST reverse tunnel all the traffic to the mobile access gateway MUST reverse tunnel all the traffic to
the mobile node's local mobility anchor. the mobile node's local mobility anchor.
When the value of this flag is set to "TRUE", the mobile access When the value of this flag is set to "TRUE", the mobile access
gateway MUST route the traffic locally. gateway MUST route the traffic locally.
This aspect of local routing MAY be defined as policy on a per This aspect of local routing MAY be defined as policy on a per
mobile basis and when present will take precedence over this flag. mobile basis and when present will take precedence over this flag.
MinPBUReplyTime
This variable specifies the amount of time in milliseconds the
mobile access gateway SHOULD wait for the reply message for the
Proxy Binding Update request that it sent to the local mobility
anchor.
The default value for this variable is 2000 milliseconds.
10. IANA Considerations 10. IANA Considerations
This document defines five new Mobility Header Options, the Home This document defines six new Mobility Header options, the Home
Network Prefix option, Access Technology Type option, Interface Network Prefix option, Handoff Indicator option, Access Technology
Identifier option, Link-local Address option and Timestamp option. Type option, Interface Identifier option, Link-local Address option
These options are described in Sections 8.3, 8.4, 8.5, 8.6 and 8.7 and Timestamp option. These options are described in Section 8. The
respectively. The Type value for these options needs to be assigned Type value for these options needs to be assigned from the same
from the same numbering space as allocated for the other mobility numbering space as allocated for the other mobility options, as
options, as defined in [RFC-3775]. defined in [RFC-3775].
The Mobility Header Option, Access Technology Type option defined in The Access Technology Type option defined in Section 8.5 of this
Section 8.4 of this document introduces a new Access Technology type document introduces a new Access Technology type numbering space,
numbering space, where the values from 0 to 5 have been reserved by where the values from 0 to 5 have been reserved by this document.
this document. Approval of new Access Technology type numbers are to Approval of new Access Technology type numbers are to be made through
be made through IANA Expert Review. IANA Expert Review.
This document also defines new Binding Acknowledgement status values This document also defines new Binding Acknowledgement status values
as described in Section 8.8. The status values MUST be assigned from as described in Section 8.9. The status values MUST be assigned from
the same number space used for Binding Acknowledgement status values, the same number space used for Binding Acknowledgement status values,
as defined in [RFC-3775]. The allocated values for each of these as defined in [RFC-3775]. The allocated values for each of these
status values MUST be greater than 128. status values MUST be greater than 128.
11. Security Considerations 11. Security Considerations
The potential security threats against any network-based mobility The potential security threats against any network-based mobility
management protocol are described in [RFC-4832]. This section management protocol are described in [RFC-4832]. This section
explains how Proxy Mobile IPv6 protocol defends itself against those explains how Proxy Mobile IPv6 protocol defends itself against those
threats. threats.
skipping to change at page 70, line 20 skipping to change at page 74, line 31
[RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H.,
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September
2007. 2007.
13.2. Informative References 13.2. Informative References
[RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
51, RFC 1661, July 1994. 51, RFC 1661, July 1994.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and
P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005. 2005.
[RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005. 4140, August 2005.
[RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
skipping to change at page 71, line 9 skipping to change at page 75, line 17
[RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based
Localized Mobility Management", September 2006. Localized Mobility Management", September 2006.
[RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless
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-5072] Varada, S., Haskin, D. and Allen, E., "IP version 6 over
PPP", RFC 5072, September 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-02.txt,
November 2007. November 2007.
[ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6 [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006. Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006.
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
skipping to change at page 72, line 20 skipping to change at page 76, line 26
For all IPv6 traffic from the source MN-HoA::/128 to For all IPv6 traffic from the source MN-HoA::/128 to
_ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is _ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is
the MAG to LMA tunnel. the MAG to LMA tunnel.
Routing state at the local mobility anchor: Routing state at the local mobility anchor:
For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0, For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0,
next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel. next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel.
Appendix C. Routing State
The following section explains the routing state for a mobile node on
the mobile access gateway. This routing state reflects only one
specific way of implementation and one MAY choose to implement it in
other ways. The policy based route defined below acts as a traffic
selection rule for routing a mobile node's traffic through a specific
tunnel created between the mobile access gateway and that mobile
node's local mobility anchor and with the specific encapsulation
mode, as negotiated.
The below example identifies the routing state for two visiting
mobile nodes, MN1 and MN2 with their respective local mobility
anchors LMA1 and LMA2.
For all traffic from the mobile node, identified by the mobile node's
MAC address, ingress interface or source prefix (MN-HNP) to
_ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA.
+==================================================================+
| Packet Source | Destination Address | Destination Interface |
+==================================================================+
| MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 |
| (IPv6 Prefix or |----------------------------------------------|
| Input Interface) | Locally Connected | Tunnel0 |
+------------------------------------------------------------------+
| MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 |
+ (IPv6 Prefix or -----------------------------------------------|
| Input Interface | Locally Connected | direct |
+------------------------------------------------------------------+
Figure 22: Example - Policy based Route Table
+==================================================================+
| Interface | Source Address | Destination Address | Encapsulation |
+==================================================================+
| Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
| Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 |
+------------------------------------------------------------------+
Figure 23: 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
skipping to change at page 74, line 7 skipping to change at page 79, line 7
Basavaraj Patil Basavaraj Patil
Nokia Siemens Networks Nokia Siemens Networks
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: basavaraj.patil@nsn.com Email: basavaraj.patil@nsn.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 222 change blocks. 
906 lines changed or deleted 1125 lines changed or added

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