draft-ietf-netlmm-proxymip6-05.txt   draft-ietf-netlmm-proxymip6-06.txt 
NETLMM WG S. Gundavelli NETLMM WG S. Gundavelli
Internet-Draft K. Leung Internet-Draft K. Leung
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: March 17, 2008 V. Devarapalli Expires: March 26, 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
September 14, 2007 September 23, 2007
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-05.txt draft-ietf-netlmm-proxymip6-06.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 March 17, 2008. This Internet-Draft will expire on March 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This specification describes a network-based mobility management This specification describes a network-based mobility management
protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6
[RFC-3775]. This protocol enables mobility support to a host without [RFC-3775]. This protocol enables mobility support to a host without
requiring its participation in any mobility related signaling. The requiring its participation in any mobility related signaling. The
design principle in the case of network-based mobility management design principle in the case of a network-based mobility management
protocol relies on the network being in control of the mobility protocol relies on the network being in control of the mobility
management. The mobility entities in the network are responsible for management. The mobility entities in the network are responsible for
tracking the movements of the host and initiating the required tracking the movements of the host and initiating the required
mobility signaling on its behalf. mobility signaling on its behalf.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . 13 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 13
4.1. Peer Authorization Database Entries . . . . . . . . . . . 13 4.1. Peer Authorization Database Entries . . . . . . . . . . . 13
4.2. Security Policy Database Entries . . . . . . . . . . . . . 14 4.2. Security Policy Database Entries . . . . . . . . . . . . . 14
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15
5.1. Extensions to Binding Cache Entry Data Structure . . . . . 15 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 15
5.2. Supported Home Network Prefix Models . . . . . . . . . . . 16 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 16
5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 16 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 16
5.4. Timestamp Option for Message Ordering . . . . . . . . . . 21 5.4. Timestamp Option for Message Ordering . . . . . . . . . . 21
5.5. Routing Considerations . . . . . . . . . . . . . . . . . . 23 5.5. Routing Considerations . . . . . . . . . . . . . . . . . . 24
5.5.1. Bi-Directional Tunnel Management . . . . . . . . . . . 23 5.5.1. Bi-Directional Tunnel Management . . . . . . . . . . . 24
5.5.2. Forwarding Considerations . . . . . . . . . . . . . . 24 5.5.2. Forwarding Considerations . . . . . . . . . . . . . . 25
5.6. Local Mobility Anchor Address Discovery . . . . . . . . . 25 5.6. Local Mobility Anchor Address Discovery . . . . . . . . . 25
5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 25 5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 26
5.8. Route Optimizations Considerations . . . . . . . . . . . . 25 5.8. Route Optimizations Considerations . . . . . . . . . . . . 26
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 27
6.1. Extensions to Binding Update List Entry Data Structure . . 26 6.1. Extensions to Binding Update List Entry Data Structure . . 27
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 27 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 28
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 28 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 29
6.4. Supported Address Configuration Models . . . . . . . . . . 28 6.4. Supported Address Configuration Models . . . . . . . . . . 29
6.5. Access Authentication & Mobile Node Identification . . . . 29 6.5. Access Authentication & Mobile Node Identification . . . . 30
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 29 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 30
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 30 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 31
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 30 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 31
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 31 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 33
6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 32 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 33
6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 35 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 36
6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 36 6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 37
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 36 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 37
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 37 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 38
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 37 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 38
6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 38 6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 39
6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 39 6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 40
6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 39 6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 40
6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 39 6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 40
6.11. Interaction with DHCP Relay Agent . . . . . . . . . . . . 40 6.11. Supporting DHCPv6 based Address Configuration on the
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 41 Access Link . . . . . . . . . . . . . . . . . . . . . . . 42
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 41 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 43
6.14. Allowing network access to other IPv6 nodes . . . . . . . 42 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 43
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 42 6.14. Allowing network access to other IPv6 nodes . . . . . . . 44
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 43 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 44
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 44 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 45
7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 44 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 46
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 45 7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 46
8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 46 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 47
8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 47 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 48
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 48 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 49
8.4. Link-local Address Option . . . . . . . . . . . . . . . . 50 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 50
8.5. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 51 8.4. Link-local Address Option . . . . . . . . . . . . . . . . 52
8.6. Status Values . . . . . . . . . . . . . . . . . . . . . . 51 8.5. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 53
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 53 8.6. Status Values . . . . . . . . . . . . . . . . . . . . . . 53
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 55
11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 11. Security Considerations . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . . 55 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 57 Infrastructure . . . . . . . . . . . . . . . . . . . 59
Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 57 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . . . . . 62
1. Introduction 1. Introduction
Mobile IPv6 [RFC-3775] is the enabler for IPv6 mobility. It requires Mobile IPv6 [RFC-3775] is the enabler for IPv6 mobility. It requires
Mobile IPv6 client functionality in the IPv6 stack of a mobile node. Mobile IPv6 client functionality in the IPv6 stack of a mobile node.
Signaling between the mobile node and home agent enables the creation Signaling between the mobile node and home agent enables the creation
and maintenance of a binding between the mobile node's home address and maintenance of a binding between the mobile node's home address
and care-of-address. Mobile IPv6 has been designed to be an integral and care-of-address. Mobile IPv6 has been designed to be an integral
part of the IPv6 stack in a host. However there exist IPv6 stacks part of the IPv6 stack in a host. However there exist IPv6 stacks
today that do not have Mobile IPv6 functionality and there would today that do not have Mobile IPv6 functionality and there would
skipping to change at page 5, line 27 skipping to change at page 5, line 27
3775]. 3775].
This document adopts the terms, Local Mobility Anchor (LMA) and This document adopts the terms, Local Mobility Anchor (LMA) and
Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC- Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC-
4831]. This document also provides the following context specific 4831]. This document also provides the following context specific
explanation to the following terms used in this document. explanation to the following terms used in this document.
Proxy Mobile IPv6 Domain (PMIPv6-Domain) Proxy Mobile IPv6 Domain (PMIPv6-Domain)
Proxy Mobile IPv6 domain refers to the network where the mobility Proxy Mobile IPv6 domain refers to the network where the mobility
management of a mobile node is handled using Proxy Mobile IPv6 management of a mobile node is handled using the Proxy Mobile IPv6
protocol as defined in this specification. The Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6
domain includes local mobility anchors and mobile access gateways domain includes local mobility anchors and mobile access gateways
between which security associations can be setup and authorization between which security associations can be setup and authorization
for sending Proxy Binding Updates on behalf of the mobile nodes for sending Proxy Binding Updates on behalf of the mobile nodes
can be ensured. can be ensured.
Local Mobility Anchor (LMA) Local Mobility Anchor (LMA)
Local Mobility Anchor is the home agent for the mobile node in the Local Mobility Anchor is the home agent for the mobile node in the
Proxy Mobile IPv6 domain. It is the topological anchor point for Proxy Mobile IPv6 domain. It is the topological anchor point for
the mobile node's home network prefix and is the entity that the mobile node's home network prefix and is the entity that
manages the mobile node's reachability state. It is important to manages the mobile node's reachability state. It is important to
understand that the local mobility anchor has the functional understand that the local mobility anchor has the functional
capabilities of a home agent as defined in Mobile IPv6 base capabilities of a home agent as defined in Mobile IPv6 base
specification [RFC-3775] and with the additional required specification [RFC-3775] and with the additional capabilities
capabilities for supporting Proxy Mobile IPv6 protocol as defined required for supporting Proxy Mobile IPv6 protocol as defined in
in this specification. 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 on the access link and for signaling the mobile node's local
mobility anchor. mobility anchor.
Mobile Node (MN) Mobile Node (MN)
Through out this document, the term mobile node is used to refer Throughout this document, the term mobile node is used to refer to
to an IP host whose mobility is managed by the network. The an IP host whose mobility is managed by the network. The mobile
mobile node may be operating in IPv6 mode, IPv4 mode or in IPv4/ node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual
IPv6 dual mode. The mobile node is not required to participate in mode. The mobile node is not required to participate in any
any mobility related signaling for achieving mobility for an IP mobility related signaling for achieving mobility for an IP
address that is obtained in that Proxy Mobile IPv6 domain. This address that is obtained in that Proxy Mobile IPv6 domain. This
document further uses explicit text when referring to a mobile document further uses explicit text when referring to a mobile
node that is involved in mobility related signaling as per Mobile node that is involved in mobility related signaling as per Mobile
IPv6 specification [RFC-3775]. 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
skipping to change at page 8, line 19 skipping to change at page 8, line 19
[RFC-3775]. [RFC-3775].
Proxy Mobile IPv6 protocol is intended for providing network-based Proxy Mobile IPv6 protocol is intended for providing network-based
mobility management support to a mobile node, without requiring the mobility management support to a mobile node, without requiring the
participation of the mobile node in any mobility related signaling. participation of the mobile node in any mobility related signaling.
The mobility entities in the network will track the mobile node's The mobility entities in the network will track the mobile node's
movements and will initiate the mobility signaling and setup the movements and will initiate the mobility signaling and setup the
required routing state. 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 and the Mobile Access Gateway. The local Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The
mobility is responsible for maintaining the mobile node's local mobility anchor is responsible for maintaining the mobile
reachability state and is the topological anchor point for the mobile node's reachability state and is the topological anchor point for the
node's home network prefix. While 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 on its access link and for sending binding
registrations to the mobile node's local mobility anchor. registrations to the mobile node's local mobility 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 9, line 4 skipping to change at page 9, line 27
\\ // \\ \\ // \\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
Proxy-CoA1--> | | <-- Proxy-CoA2 Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+ +----+ +----+
|MAG1|-----{MN2} |MAG2| |MAG1|-----{MN2} |MAG2|
+----+ | +----+ +----+ | +----+
| | | | | |
MN-HoA1 --> | MN-HoA2 | <-- MN-HoA3 MN-HoA1 --> | MN-HoA2 | <-- MN-HoA3
{MN1} {MN3} {MN1} {MN3}
Figure 1: Proxy Mobile IPv6 Domain Figure 1: Proxy Mobile IPv6 Domain
Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to
an access network, the mobile access gateway on that access network an access network, the mobile access gateway on that access network,
after identifying the mobile node and acquiring its identifier, will after identifying the mobile node and acquiring its identifier, will
determine if the mobile node is authorized for network-based mobility determine if the mobile node is authorized for network-based mobility
management service. management service.
If the network determines that the network-based mobility management If the network determines that the network-based mobility management
service needs to be offered to that mobile node, the network will service needs to be offered to that mobile node, the network will
ensure that the mobile node using any of the address configuration ensure that the mobile node using any of the address configuration
mechanisms permitted by the network, will be able to obtain an mechanisms permitted by the network, will be able to obtain an
address from its home network prefix and move anywhere in that proxy address from its home network prefix and move anywhere in that proxy
mobile IPv6 domain. From the perspective of the mobile node, the mobile IPv6 domain. From the perspective of the mobile node, the
skipping to change at page 11, line 22 skipping to change at page 11, line 31
on-link-prefix. on-link-prefix.
The mobile node on receiving these Router Advertisement messages on The mobile node on receiving these Router Advertisement messages on
the access link will attempt to configure its interface either using the access link will attempt to configure its interface either using
stateful or stateless address configuration modes, based on the modes stateful or stateless address configuration modes, based on the modes
that are permitted on that access link. At the end of a successful that are permitted on that access link. At the end of a successful
address configuration procedure, the mobile node will end up with an address configuration procedure, the mobile node will end up with an
address from its home network prefix. address from its home network prefix.
Once the address configuration is complete, the mobile node has a Once the address configuration is complete, the mobile node has a
valid address from its home network prefix, at the current point of valid address from its home network prefix at the current point of
attachment. The serving mobile access gateway and the local mobility attachment. The serving mobile access gateway and the local mobility
anchor also have proper routing states for handling the traffic sent anchor also have proper routing states for handling the traffic sent
to and from the mobile node using an address from its home network to and from the mobile node using an address from its home network
prefix. prefix.
The local mobility anchor, being the topological anchor point for the The local mobility anchor, being the topological anchor point for the
mobile node's home network prefix, receives any packets that are sent mobile node's home network prefix, receives any packets that are sent
by any corresponding node to the mobile node. Local mobility anchor by any correspondent node to the mobile node. Local mobility anchor
forwards these received packets to the mobile access gateway through forwards these received packets to the mobile access gateway through
the bi-directional tunnel. The mobile access gateway on other end of the bi-directional tunnel. The mobile access gateway on other end of
the tunnel, after receiving the packet, removes the outer header and the tunnel, after receiving the packet, removes the outer header and
forwards the packet on the access link to the mobile node. forwards the packet on the access link to the mobile node.
The mobile access gateway typically acts as a default router on the The mobile access gateway typically acts as a default router on the
access link. Any packet that the mobile node sends to any access link. Any packet that the mobile node sends to any
corresponding node will be received by the mobile access gateway and correspondent node will be received by the mobile access gateway and
will be sent to its local mobility anchor through the bi-directional will be sent to its local mobility anchor through the bi-directional
tunnel. The local mobility anchor on the other end of the tunnel, tunnel. The local mobility anchor on the other end of the tunnel,
after receiving the packet removes the outer header and routes the after receiving the packet, removes the outer header and routes the
packet to the destination. packet to the destination.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | |p-MAG| | LMA | |n-MAG| | MN | |p-MAG| | LMA | |n-MAG|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | |
| |==Bi-Dir Tunnel=| | | |==Bi-Dir Tunnel=| |
MN Detached | | | MN Detached | | |
| MN Detached Event | | | MN Detached Event | |
| | | | | | | |
skipping to change at page 12, line 41 skipping to change at page 12, line 41
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
scenario. scenario.
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 new access link, will signal the local mobile access gateway on the new access link will signal the local
mobility anchor for updating the binding and routing state. The mobility anchor for updating the binding and routing state. The
mobile node will continue to receive the Router Advertisements mobile node will continue to receive the Router Advertisements
containing its home network prefix, making it believe its still on containing its home network prefix, making it believe it's still on
the same link and can use the same address configuration on the new the same link and can use the same address configuration on the new
access link. access link.
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. A association(s) offering integrity and data origin authentication. A
security association with the mobile node for which the signaling security association with the mobile node for which the signaling
skipping to change at page 13, line 33 skipping to change at page 13, line 33
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.
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, this is not a messages or sending binding updates. Therefore, this is not a
concern. However, the local mobility anchor MUST allow only concern. However, the local mobility anchor MUST allow only
authorized mobile access gateways to create binding cache entries on authorized mobile access gateways to create binding cache entries on
behalf of the mobile nodes. The actual mechanism by which the local behalf of the mobile nodes. The actual mechanism by which the local
mobility anchor verifies if a specific mobile access gateway is mobility anchor verifies if a specific mobile access gateway is
authorized to send Proxy Binding Updates on behalf of a mobile node authorized to send Proxy Binding Updates on behalf of a mobile node
skipping to change at page 14, line 41 skipping to change at page 14, line 41
In the examples shown below, the identity of the mobile access In the examples shown below, the identity of the mobile access
gateway is assumed to be mag_1, the address of the mobile access gateway is assumed to be mag_1, the address of the mobile access
gateway is assumed to be mag_address_1, and the address of the local gateway is assumed to be mag_address_1, and the address of the local
mobility anchor is assumed to be lma_address_1. mobility anchor is assumed to be lma_address_1.
mobile access gateway SPD-S: mobile access gateway SPD-S:
- IF local_address = mag_address_1 & - IF local_address = mag_address_1 &
remote_address = lma_address_1 & remote_address = lma_address_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BA proto = MH & local_mh_type = BU & remote_mh_type = BA
Then use SA ESP transport mode Then use SA ESP transport mode
Initiate using IDi = mag_1 to address lma_1 Initiate using IDi = mag_1 to address lma_address_1
local mobility anchor SPD-S: local mobility anchor SPD-S:
- IF local_address = lma_address_1 & - IF local_address = lma_address_1 &
remote_address = mag_address_1 & remote_address = mag_address_1 &
proto = MH & local_mh_type = BA & remote_mh_type = BU proto = MH & local_mh_type = BA & remote_mh_type = BU
Then use SA ESP transport mode Then use SA ESP transport mode
5. Local Mobility Anchor Operation 5. Local Mobility Anchor Operation
For supporting the Proxy Mobile IPv6 protocol specified in this For supporting the Proxy Mobile IPv6 protocol specified in this
document, the home agent function, specified in [RFC-3775] requires document, the home agent function, specified in [RFC-3775] requires
certain functional modifications and enhancements. The home agent certain functional modifications and enhancements. The home agent
with these modifications and enhanced capabilities for supporting with these modifications and enhanced capabilities for supporting
Proxy Mobile IPv6 protocol is referred to as the local mobility Proxy Mobile IPv6 protocol is referred to as the local mobility
anchor. anchor.
The section describes the operational details of the local mobility This section describes the operational details of the local mobility
anchor. anchor.
5.1. Extensions to Binding Cache Entry Data Structure 5.1. Extensions to Binding Cache Entry Data Structure
Every local mobility anchor MUST maintain a Binding Cache entry for Every local mobility anchor MUST maintain a Binding Cache entry for
each currently registered mobile node. Binding Cache entry is a each currently registered mobile node. 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.
skipping to change at page 17, line 47 skipping to change at page 17, line 47
Acknowledgement message with Status field set to 129 Acknowledgement message with Status field set to 129
(Administratively Prohibited). (Administratively Prohibited).
o The local mobility anchor MUST apply the considerations specified o The local mobility anchor MUST apply the considerations specified
in Section 5.4, for processing the Sequence Number field and the in Section 5.4, for processing the Sequence Number field and the
Timestamp option, in the Proxy Binding Update request. Timestamp option, in the Proxy Binding Update request.
o The local mobility anchor MUST use the identifier in the NAI o The local mobility anchor MUST use the identifier in the NAI
option [RFC-4283] present in the Proxy Binding Update request for option [RFC-4283] present in the Proxy Binding Update request for
performing the Binding Cache entry existence test. If the entry performing the Binding Cache entry existence test. If the entry
does not exist, the local mobility MUST consider this request as does not exist, the local mobility anchor MUST consider this
an initial binding registration request. request as an initial binding registration request. If the entry
exists, the local mobility anchor MUST consider this request as an
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: Initial Binding Registration:
o If the Home Network Prefix option present in the Proxy Binding o If the Home Network Prefix option present in the Proxy Binding
Update request has the value 0::/0, the local mobility anchor MUST Update request has the value 0::/0, the local mobility anchor MUST
allocate a prefix for the mobile node and send a Proxy Binding allocate a prefix for the mobile node and send a Proxy Binding
Acknowledgement message including the Home Network Prefix option Acknowledgement message including the Home Network Prefix option
containing the allocated prefix value. The specific details on containing the allocated prefix value. The specific details on
how the local mobility anchor allocates the home network prefix is how the local mobility anchor allocates the home network prefix is
outside the scope of this document. The local mobility anchor outside the scope of this document. The local mobility anchor
skipping to change at page 19, line 5 skipping to change at page 19, line 9
Binding Re-Registration: Binding Re-Registration:
o If the requesting prefix in the Home Network Prefix option is a o If the requesting prefix in the Home Network Prefix option is a
non 0::/0 value and is different from what is present in the non 0::/0 value and is different from what is present in the
currently active Binding Cache entry for that mobile node, the currently active Binding Cache entry for that mobile node, the
local mobility anchor MUST reject the request and send a Proxy local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to 129 Binding Acknowledgement message with Status field set to 129
(Administratively Prohibited). (Administratively Prohibited).
o If there is a Link-local Address option present in the request
with a value other than ALL_ZERO (not set), and upon accepting the
binding re-registration request, the local mobility anchor MUST
update the link-local address field in the Binding Cache entry to
the address value received in the request.
o Upon accepting a Proxy Binding Update request for extending the o Upon accepting a Proxy Binding Update request for extending the
lifetime of a currently active binding for a mobile node, the lifetime of a currently active binding for a mobile node, the
local mobility anchor MUST update the existing Binding Cache entry local mobility anchor MUST update the existing Binding Cache entry
for this mobile node. Unless there exists an established bi- for this mobile node. Unless there exists an established bi-
directional tunnel to the mobile access gateway with the same directional tunnel to the mobile access gateway with the same
transport and encapsulation mode, the local mobility anchor MUST transport and encapsulation mode, the local mobility anchor MUST
create a tunnel to the mobile access gateway, as described in create a tunnel to the mobile access gateway, as described in
[RFC-2473] and also delete the existing tunnel route to the [RFC-2473] and also delete the existing tunnel route to the
previous mobile access gateway. It MUST also send a Proxy Binding previous mobile access gateway. It MUST also send a Proxy Binding
Acknowledgement message to the mobile access gateway with the Acknowledgement message to the mobile access gateway with the
Status field set to 0 (Proxy Binding Update Accepted). Status field set to 0 (Proxy Binding Update Accepted).
Binding De-Registration: Binding De-Registration:
o If the prefix in the Home Network Prefix option is a 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).
o If the received Proxy Binding Update request with the lifetime o If the received Proxy Binding Update request with the lifetime
value of 0, has a Source Address in the IPv6 header, different value of zero, has a Source Address in the IPv6 header, different
from what is present in the Proxy-CoA address field in its Binding from what is present in the Proxy-CoA address field in the Binding
Cache entry, the local mobility anchor MAY either choose to ignore Cache entry existing for that mobile node, the local mobility
the request or send a valid Proxy Binding Acknowledgement message anchor MAY either choose to ignore the request or send a valid
with the Status field set to 0 (Proxy Binding Update Accepted). Proxy Binding Acknowledgement message with the Status field set to
0 (Proxy Binding Update Accepted). However, it MUST NOT delete
the mobile node's Binding Cache entry or modify the routing state
created for that mobile node.
o Upon accepting the Proxy Binding Update request for a mobile node, o Upon accepting the Proxy Binding Update request for a mobile node,
with the lifetime value of zero, the local mobility anchor MUST with the lifetime value of zero, the local mobility anchor MUST
wait for MinDelayBeforeBCEDelete amount of time, before it deletes wait for MinDelayBeforeBCEDelete amount of time, before it deletes
the mobile node's Binding Cache entry. Within this wait period, the mobile node's Binding Cache entry. Within this wait period,
if the local mobility anchor receives a Proxy Binding Update if the local mobility anchor receives a Proxy Binding Update
request message for the same mobile node and from a different request message for the same mobile node with the lifetime value
mobile access gateway, with the lifetime value of greater than of greater than zero, and if that request is accepted, then the
zero, and if that request is accepted, then the Binding Cache Binding Cache entry MUST NOT be deleted, but must be updated with
entry MUST NOT be deleted, but must be updated with the new the newly accepted registration values. The local mobility anchor
values. However, the local mobile anchor MUST send the Proxy MUST send the Proxy Binding Acknowledgement message, immediately
Binding Acknowledgement message, immediately upon accepting the upon accepting the request. However, within this wait period, if
request. the local mobility anchor does not receive any valid binding
registration request for that mobile node, then at the end of this
o Upon accepting the request, the local mobility anchor MUST delete wait period, it MUST delete the mobile node's Binding Cache entry
the mobile node's Binding Cache entry and remove the Routing state and remove the routing state created for that mobile node.
for the mobile node's home network prefix.
Constructing the Proxy Binding Acknowledgement Message: 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 is set*/
skipping to change at page 20, line 24 skipping to change at page 20, line 40
Proxy Binding Acknowledgement message format Proxy Binding Acknowledgement message format
o The Source Address field in the IPv6 header of the message SHOULD o The Source Address field in the IPv6 header of the message SHOULD
be set to the destination address of the received Proxy Binding be 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
SHOULD be set to the source address of the received Proxy Binding SHOULD be set to the source address of the received Proxy Binding
Update request. Update request.
o If the Status field is set to a value greater less than 128, i.e. o The Home Network Prefix option MUST be present in the Proxy
if the binding request was rejected, then the prefix value in the Binding Acknowledgement message if and only if the same option was
Home Network Prefix option MUST be set to the prefix value from present in the corresponding Proxy Binding Update request message.
the received Home Network Prefix option. For all other cases, the
prefix value MUST be set to the allocated prefix value for that o If the Status field is set to a value greater than or equal to
mobile node. 128, i.e., if the binding request was rejected, then the prefix
value in the Home Network Prefix option MUST be set to the prefix
value from the received Home Network Prefix option. For all other
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 Link-local Address option MUST be present in the Proxy Binding
Acknowledgement message, if the same option was present in the Acknowledgement message if and only if the same option was present
corresponding Proxy Binding Update request message. If there is in the corresponding Proxy Binding Update request message.
an existing Binding Cache entry for that mobile node with the
link-local address value of ALL_ZERO (value not set), or if there o If the Status field is set to a value greater than or equal to
was no existing Binding Cache entry, then the link-local address 128, i.e., if the binding request was rejected, then the link-
MUST be copied from the received Link-local Address option in the 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
with the link-local address value of ALL_ZERO (value not set), or
if there was no existing Binding Cache entry, then the link-local
address MUST be copied from the Link-local Address option in the
received Proxy Binding Update request. For all other cases, it received Proxy Binding Update request. For all other cases, it
MUST be copied from the Binding Cache entry. MUST be copied from the mobile node's Binding Cache entry.
o Considerations from Section 5.4 must be applied for constructing o Considerations from Section 5.4 must be applied for constructing
the Timestamp option. the Timestamp option.
o The identifier in the NAI option [RFC-4283] MUST be copied from o The identifier in the NAI option [RFC-4283] MUST be copied from
the received Proxy Binding Update request. If the Status field the received Proxy Binding Update request. If the Status field
value is set to MISSING_MN_IDENTIFIER_OPTION, the NAI option MUST value is set to MISSING_MN_IDENTIFIER_OPTION, the NAI option MUST
NOT be present in the reply message. NOT be present in the Proxy Binding Acknowledgement message.
o The message MUST be protected by using IPsec, using the security o The message MUST be protected by using IPsec, using the security
association existing between the local mobility anchor and the association existing between the local mobility anchor and the
mobile access gateway. mobile access gateway.
o The Type 2 Routing header, MUST NOT be present in the IPv6 header o The Type 2 Routing header MUST NOT be present in the IPv6 header
of the packet. of the packet.
5.4. Timestamp Option for Message Ordering 5.4. 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 context transfer mechanism, the serving mobile in the absence of context transfer mechanism, the serving mobile
access gateway will be unable to determine the sequence number that access gateway will be unable to determine the sequence number that
it needs to use in the signaling messages. Hence, the sequence it needs to use in the signaling messages. Hence, the sequence
number scheme as specified in [RFC-3775], will be insufficient for number scheme, as specified in [RFC-3775], will be insufficient for
Proxy Mobile IPv6. Proxy Mobile IPv6.
If the local mobility anchor cannot determine the sending order of If the local mobility anchor cannot determine the sending order of
the received binding registration messages, it may potentially the received binding registration messages, it may potentially
process an older message sent by a mobile access gateway, where the process an older message sent by a mobile access gateway where the
mobile node was previously anchored, resulting in an incorrect mobile node was previously anchored, resulting in an incorrect
Binding Cache entry. Binding Cache entry.
For solving this problem, this specification adopts two alternative For solving this problem, this specification adopts two alternative
solutions, one is based on timestamps and the other based on sequence solutions. One is based on timestamps and the other based on
numbers, as defined in [RFC-3775]. sequence numbers, as defined in [RFC-3775].
The basic principle behind the use of timestamps in binding The basic principle behind the use of timestamps in binding
registration messages is that the node generating the message inserts registration messages is that the node generating the message inserts
the current time-of-day, and the node receiving the message checks the current time-of-day, and the node receiving the message checks
that this timestamp is greater than all previously accepted that this timestamp is greater than all previously accepted
timestamps. The timestamp based solution may be used, when the timestamps. The timestamp based solution may be used, when the
serving mobile access gateways in a Proxy Mobile IPv6 domain do not serving mobile access gateways in a Proxy Mobile IPv6 domain do not
have the ability to obtain the last sequence number that was sent in have the ability to obtain the last sequence number that was sent in
a binding registration message for updating a given mobile node's a binding registration message for updating a given mobile node's
binding. binding.
As an alternative to the Timestamp based approach, the specification As an alternative to the Timestamp based approach, the specification
also allows the use of Sequence Number based scheme, as per [RFC- also allows the use of Sequence Number based scheme, as per [RFC-
3775]. However, for this scheme to work, the serving mobile access 3775]. However, for this scheme to work, the serving mobile access
gateways in a Proxy Mobile IPv6 domain MUST have the ability to gateways in a Proxy Mobile IPv6 domain MUST have the ability to
obtain the last sequence number that was sent in a binding obtain the last sequence number that was sent in a binding
registration message for updating a given mobile node's binding. The registration message for updating a given mobile node's binding. The
sequence number MUST be maintained on a per mobile node basis and sequence number MUST be maintained on a per mobile node basis and
MUST be synchronized between the serving mobile access gateways. MUST be synchronized between the serving mobile access gateways.
However, the specific details on how a mobile node's sequence number This may be achieved by using context transfer schemes or by
is synchronized between different mobile access gateways is outside maintaining the sequence number in a policy store. However, the
the scope of this document. specific details on how the mobile node's sequence number is
synchronized between different mobile access gateways is outside the
scope of this document.
Using Timestamps based approach: Using Timestamps based approach:
o An implementation MUST support Timestamp option. If the Timestamp o A local mobility anchor implementation MUST support Timestamp
option is present in the received Proxy Binding Update request option. If the Timestamp option is present in the received Proxy
message, then the local mobility anchor MUST include a valid Binding Update request message, then the local mobility anchor
Timestamp option in the Proxy Binding Acknowledgement message that MUST include a valid Timestamp option in the Proxy Binding
it sends to the mobile access gateway. Acknowledgement message that it sends to the mobile access
gateway.
o All the mobility entities in a Proxy Mobile IPv6 domain, o All the mobility entities in a Proxy Mobile IPv6 domain that are
exchanging binding registration messages using Timestamp option exchanging binding registration messages using the Timestamp
must have adequately synchronized time-of-day clocks. This is the option must have adequately synchronized time-of-day clocks. This
essential requirement for this solution to work. If this is the essential requirement for this solution to work. If this
requirement is not met, the solution will not predictably work in requirement is not met, the solution will not predictably work in
all cases. all cases.
o The mobility entities in a Proxy Mobile IPv6 domain SHOULD o The mobility entities in a Proxy Mobile IPv6 domain SHOULD
synchronize their clocks to a common time source. For synchronize their clocks to a common time source. For
synchronizing the clocks, the nodes may use Network Time Protocol synchronizing the clocks, the nodes may use Network Time Protocol
[RFC-4330]. Deployments may also adopt other approaches suitable [RFC-4330]. Deployments may also adopt other approaches suitable
for that specific deployment. for that specific deployment.
o When generating the timestamp value for building the Timestamp o 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.5]. specified in the format for the Timestamp option [Section 8.5].
o If the Timestamp option is present in the received Proxy Binding
Update message, the local mobility anchor MUST ignore the sequence
number field in the message. However, it MUST copy the sequence
number from the received Proxy Binding Update message to the Proxy
Binding Acknowledgement message.
o Upon receipt of a Proxy Binding Update message with the Timestamp o 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 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.
o If the Timestamp option is present in the received Proxy Binding
Update message, the local mobility anchor MUST ignore the sequence
number field in the message. However, it MUST copy the sequence
number from the received Proxy Binding Update message to the Proxy
Binding Acknowledgement message.
o If the timestamp value in the received Proxy Binding Update is o If the timestamp value in the received Proxy Binding Update is
valid, the local mobility anchor MUST return the same timestamp valid (validity as specified in the above considerations), the
value in the Timestamp option included in the Proxy Binding local mobility anchor MUST return the same timestamp value in the
Acknowledgement message that it sends to the mobile access Timestamp option included in the Proxy Binding Acknowledgement
gateway. message that it sends to the mobile access gateway.
o If the timestamp value in the received Proxy Binding Update is not o If the timestamp value in the received Proxy Binding Update is not
valid, the local mobility anchor MUST reject the Proxy Binding valid (validity as specified in the above considerations), the
Update and send a Proxy Binding Acknowledgement message with local mobility anchor MUST reject the Proxy Binding Update and
Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The send a Proxy Binding Acknowledgement message with Status field set
message MUST also include the Timestamp option with the value set to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST also
to the current time-of-day on the local mobility anchor. include the Timestamp option with the value set to the current
time-of-day on the local mobility anchor.
Using Sequence Number based approach: Using Sequence Number based approach:
o If the Timestamp option is not present in the received Proxy o If the Timestamp option is not present in the received Proxy
Binding Update request, the local mobility anchor MUST fallback to Binding Update request, the local mobility anchor MUST fallback to
the Sequence Number based scheme. It MUST process the sequence the Sequence Number based scheme. It MUST process the sequence
number field as specified in [RFC-3775]. Also, it MUST NOT number field as specified in [RFC-3775]. Also, it MUST NOT
include the Timestamp option in the Proxy Binding Acknowledgement include the Timestamp option in the Proxy Binding Acknowledgement
messages that it sends to the mobile access gateway. messages that it sends to the mobile access gateway.
skipping to change at page 24, line 9 skipping to change at page 24, line 45
o The tunnel between the local mobility anchor and the mobile access o The tunnel between the local mobility anchor and the mobile access
gateway is typically a shared tunnel and can be used for routing gateway is typically a shared tunnel and can be used for routing
traffic streams for different mobile nodes attached to the same traffic streams for different mobile nodes attached to the same
mobile access gateway. mobile access gateway.
o Implementations typically use a software timer for managing the o Implementations typically use a software timer for managing the
tunnel lifetime and a counter for keeping a count of all the tunnel lifetime and a counter for keeping a count of all the
mobile nodes that are sharing the tunnel. The timer value will be mobile nodes that are sharing the tunnel. The timer value will be
set to the accepted binding life-time and will be updated after set to the accepted binding life-time and will be updated after
each periodic registrations for extending the lifetime. If the each periodic re-registration for extending the lifetime. If the
tunnel is shared for multiple mobile nodes, the tunnel lifetime tunnel is shared for multiple mobile nodes, the tunnel lifetime
will be set to the highest binding lifetime that is granted to any will be set to the highest binding lifetime that is granted to any
one of those mobile nodes sharing that tunnel. one of those mobile nodes sharing that tunnel.
5.5.2. Forwarding Considerations 5.5.2. Forwarding Considerations
Intercepting Packets Sent to the Mobile Node's Home Network: Intercepting Packets Sent to the Mobile Node's Home Network:
o When the local mobility anchor is serving a mobile node, it MUST o When the local mobility anchor is serving a mobile node, it MUST
be able to receive packets that are sent to the mobile node's home be able to receive packets that are sent to the mobile node's home
network. In order for it to receive those packets, it MUST network. In order for it to receive those packets, it MUST
advertise a connected route in to the Routing Infrastructure for advertise a connected route in to the Routing Infrastructure for
the mobile node's home network prefix or for an aggregated prefix the mobile node's home network prefix or for an aggregated prefix
with a larger scope. This essentially enables IPv6 routers in with a larger scope. This essentially enables IPv6 routers in
that network to detect the local mobility anchor as the last-hop that network to detect the local mobility anchor as the last-hop
router for that prefix. router for that prefix.
Forwarding Packets to the Mobile Node: Forwarding Packets to the Mobile Node:
o On receiving a packet from a corresponding node with the o On receiving a packet from a correspondent node with the
destination address matching a mobile node's home network prefix, destination address matching a mobile node's home network prefix,
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*/
skipping to change at page 25, line 39 skipping to change at page 26, line 30
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.7. Mobile Prefix Discovery Considerations 5.7. Mobile Prefix Discovery Considerations
The ICMP Mobile Prefix Advertisement message, described in Section The ICMP Mobile Prefix Advertisement message, described in Section
6.8 and Section 11.4.3 of [RFC-3775], allows a home agent to send a 6.8 and Section 11.4.3 of [RFC-3775], allows a home agent to send a
Mobile Prefix Advertisement to the mobile node. Mobile Prefix Advertisement to the mobile node.
In Proxy Mobile IPv6, the mobile node's home network prefix is hosted 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 on the access link connected to the mobile access gateway, but it is
topologically anchored on the local mobility anchor. Since, there is topologically anchored on the local mobility anchor. Since there is
no physical home-link for the mobile node's home network prefix on 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 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 link where the prefix is hosted, any prefix change messages can just
be advertised by the mobile access gateway on the access link and be advertised by the mobile access gateway on the access link and
thus there is no applicability of this message for Proxy Mobile IPv6. thus there is no applicability of this message for Proxy Mobile IPv6.
Hence, this specification does not support Mobile Prefix Discovery. Hence, this specification does not support Mobile Prefix Discovery.
5.8. Route Optimizations Considerations 5.8. 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 corresponding 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 corresponding 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 mobility In Proxy Mobile IPv6, the mobile node is not involved in any mobility
related signaling. The mobile node uses only its home address for related signaling. The mobile node uses only its home address for
all its communication and the Care-of address (Proxy-CoA) is not all its communication and the Care-of address (Proxy-CoA) is not
visible to the mobile node. Hence, the Return Routability procedure visible to the mobile node. Hence, the Return Routability procedure
as defined in Mobile IPv6 cannot be used in Proxy Mobile IPv6. as defined in Mobile IPv6 cannot be used in Proxy Mobile IPv6.
6. Mobile Access Gateway Operation 6. Mobile Access Gateway Operation
The Proxy Mobile IPv6 protocol described in this document, introduces The Proxy Mobile IPv6 protocol described in this document introduces
a new functional entity, the Mobile Access Gateway (MAG). The mobile a new functional entity, the Mobile Access Gateway (MAG). The mobile
access gateway is the entity that is responsible for detecting the access gateway is the entity that is responsible for detecting the
mobile node's movements on its access link and sending the binding mobile node's movements on its access link and sending the binding
registration requests to the local mobility anchor. In essence, the registration requests to the local mobility anchor. In essence, the
mobile access gateway performs mobility management on behalf of a mobile access gateway performs mobility management on behalf of a
mobile node. 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 is 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
access link and for initiating the mobility signaling with the access link and for initiating the mobility signaling with the
mobile node's local mobility anchor. mobile node's local mobility anchor.
o Emulation of the mobile node's home link on the access link by o Emulation of the mobile node's home link on the access link by
sending Router Advertisements with the mobile node's home network sending Router Advertisements with the mobile node's home network
prefix information. prefix information.
skipping to change at page 27, line 47 skipping to change at page 28, line 39
o The interface identifier of the bi-directional tunnel between the o The interface identifier of the bi-directional tunnel between the
mobile node's local mobility anchor and the mobile access gateway. mobile node's local mobility anchor and 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
parameters that are required by the network entities for managing the parameters that are required by the network entities for managing the
mobile node's mobility service. These policy profiles are stored in mobile node's mobility service. These policy profiles are stored in
a local or a remote policy store, the mobile access gateway and the a local or a remote policy store. The mobile access gateway and the
local mobility anchor MUST be able to obtain a mobile node's policy local mobility anchor MUST be able to obtain a mobile node's policy
profile. The policy profile may also be handed over to a serving profile. The policy profile may also be handed over to a serving
mobile access gateway as part of a context transfer procedure during mobile access gateway as part of a context transfer procedure during
a handoff. The exact details on how this achieved is outside the a handoff. The exact details on how this achieved is outside the
scope of this document. However, this specification requires that a scope of this document. However, this specification requires that a
mobile access gateway serving a mobile node MUST have access to its mobile access gateway serving a mobile node MUST have access to its
policy profile. policy profile.
The following are the mandatory fields of the policy profile: The following are the mandatory fields of the policy profile:
skipping to change at page 28, line 37 skipping to change at page 29, line 28
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 Models
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 link,
the mobile node can generate one or more IPv6 addresses by combining the mobile node can generate one or more IPv6 addresses by combining
the network prefix advertised on the access link with an interface the network prefix advertised on the access link with an interface
skipping to change at page 30, line 30 skipping to change at page 31, line 26
configuration parameters consistent with its home link properties. configuration parameters consistent with its home link properties.
Typically, the mobile access gateway learns the mobile node's home Typically, the mobile access gateway learns the mobile node's home
network prefix information from the received Proxy Binding network prefix information from the received Proxy Binding
Acknowledgement message or it may be obtained from the mobile node's Acknowledgement message or it may be obtained from the mobile node's
policy profile. However, the mobile access gateway SHOULD send the policy profile. However, the mobile access gateway SHOULD send the
Router Advertisements advertising the mobile node's home network Router Advertisements advertising the mobile node's home network
prefix only after successfully completing the binding registration prefix only after successfully completing the binding registration
with the mobile node's local mobility anchor. with the mobile node's local mobility anchor.
When advertising the home network prefix in the Router Advertisement
messages, the mobile access gateway MAY set the prefix lifetime value
for the advertised prefix to any chosen value at its own discretion.
An implementation MAY choose to tie the prefix lifetime to the mobile
node's binding lifetime. The prefix lifetime can also be an optional
configuration parameter in the mobile node's policy profile.
6.8. Link-Local and Global Address Uniqueness 6.8. Link-Local and Global Address Uniqueness
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, it will continue to detect its mobile access gateway to the other, will continue to detect its home
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 to the interface state change will trigger the mobile node to perform
perform DAD operation on the link-local and global addresses. DAD operation on the link-local and global addresses. However, if
However, if the mobile node is DNAv6 enabled, as specified in [ID- the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may
DNAV6], it may not detect the link change due to DNAv6 optimizations not detect the link change due to DNAv6 optimizations and may not
and may not trigger the duplicate address detection (DAD) procedure trigger the duplicate address detection (DAD) procedure for
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 Further, if the mobile node uses an interface identifier that is not
based on EUI-64 identifier, such as specified in IPv6 Stateless based on EUI-64 identifier, such as specified in IPv6 Stateless
Autoconfiguration specification [RFC-2462], there is a possibility, Autoconfiguration specification [RFC-2462], there is a very low
with the odds of 1 to billion, of a link-local address collision possibility of a link-local address collision between the two
between the two neighbors on that access link. neighbors on that access link.
One of the workarounds for this issue is to set the DNAv6 For solving this problem, this specification allows the mobile access
configuration parameter, DNASameLinkDADFlag to TRUE and that will gateway to upload the mobile node's link-local address to the local
force the mobile node to redo DAD operation every time the interface mobility anchor using the Link-local Address option, exchanged in the
detects a handover, even when DNAv6 does not detect a link change. binding registration messages. The mobile access gateway can learn
the mobile node's link-local address, by snooping the DAD messages
sent by the mobile node for establishing the link-local address
uniqueness on the access link. Subsequently, at each handoff, the
mobile access gateway can obtain this address from the local mobility
anchor to ensure link-local address uniqueness and may change its own
link-local address, if it detects a collision.
However, this issues will not impact point-to-point links based on Alternatively, one of the workarounds for this issue is to set the
DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that
will force the mobile node to redo DAD operation every time the
interface detects a handover, even when DNAv6 does not detect a link
change.
However, this issue will not impact point-to-point links based on a
PPP session. Each time the mobile node moves and attaches to a new PPP session. Each time the mobile node moves and attaches to a new
mobile access gateway, either the PPP session [RFC-1661] is mobile access gateway, either the PPP session [RFC-1661] is
reestablished or the PPP session may be moved as part of context reestablished or the PPP session may be moved as part of context
transfer procedures between the old and the new mobile access transfer procedures between the old and the new mobile access
gateway. gateway.
When the mobile node tries to establish a PPP session with the mobile When the mobile node tries to establish a PPP session with the mobile
access gateway, the PPP goes through the Network layer Protocol phase access gateway, the PPP goes through the Network layer Protocol phase
and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered. Both and the IPv6 Control Protocol, IPV6CP [RFC-2472] gets triggered.
the PPP peers negotiate a unique identifier using Interface- Both the PPP peers negotiate a unique identifier using Interface-
Identifier option in IPV6CP and the negotiated identifier is used for Identifier option in IPV6CP and the negotiated identifier is used for
generating a unique link-local address on that link. Now, if the generating a unique link-local address on that link. Now, if the
mobile node moves to a new mobile access gateway, the PPP session 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 gets torn down with the old mobile access gateway and a new PPP
session gets established with the new mobile access gateway, and the session gets established with the new mobile access gateway, and the
mobile node obtains a new link-local address. So, even if the mobile 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- node is DNAv6 capable, the mobile node always configures a new link-
local address when ever it moves to a new link. local address when ever it moves to a new link.
If the PPP session state is moved to the new mobile access gateway, If the PPP session state is moved to the new mobile access gateway as
as part of context transfer procedures that are in place, there will part of context transfer procedures that are in place, there will not
not be any change to the interface identifiers of the two nodes on be any change to the interface identifiers of the two nodes on that
that point-to-point change. The whole link is moved to the new point-to-point change. The whole link is moved to the new mobile
mobile access gateway and there will not be any need for establishing access gateway and there will not be any need for establishing link-
link-local address uniqueness on that link. local address uniqueness on that link.
Alternatively, this specification allows the mobile access gateway to
upload the mobile node's link-local address to the local mobility
anchor using the Link-local Address option, exchanged in the binding
registration messages. The mobile access gateway can learn the
mobile node's link-local address, by snooping the DAD messages sent
by the mobile node for establishing the link-local address uniqueness
on the access link. Subsequently, at each handoff, the mobile access
gateway can obtain this address from the local mobility anchor and
can change its own link-local address, if it detects an address
collision.
This issue is not relevant to the mobile node's global address. The issue of address collision is not relevant to the mobile node's
Since, there is a unique home network prefix for each mobile node, global address. Since there is an unique home network prefix
the uniqueness for the mobile node's global address is assured on the assigned for each mobile node, the uniqueness for the mobile node's
access link. global 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
Initial Binding Registration: Mobile Node Attachment and Initial Binding Registration:
o After detecting a new mobile node on its access link, the mobile o 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 offered to the mobile node, it MUST management service needs to be offered to the mobile node, it MUST
send a Proxy Binding Update message to the local mobility anchor. send a Proxy Binding Update message to the local mobility anchor.
o The Proxy Binding Update message MUST have the NAI option [RFC- o The Proxy Binding Update message MUST have the NAI option [RFC-
4283], identifying the mobile node, the Home Network Prefix 4283], identifying the mobile node, the Home Network Prefix
option, either the Timestamp option or a valid sequence number and option, either the Timestamp option or a valid sequence number and
optionally the Link-local Address option. When Timestamp option optionally the Link-local Address option. When Timestamp option
is added to the message, the mobile access gateway MAY set the is added to the message, the mobile access gateway MAY set the
Sequence Number field to a value of a monotonically increasing Sequence Number field to a value of a monotonically increasing
counter and the local mobility anchor will ignore this field, but counter and the local mobility anchor will ignore this field, but
will return the same value in the Proxy Binding Acknowledgement will return the same value in the Proxy Binding Acknowledgement
skipping to change at page 32, line 49 skipping to change at page 33, line 51
o The mobile access gateway MUST observe the rules described in o The mobile access gateway MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Headers in the Section 9.2 [RFC-3775] when processing Mobility Headers in the
received Proxy Binding Acknowledgement message. received Proxy Binding Acknowledgement message.
o The message MUST be authenticated as described in Section 4.0. o The message MUST be authenticated as described in Section 4.0.
The SPI in the IPSec header [RFC-4306] of the received packet must The SPI in the IPSec header [RFC-4306] of the received packet must
be used for locating the security association needed for be used for locating the security association needed for
authenticating the message. authenticating the message.
o The mobile access gateway MUST apply the considerations specified o The mobile access gateway MUST apply the considerations specified
in Section 5.4, for processing the Sequence Number field and the in Section 5.4 for processing the Sequence Number field and the
Timestamp option, in the message. Timestamp option, in the message.
o The mobile access gateway MUST ignore any checks, specified in o The mobile access gateway MUST ignore any checks, specified in
[RFC-3775] related to the presence of Type 2 Routing header in the [RFC-3775] related to the presence of Type 2 Routing header in the
Proxy Binding Acknowledgement message. Proxy Binding Acknowledgement message.
o If the Timestamp option is present in the received Proxy Binding o If the Timestamp option is present in the received Proxy Binding
Acknowledgement message and with the Status field value set to any Acknowledgement message and with the Status field value set to any
value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the
mobile access gateway MAY use the timestamp value for matching the mobile access gateway MAY use the timestamp value for matching the
skipping to change at page 33, line 28 skipping to change at page 34, line 29
o If the received Proxy Binding Acknowledgement message has the o 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 that mobile node. It must also deny the mobility service to that
mobile node. mobile node.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp),
the mobile access gateway SHOULD try to register again only after the mobile access gateway SHOULD try to register again only after
it synchronized its clock to a common time source that is used by it has synchronized its clock to a common time source that is used
all the mobility entities in that domain for their clock by all the mobility entities in that domain for their clock
synchronization. The mobile access gateway SHOULD NOT synchronize synchronization. The mobile access gateway SHOULD NOT synchronize
its clock to the local mobility anchor's system clock, based on its clock to the local mobility anchor's system clock, based on
the timestamp present in the received message. the timestamp present in the received message.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX
(Not authorized for that prefix), the mobile access gateway SHOULD (Not authorized for that prefix), the mobile access gateway SHOULD
try to request for that prefix in the binding registration try to request for that prefix in the binding registration
request, only after it learned the validity of that prefix. request, only after it learned the validity of that prefix.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to any value greater than 128 (i.e., the Status field value set to any value greater than or equal to 128
binding is rejected), the mobile access gateway MUST NOT advertise (i.e., if the binding is rejected), the mobile access gateway MUST
the mobile node's home network prefix in the Router Advertisements NOT advertise the mobile node's home network prefix in the Router
sent on that access link and there by denying mobility service to Advertisements sent on that access link and there by denying
the mobile node. mobility service to the mobile node.
o If the received Proxy Binding Acknowledgement message has the o 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) and if
mobile access gateway MUST create Binding Update List entry for there is no existing Binding Update List entry for that mobile
the mobile node and must setup a tunnel to the mobile node's local node, the mobile access gateway MUST create a Binding Update List
mobility anchor, as explained in section 6.10. entry and must setup the routing state, as explained in section
6.10. But, if there is an existing Binding Update List entry for
that mobile node, the entry MUST be updated reflecting the
accepted binding registration.
o If the received Proxy Binding Acknowledgement message has the o 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 where matches its own link-local address on that access interface where
the mobile node is anchored, the mobile access gateway MUST change the mobile node is anchored, the mobile access gateway MUST change
its link-local address on that interface. its link-local address on that interface.
Binding Re-Registration: Extending Binding Lifetime:
o For extending the lifetime of a currently existing binding at the o For extending the lifetime of a currently registered mobile node
local mobility, the mobile access gateway MUST send a Proxy (i.e., if there exists a Binding Update List entry for that mobile
Binding Update message to the local mobility anchor. The prefix node), the mobile access gateway MUST send a Proxy Binding Update
value in the Home Network Prefix option present in the request message to the local mobility anchor. The prefix value in the
SHOULD be set to the currently registered home network prefix and Home Network Prefix option present in the request SHOULD be set to
the value in the Link-local Address option may be set to ALL_ZERO the currently registered home network prefix and the value in the
or to the link-local address of the mobile node. Link-local Address option may be set to ALL_ZERO or to the link-
local address of the mobile node.
Binding De-Registration: Mobile Node Detachment and Binding De-Registration:
o At any point, the mobile access gateway detects that the mobile o At any point, if the mobile access gateway detects that the mobile
node has moved away from its access link, it MUST send a Proxy node has moved away from its access link, it MUST send a Proxy
Binding Update message to the local mobility anchor with the Binding Update message to the local mobility anchor with the
lifetime value set to zero. lifetime value set to zero.
o Either upon receipt of a Proxy Binding Acknowledgement message o Either upon receipt of a Proxy Binding Acknowledgement message
from the local mobility anchor or after a certain timeout waiting from the local mobility anchor or after a certain timeout waiting
for the reply, the mobile access gateway MUST remove the binding for the reply, the mobile access gateway MUST remove the binding
entry for that mobile node from its Binding Update List and entry for that mobile node from its Binding Update List and
withdraw the mobile node's home network prefix as the hosted on- withdraw the mobile node's home network prefix as the hosted on-
link prefix on that access link. link prefix on that access link.
skipping to change at page 37, line 8 skipping to change at page 38, line 15
Proxy-CoA LMAA Proxy-CoA LMAA
| | | |
+--+ +---+ +---+ +--+ +--+ +---+ +---+ +--+
|MN|----------|MAG|======================|LMA|----------|CN| |MN|----------|MAG|======================|LMA|----------|CN|
+--+ +---+ +---+ +--+ +--+ +---+ +---+ +--+
IPv6 Tunnel 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 can be either an IPv6 or IPv4 network. However, this mobile access gateway can be either an IPv6 or IPv4 network.
specification only deals with the IPv6 transport and the companion However, this specification only deals with the IPv6 transport and
document [ID-IPV4-PMIP6] specifies the required extensions for the companion document [ID-IPV4-PMIP6] specifies the required
negotiating IPv4 transport and the corresponding encapsulation mode, extensions for negotiating IPv4 transport and the corresponding
for supporting this protocol operation. encapsulation mode for supporting this protocol operation.
6.10.2. Tunneling & Encapsulation Modes 6.10.2. Tunneling & Encapsulation Modes
The IPv6 address that a mobile node uses from its home network prefix The IPv6 address that a mobile node uses from its home network prefix
is topologically anchored at the local mobility anchor. For a mobile is topologically anchored at the local mobility anchor. For a mobile
node to use this address from an access network attached to a mobile node to use this address from an access network attached to a mobile
access gateway, proper tunneling techniques have to be in place. access gateway, proper tunneling techniques have to be in place.
Tunneling hides the network topology and allows the mobile node's Tunneling hides the network topology and allows the mobile node's
IPv6 datagrams to be encapsulated as a payload of another IPv6 packet IPv6 datagrams to be encapsulated as a payload of another IPv6 packet
and be routed between the local mobility anchor and the mobile access and to be routed between the local mobility anchor and the mobile
gateway. The Mobile IPv6 base specification [RFC-3775] defines the access gateway. The Mobile IPv6 base specification [RFC-3775]
use of IPv6-over-IPv6 tunneling, between the home agent and the defines the use of IPv6-over-IPv6 tunneling, between the home agent
mobile node and this specification extends the use of the same and the mobile node and this specification extends the use of the
tunneling mechanism between the local mobility anchor and the mobile same tunneling mechanism between the local mobility anchor and the
access gateway. mobile access gateway.
On most operating systems, tunnels are implemented as a virtual On most operating systems, tunnels are implemented as a virtual
point-to-point interface. The source and the destination address of point-to-point interface. The source and the destination address of
the two end points of this virtual interface along with the the two end points of this virtual interface along with the
encapsulation mode are specified for this virtual interface. Any encapsulation mode are specified for this virtual interface. Any
packet that is routed over this interface, get encapsulated with the packet that is routed over this interface gets encapsulated with the
outer header and the addresses as specified for that point to point outer header and the addresses as specified for that point to point
tunnel interface. For creating a point to point tunnel to any local tunnel interface. For creating a point to point tunnel to any local
mobility anchor, the mobile access gateway may implement a tunnel mobility anchor, the mobile access gateway may implement a tunnel
interface with the source address field set to its Proxy-CoA address interface with the source address field set to its Proxy-CoA address
and the destination address field set to the LMA address. and the destination address field set to the LMA address.
The following are the supported packet encapsulation modes that can The following are the supported packet encapsulation modes that can
be used by the mobile access gateway and the local mobility anchor be used by the mobile access gateway and the local mobility anchor
for routing mobile node's IPv6 datagrams. for routing mobile node's IPv6 datagrams.
skipping to change at page 39, line 8 skipping to change at page 40, line 17
| Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 | | Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Example - Tunnel Interface Table Example - Tunnel Interface Table
6.10.4. Local Routing 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
corresponding 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. However, this has an implication on the mobile node's anchor. However, this has an implication on the mobile node's
accounting and policy enforcement as the local mobility anchor is not accounting and policy enforcement as the local mobility anchor is not
in the path for that traffic and it will not be able to apply any in the path for that traffic and it will not be able to apply any
traffic policies or do any accounting for those flows. traffic policies or do any accounting for those flows.
This decision of path optimization SHOULD be based on the configured This decision of path optimization SHOULD be based on the policy
policy configured on the mobile access gateway, but enforced by the configured on the mobile access gateway, but enforced by the mobile
mobile node's local mobility anchor. The specific details on how node's local mobility anchor. The specific details on how this is
this is achieved is beyond of the scope of this document. achieved are beyond of the scope of this document.
6.10.5. Tunnel Management 6.10.5. Tunnel Management
All the considerations mentioned in Section 5.5.1, for the tunnel All the considerations mentioned in Section 5.5.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.6. 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,
it MUST silently drop the packet. For reporting an error in such it MUST silently drop the packet. For reporting an error in such
scenario, in the form of ICMP control message, the considerations a scenario, in the form of ICMP control message, the
from Generic Packet Tunneling specification [RFC-2473] must be considerations from Generic Packet Tunneling specification [RFC-
applied. 2473] must be applied.
o On receiving a packet from a corresponding node that is locally o On receiving a packet from a correspondent node that is locally
connected, to the mobile node that is on the access link, the connected and which is destined to a mobile node that is on
mobile access gateway MUST check the configuration variable, another locally connected access link, the mobile access gateway
EnableMAGLocalRouting, to ensure the mobile access gateway is MUST check the configuration variable, EnableMAGLocalRouting, to
allowed to route the packet directly to the mobile node. If the ensure the mobile access gateway is allowed to route the packet
mobile access gateway is not allowed to route the packet directly, directly to the mobile node. If the mobile access gateway is not
it MUST route the packet through the bi-directional tunnel allowed to route the packet directly, it MUST route the packet
established between itself and the mobile node's local mobility through the bi-directional tunnel established between itself and
anchor. Otherwise, it can route the packet directly to the mobile the mobile node's local mobility anchor. Otherwise, it can route
node. the packet directly to the mobile node.
Forwarding Packets Sent by the Mobile Node: Forwarding Packets Sent by the Mobile Node:
o On receiving a packet from a mobile node connected to its access o On receiving a packet from a mobile node connected to its access
link, the mobile access gateway MUST ensure that there is an link, the mobile access gateway MUST ensure that there is an
established binding for that mobile node with its local mobility established binding for that mobile node with its local mobility
anchor before forwarding the packet directly to the destination or anchor before forwarding the packet directly to the destination or
before tunneling the packet to the mobile node's local mobility before tunneling the packet to the mobile node's local mobility
anchor. anchor.
skipping to change at page 40, line 39 skipping to change at page 42, line 4
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. However, when using
IPv4 transport, the format of the tunneled packet is as described IPv4 transport, the format of the tunneled packet is as described
in [ID-IPV4-PMIP6]. 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 12: Tunneled Packets from MAG to LMA Figure 12: Tunneled Packets from MAG to LMA
6.11. Interaction with DHCP Relay Agent 6.11. Supporting DHCPv6 based Address Configuration on the Access Link
If Stateful Address Configuration using DHCP is supported on the link This non-normative section explains how Stateful Address
where the mobile node is attached, the DHCP relay agent [RFC-3315] Configuration using DHCPv6 can be enabled on the access link attached
needs to be configured on that access link. to a mobile access gateway and how a mobile node attached to that
link can obtain an address from its home network prefix using DHCPv6.
When the mobile node sends a DHCPv6 Request message, the DHCP relay o The DHCPv6 relay agent [RFC-3315] service needs to be enabled on
agent function on the access link will set the link-address field in each of the access links in the Proxy Mobile IPv6 domain.
the DHCPv6 message to the mobile node's home network prefix, so as to Further, as specified in Section 20 [RFC-3315], the relay agent
provide a prefix hint to the DHCP Server for the address pool should be configured to use a list of destination addresses, which
selection. MAY include unicast addresses, the All_DHCP_Servers multicast
address, or other addresses selected by the network administrator.
o The DHCPv6 server in the Proxy Mobile IPv6 domain can be
configured with a list of address pools (P1, P2, ..., Pn). Each
one of these prefix pools corresponds to a home network prefix
that a local mobility anchor allocates to a mobile node in that
domain. However, the DHCPv6 server will not know the relation
between a given address pool and a mobile node to which the
corresponding prefix is allocated. It just views these pools as
prefixes hosted on different links in that domain.
o When a mobile node sends a DHCPv6 request message, the DHCP relay
agent function on the access link will set the link-address field
in the DHCP message to the mobile node's home network prefix, so
as to provide a prefix hint to the DHCP Server for the address
pool selection. The DHCP server on receiving the request from the
mobile node, will allocate an address from the prefix pool present
in the link-address field of the request.
o Once the mobile node obtains an address and moves to a different
link, the DHCP relay agent on the new link will set the prefix
hint in the DHCP messages to the mobile node's home network
prefix. The DHCP server will identify the client from the Client
Identifier option present in the request and will allocate the
same address as before.
o The DHCP based address configuration is not recommended for
deployments where the local mobility anchor and the mobile access
gateways are located in different administrative domains. For
this configuration to work, all the mobile access gateways in the
Proxy Mobile IPv6 domain should be able to ensure that the DHCP
requests from a given mobile node anchored on any of the access
links in that domain, will always be handled by the same DHCP
server.
o The DHCP server should be configured to offer low address lease
times. A lease time that is too large prevents the DHCP server
from reclaiming the address even after the local mobility anchor
deletes the mobile node's binding cache entry.
6.12. Home Network Prefix Renumbering 6.12. Home Network Prefix Renumbering
If the mobile node's home network prefix gets renumbered or becomes If the mobile node's home network prefix gets renumbered or becomes
invalid during the middle of a mobility session, the mobile access invalid during the middle of a mobility session, the mobile access
gateway MUST withdraw the prefix by sending a Router Advertisement on gateway MUST withdraw the prefix by sending a Router Advertisement on
the access link with zero prefix lifetime for the mobile node's home the access link with zero prefix lifetime for the mobile node's home
network prefix. Also, the local mobility anchor and the mobile network prefix. Also, the local mobility anchor and the mobile
access gateway MUST delete the routing state for that prefix. access gateway MUST delete the routing state for that prefix.
However, the specific details on how the local mobility anchor However, the specific details on how the local mobility anchor
notifies the mobile access gateway about the mobile node's home notifies the mobile access gateway about the mobile node's home
network prefix renumbering is outside the scope of this document. network prefix renumbering are outside the scope of this document.
6.13. Mobile Node Detachment Detection and Resource Cleanup 6.13. Mobile Node Detachment Detection and Resource Cleanup
Before sending a Proxy Binding Update message to the local mobility Before sending a Proxy Binding Update message to the local mobility
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.
skipping to change at page 42, line 38 skipping to change at page 44, line 38
its home link, as explained in various sections of this its home link, as explained in various sections of this
specification. specification.
If the mobile node is not entitled for the network-based mobility If the mobile node is not entitled for the network-based mobility
management service, as determined from the policy considerations, the management service, as determined from the policy considerations, the
mobile access gateway MAY choose to offer regular IPv6 access to the mobile access gateway MAY choose to offer regular IPv6 access to the
mobile node and in such scenario the normal IPv6 considerations mobile node and in such scenario the normal IPv6 considerations
apply. If IPv6 access is enabled, the mobile node SHOULD be able to apply. If IPv6 access is enabled, the mobile node SHOULD be able to
obtain an IPv6 address using normal IPv6 address configuration obtain an IPv6 address using normal IPv6 address configuration
procedures. The obtained address must be from a local visitor procedures. The obtained address must be from a local visitor
network prefix. This essentially ensures, the mobile access gateway network prefix. This essentially ensures that the mobile access
functions as a normal access router to a mobile node attached to its gateway functions as a normal access router to a mobile node attached
access link and with out impacting its host-based mobility protocol to its access link and with out impacting its host-based mobility
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 Once 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
skipping to change at page 45, line 26 skipping to change at page 47, line 26
access gateway may withdraw the previous default-router entry, by access gateway may withdraw the previous default-router entry, by
sending a Router Advertisement using the link-local address that of sending a Router Advertisement using the link-local address that of
the previous mobile access gateway and with the Router Lifetime field the previous mobile access gateway and with the Router Lifetime field
set to value 0, then this will force the flush of the Previous set to value 0, then this will force the flush of the Previous
Default-Router entry from the mobile node's cache. This certainly Default-Router entry from the mobile node's cache. This certainly
requires context-transfer mechanisms in place for notifying the link- requires context-transfer mechanisms in place for notifying the link-
local address of the default-router on the previous link to the local address of the default-router on the previous link to the
mobile access gateway on the new link. mobile access gateway on the new link.
There are other solutions possible for this problem, including the There are other solutions possible for this problem, including the
assignment of a fixed link-local address for all the mobile access assignment of a fixed link-local address for all the mobility
gateways in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is 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 not deployed. In such scenario, the mobile node is not required to
update the default-router entry. However, this is an implementation update the default-router entry. However, this is an implementation
choice and has no bearing on the protocol interoperability. choice and has no bearing on the protocol interoperability.
Implementations are free to adopt the best approach that suits their Implementations are free to adopt the best approach that suits their
target deployments. 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.
skipping to change at page 52, line 6 skipping to change at page 54, line 6
Figure 17: Timestamp Option Figure 17: Timestamp Option
8.6. Status Values 8.6. 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
was processed successfully by the local mobility anchor. Status request was accepted by the local mobility anchor. Status values
values greater than 128 indicate that the Proxy Binding Update was greater than 128 indicate that the Proxy Binding Update was rejected
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. updates.
skipping to change at page 53, line 15 skipping to change at page 55, line 15
9. Protocol Configuration Variables 9. Protocol Configuration Variables
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 corresponding 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 corresponding 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.
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
skipping to change at page 54, line 40 skipping to change at page 56, line 40
Binding Update and Proxy Binding Acknowledgement, exchanged between Binding Update and Proxy Binding Acknowledgement, exchanged between
the mobile access gateway and the local mobility anchor to be the mobile access gateway and the local mobility anchor to be
protected using IPsec, using the established security association protected using IPsec, using the established security association
between them. This essentially eliminates the threats related to the between them. This essentially eliminates the threats related to the
impersonation of the mobile access gateway or the local mobility impersonation of the mobile access gateway or the local mobility
anchor. anchor.
This specification allows a mobile access gateway to send binding This specification allows a mobile access gateway to send binding
registration messages on behalf of a mobile node. If proper registration messages on behalf of a mobile node. If proper
authorization checks are not in place, a malicious node may be able authorization checks are not in place, a malicious node may be able
to hijack a mobile node's session or may do a denial-of-service to hijack a mobile node's session or may carry out a denial-of-
attacks. To prevent this attack, this specification requires the service attack. To prevent this attack, this specification requires
local mobility anchor to allow only authorized mobile access gateways the local mobility anchor to allow only authorized mobile access
to send binding registration messages on behalf of a mobile node. gateways to send binding registration messages on behalf of a mobile
node.
To eliminate the threats on the interface between the mobile access To eliminate the threats on the interface between the mobile access
gateway and the mobile node, this specification requires an gateway and the mobile node, this specification requires an
established trust between the mobile access gateway and the mobile established trust between the mobile access gateway and the mobile
node and to authenticate and authorize the mobile node before it is node and to authenticate and authorize the mobile node before it is
allowed to access the network. allowed to access the network. Further, the established
authentication mechanisms enabled on that access link will ensure
that there is a secure binding between the mobile node's identity and
its link-layer address. The mobile access gateway will definitively
identify the mobile node from the packets that it receives on that
access link.
To eliminate the threats related to a compromised mobile access To eliminate the threats related to a compromised mobile access
gateway, this specification recommends that the local mobility anchor gateway, this specification recommends that the local mobility anchor
before accepting a Proxy Binding Update message for a given mobile before accepting a Proxy Binding Update message for a given mobile
node, should ensure the mobile node is definitively attached to the node, should ensure the mobile node is definitively attached to the
mobile access gateway that sent the binding registration request. mobile access gateway that sent the binding registration request.
The issues related to a compromised mobile access gateway in the The issues related to a compromised mobile access gateway in the
scenario where the local mobility anchor and the mobile access scenario where the local mobility anchor and the mobile access
gateway in different domains, is outside the scope of this document. gateway in different domains, is outside the scope of this document.
 End of changes. 92 change blocks. 
275 lines changed or deleted 369 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/