draft-ietf-netlmm-proxymip6-03.txt   draft-ietf-netlmm-proxymip6-04.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 8, 2008 V. Devarapalli Expires: March 14, 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 5, 2007 September 11, 2007
Proxy Mobile IPv6 Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-03.txt draft-ietf-netlmm-proxymip6-04.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 8, 2008. This Internet-Draft will expire on March 14, 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . 11 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 13
4.1. Peer Authorization Database Entries . . . . . . . . . . . 12 4.1. Peer Authorization Database Entries . . . . . . . . . . . 13
4.2. Security Policy Database Entries . . . . . . . . . . . . . 13 4.2. Security Policy Database Entries . . . . . . . . . . . . . 14
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 13 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15
5.1. Extensions to Binding Cache Entry Data Structure . . . . . 14 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 15
5.2. Supported Home Network Prefix Models . . . . . . . . . . . 14 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 16
5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 15 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 16
5.4. Timestamp Option for Message Ordering . . . . . . . . . . 19 5.4. Timestamp Option for Message Ordering . . . . . . . . . . 21
5.5. Routing Considerations . . . . . . . . . . . . . . . . . . 21 5.5. Routing Considerations . . . . . . . . . . . . . . . . . . 23
5.5.1. Bi-Directional Tunnel Management . . . . . . . . . . . 21 5.5.1. Bi-Directional Tunnel Management . . . . . . . . . . . 23
5.5.2. Forwarding Considerations . . . . . . . . . . . . . . 22 5.5.2. Forwarding Considerations . . . . . . . . . . . . . . 23
5.6. Local Mobility Anchor Address Discovery . . . . . . . . . 23 5.6. Local Mobility Anchor Address Discovery . . . . . . . . . 24
5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 23 5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 25
5.8. Route Optimizations Considerations . . . . . . . . . . . . 24 5.8. Route Optimizations Considerations . . . . . . . . . . . . 25
6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 24 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 25
6.1. Extensions to Binding Update List Entry Data Structure . . 25 6.1. Extensions to Binding Update List Entry Data Structure . . 26
6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 26 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 27
6.3. Supported Access Link Types . . . . . . . . . . . . . . . 26 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 28
6.4. Supported Address Configuration Models . . . . . . . . . . 26 6.4. Supported Address Configuration Models . . . . . . . . . . 28
6.5. Access Authentication & Mobile Node Identification . . . . 27 6.5. Access Authentication & Mobile Node Identification . . . . 28
6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 27 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 29
6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 28 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 29
6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 28 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 30
6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 30 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 31
6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 33 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 31
6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 33 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 34
6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 33 6.9.3. Retransmissions and Rate Limiting . . . . . . . . . . 35
6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 34 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 35
6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 35 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 36
6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 36 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 36
6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 36 6.10.3. Routing State . . . . . . . . . . . . . . . . . . . . 37
6.11. Interaction with DHCP Relay Agent . . . . . . . . . . . . 36 6.10.4. Local Routing . . . . . . . . . . . . . . . . . . . . 38
6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 37 6.10.5. Tunnel Management . . . . . . . . . . . . . . . . . . 38
6.13. Mobile Node Detachment Detection and Resource Cleanup . . 37 6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 38
6.14. Allowing network access to other IPv6 nodes . . . . . . . 38 6.11. Interaction with DHCP Relay Agent . . . . . . . . . . . . 40
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 38 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 40
7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 39 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 40
7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 40 6.14. Allowing network access to other IPv6 nodes . . . . . . . 41
7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 40 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 42
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 41 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 42
8.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . . 42 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 43
8.2. Proxy Binding Acknowledgement . . . . . . . . . . . . . . 43 7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 43
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 43 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 44
8.4. Link-local Address Option . . . . . . . . . . . . . . . . 44 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 45
8.5. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 45 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 46
8.6. Status Values . . . . . . . . . . . . . . . . . . . . . . 46 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 46
9. Protocol Configuration Variables . . . . . . . . . . . . . . . 47 8.4. Link-local Address Option . . . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 8.5. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 8.6. Status Values . . . . . . . . . . . . . . . . . . . . . . 49
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
13.1. Normative References . . . . . . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
13.2. Informative References . . . . . . . . . . . . . . . . . . 51 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Proxy Mobile IPv6 interactions with AAA Appendix A. Proxy Mobile IPv6 interactions with AAA
Infrastructure . . . . . . . . . . . . . . . . . . . 52 Infrastructure . . . . . . . . . . . . . . . . . . . 55
Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 52 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . . . . . 57
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 10 skipping to change at page 5, line 10
The problem statement and the need for a network based mobility The problem statement and the need for a network based mobility
protocol solution has been documented in [RFC-4830]. Proxy Mobile protocol solution has been documented in [RFC-4830]. Proxy Mobile
IPv6 is a solution that addresses these issues and requirements. IPv6 is a solution that addresses these issues and requirements.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions used in this document 2.1. Conventions used in this document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [RFC-2119].
2.2. Terminology 2.2. Terminology
All the general mobility related terms used in this document are to All the general mobility related terms used in this document are to
be interpreted as defined in the Mobile IPv6 base specification [RFC- be interpreted as defined in the Mobile IPv6 base specification [RFC-
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
skipping to change at page 6, line 6 skipping to change at page 6, line 6
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 required
capabilities for supporting Proxy Mobile IPv6 protocol as defined capabilities for supporting Proxy Mobile IPv6 protocol as defined
in this specification. in this specification.
Mobile Access Gateway (MAG) Mobile Access Gateway (MAG)
Mobile Access Gateway is a function that manages the mobility Mobile Access Gateway is a function that manages the mobility
related signaling for a mobile node that is attached to its access related signaling for a mobile node that is attached to its access
link. It is responsible for tracking the mobile node's attachment link. It is responsible for tracking the mobile node's movements
to the link and for signaling the mobile node's local mobility on the access link and for signaling the mobile node's local
anchor. mobility anchor.
Mobile Node (MN) Mobile Node (MN)
Through out this document, the term mobile node is used to refer Through out this document, the term mobile node is used to refer
to an IP node whose mobility is managed by the network. The to an IP host whose mobility is managed by the network. The
mobile node may be operating in IPv6 mode, IPv4 mode or in IPv4/ mobile node may be operating in IPv6 mode, IPv4 mode or in IPv4/
IPv6 dual mode. The mobile node is not required to participate in IPv6 dual mode. The mobile node is not required to participate in
any mobility related signaling for achieving mobility for an IP any mobility related signaling for achieving mobility for an IP
address that is obtained in that local domain. This document address that is obtained in that Proxy Mobile IPv6 domain. This
further uses explicit text when referring to a mobile node that is document further uses explicit text when referring to a mobile
involved in mobility related signaling as per Mobile IPv6 node that is involved in mobility related signaling as per Mobile
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 tunnel mobility anchor and is the transport endpoint of the bi-
between the local mobility anchor and the mobile access gateway. directional tunnel established between the local mobility anchor
This is the address to where the mobile access gateway sends the and the mobile access gateway. This is the address to where the
Proxy Binding Update messages. When supporting IPv4 traversal, mobile access gateway sends the Proxy Binding Update messages.
i.e. when the network between the local mobility anchor and the When supporting IPv4 traversal, i.e., when the network between the
mobile access gateway is an IPv4 network, this address will be an local mobility anchor and the mobile access gateway is an IPv4
IPv4 address and will be referred to as IPv4-LMAA, as specified in network, this address will be an IPv4 address and will be referred
[ID-IPV4-PMIP6]. to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6].
Proxy Care-of Address (Proxy-CoA) Proxy Care-of Address (Proxy-CoA)
Proxy-CoA is the address configured on the interface of the mobile Proxy-CoA is the address configured on the interface of the mobile
access gateway and is the transport endpoint of the tunnel between access gateway and is the transport endpoint of the tunnel between
the local mobility anchor and the mobile access gateway. The the local mobility anchor and the mobile access gateway. The
local mobility anchor views this address as the Care-of Address of local mobility anchor views this address as the Care-of Address of
the mobile node and registers it in the Binding Cache entry for the mobile node and registers it in the Binding Cache entry for
that mobile node. When the transport network between the mobile that mobile node. When the transport network between the mobile
access gateway and the local mobility anchor is an IPv4 network access gateway and the local mobility anchor is an IPv4 network
skipping to change at page 7, line 13 skipping to change at page 7, line 13
Mobile Node's Home Address (MN-HoA) Mobile Node's Home Address (MN-HoA)
MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6 MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6
domain. It is an address from its home network prefix obtained by domain. It is an address from its home network prefix obtained by
a mobile node in a Proxy Mobile IPv6 domain. The mobile node can a mobile node in a Proxy Mobile IPv6 domain. The mobile node can
continue to use this address as long as it is attached to the continue to use this address as long as it is attached to the
network that is in the scope of that Proxy Mobile IPv6 domain. network that is in the scope of that Proxy Mobile IPv6 domain.
Mobile Node's Home Network Prefix (MN-HNP) Mobile Node's Home Network Prefix (MN-HNP)
This is the on-link IPv6 prefix that is always present in the This is the on-link IPv6 prefix that is always present in the
Router Advertisements that the mobile node receives on any of the Router Advertisements that the mobile node receives when it is
access links in that Proxy Mobile IPv6 domain. This home network attached to any of the access links in that Proxy Mobile IPv6
prefix is topologically anchored at the mobile node's local domain. This home network prefix is topologically anchored at the
mobility anchor. The mobile node configures its interface with an mobile node's local mobility anchor. The mobile node configures
address from this prefix. its interface with an address from this prefix.
Mobile Node's Home Link Mobile Node's Home Link
This is the link on which the mobile node obtained its initial This is the link on which the mobile node obtained its initial
address configuration after it moved into that Proxy Mobile IPv6 address configuration after it moved into that Proxy Mobile IPv6
domain. This is the link that conceptually follows the mobile domain. This is the link that conceptually follows the mobile
node. The network will ensure the mobile node always sees this node. The network will ensure the mobile node always sees this
link with respect to the layer-3 network configuration, on any link with respect to the layer-3 network configuration, on any
access link that it attaches to in that proxy mobile IPv6 domain. access link that it attaches to in that Proxy Mobile IPv6 domain.
Mobile Node Identifier (MN-Identifier) Mobile Node Identifier (MN-Identifier)
The identity of a mobile node in the Proxy Mobile IPv6 domain. The identity of a mobile node in the Proxy Mobile IPv6 domain.
This is the stable identifier of a mobile node that the mobility This is the stable identifier of a mobile node that the mobility
entities in a Proxy Mobile IPv6 domain can always acquire and entities in a Proxy Mobile IPv6 domain can always acquire and
using which can predictably identify a mobile node. This is using which a mobile node can predictably be identified. This is
typically an identifier such as Mobile Node NAI [RFC-4282]. typically an identifier such as Mobile Node NAI [RFC-4282].
Proxy Binding Update (PBU) Proxy Binding Update (PBU)
A request message sent by a mobile access gateway to a mobile A binding registration request message sent by a mobile access
node's local mobility anchor for establishing a binding between gateway to a mobile node's local mobility anchor for establishing
the mobile node's MN-HNP and the Proxy-CoA. a binding between the mobile node's MN-HNP and the Proxy-CoA.
Proxy Binding Acknowledgement (PBA) Proxy Binding Acknowledgement (PBA)
A response message sent by a local mobility anchor in response to A binding registration reply message sent by a local mobility
a Proxy Binding Update message that it received from a mobile anchor in response to a Proxy Binding Update request message that
access gateway. it received from a mobile access gateway.
3. Proxy Mobile IPv6 Protocol Overview 3. Proxy Mobile IPv6 Protocol Overview
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]. [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.
skipping to change at page 8, line 46 skipping to change at page 8, line 46
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ ) ( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ ) ( \\ Network // \\ )
+------\\--------//------------\\-+ +------\\--------//------------\\-+
\\ // \\ \\ // \\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
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
skipping to change at page 10, line 36 skipping to change at page 10, line 36
|--- Rtr Sol --------->| | |--- Rtr Sol --------->| |
| | | | | |
|<------- Rtr Adv -----| | |<------- Rtr Adv -----| |
| | | | | |
IP Address | | IP Address | |
Configuration | | Configuration | |
| | | | | |
Figure 2: Mobile Node Attachment - Signaling Call Flow Figure 2: Mobile Node Attachment - Signaling Call Flow
Figure 2 shows the signaling call flow, when the mobile node enters
the Proxy Mobile IPv6 domain.
For updating the local mobility anchor about the current location of For updating the local mobility anchor about the current location of
the mobile node, the mobile access gateway sends a Proxy Binding the mobile node, the mobile access gateway sends a Proxy Binding
Update message to the mobile node's local mobility anchor. Upon Update message to the mobile node's local mobility anchor. Upon
accepting this Proxy Binding Update message, the local mobility accepting this Proxy Binding Update message, the local mobility
anchor sends a Proxy Binding Acknowledgement message including the anchor sends a Proxy Binding Acknowledgement message including the
mobile node's home network prefix. It also creates the binding cache mobile node's home network prefix. It also creates the Binding Cache
entry and establishes a bi-directional tunnel to the mobile access entry and establishes a bi-directional tunnel to the mobile access
gateway. gateway.
The mobile access gateway on receiving the Proxy Binding The mobile access gateway on receiving the Proxy Binding
Acknowledgement message sets up a bi-directional tunnel to the local Acknowledgement message sets up a bi-directional tunnel to the local
mobility anchor and sets up the data path for the mobile node's mobility anchor and sets up the data path for the mobile node's
traffic. At this point the mobile access gateway will have all the traffic. At this point the mobile access gateway will have all the
required information for emulating the mobile node's home link. It required information for emulating the mobile node's home link. It
sends Router Advertisement messages to the mobile node on the access sends Router Advertisement messages to the mobile node on the access
link advertising the mobile node's home network prefix as the hosted link advertising the mobile node's home network prefix as the hosted
skipping to change at page 11, line 33 skipping to change at page 11, line 37
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 corresponding 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 and any packet that the mobile node sends to any access link. However, in some configurations where the functionality
corresponding node is received by the mobile access gateway and it of the mobile access gateway is split across different nodes, the
forwards the packet to its local mobility anchor through the bi- node sending the Router Advertisements will be the default-router for
directional tunnel. The local mobility anchor on the other end of the mobile node. Any packet that the mobile node sends to any
the tunnel, after receiving the packet removes the outer header and corresponding node will be received by the mobile access gateway and
routes the packet to the destination. will be sent to its local mobility anchor through the bi-directional
tunnel. The local mobility anchor on the other end of the tunnel,
after receiving the packet removes the outer header and routes the
packet to the destination.
+-----+ +-----+ +-----+ +-----+
| MN | |p-MAG| | LMA | |n-MAG|
+-----+ +-----+ +-----+ +-----+
| | | |
| |==Bi-Dir Tunnel=| |
MN Detached | | |
| MN Detached Event | |
| | | |
| |-- PBU -------->| |
| | | |
| | Accept PBU |
| | (Start BCE delete timer) |
| | | |
| |<-------- PBA --| |
| | | |
MN Attached | | |
| | | MN Attached Event
| | | (Acquire MN-Id and Profile)
....
Registration steps as in fig 2.
....
| | |==Bi-Dir Tunnel=|
|--- Rtr Sol ------------------------------------->|
| | | |
|<------------------------------------ Rtr Adv ----|
| | | |
MN retains HoA/HNP
| | | |
Figure 3: Mobile Node Handoff - Signaling Call Flow
Figure 3 shows the signaling call flow for the mobile node's handoff
scenario.
After obtaining the initial address configuration in the Proxy Mobile
IPv6 domain, if the mobile node changes its point of attachment, the
mobile access gateway on the new access link, will signal the local
mobility anchor for updating the binding and routing state. The
mobile node will continue to receive the Router Advertisements
containing its home network prefix, making it believe its still on
the same link and can use the same address configuration on the new
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 IPsec [RFC-4301] and local mobility anchor MUST be protected using end-to-end security
using the established security association between them. The association(s) offering integrity and data origin authentication. A
security association of the specific mobile node for which the security association with the mobile node for which the signaling
signaling message is initiated is not required for protecting these message is issued is not required for protection of these messages.
messages.
The mobile access gateway and the local mobility anchor MUST
implement IPsec for protecting the Proxy Mobile IPv6 signaling
messages [RFC-4301]. IPsec is the default security mechanism for
securing the signaling messages. However in certain deployments of
this protocol, other security mechanisms MAY be applied and the
signaling messages must be protected using the semantics provided by
that respective mechanism.
IPsec ESP [RFC-4303] in transport mode with mandatory integrity IPsec ESP [RFC-4303] in transport mode with mandatory integrity
protection SHOULD be used for protecting the signaling messages. protection SHOULD be used for protecting the signaling messages.
Confidentiality protection of these messages is not required. Confidentiality protection of these messages is not required.
IKEv2 [RFC-4306] SHOULD be used to setup security associations IKEv2 [RFC-4306] SHOULD be used to setup security associations
between the mobile access gateway and the local mobility anchor to between the mobile access gateway and the local mobility anchor to
protect the Proxy Binding Update and Proxy Binding Acknowledgement protect the Proxy Binding Update and Proxy Binding Acknowledgement
messages. The mobile access gateway and the local mobility anchor messages. The mobile access gateway and the local mobility anchor
can use any of the authentication mechanisms, as specified in IKEv2, can use any of the authentication mechanisms, as specified in IKEv2,
skipping to change at page 14, line 7 skipping to change at page 15, line 19
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 The 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.
o A flag indicating whether or not this Binding Cache entry is o A flag indicating whether or not this Binding Cache entry is
created due to a proxy registration. This flag is enabled for created due to a proxy registration. This flag is enabled for
Binding Cache entries that are proxy registrations and is turned Binding Cache entries that are proxy registrations and is turned
off for all other entries that are created due to the off for all other entries that are created due to the
registrations directly sent by the mobile node. registrations directly sent by the mobile node.
skipping to change at page 15, line 9 skipping to change at page 16, line 23
an unique home network prefix assigned to each mobile node and no an unique home network prefix assigned to each mobile node and no
other node shares an address from that prefix. other node shares an address from that prefix.
The mobile node's home network prefix is always hosted on the access The mobile node's home network prefix is always hosted on the access
link where the mobile node is anchored. Conceptually, the entire link where the mobile node is anchored. Conceptually, the entire
home network prefix follows the mobile node as it moves within the home network prefix follows the mobile node as it moves within the
Proxy Mobile IPv6 domain. The local mobility anchor is not required Proxy Mobile IPv6 domain. The local mobility anchor is not required
to perform any proxy ND operations [RFC-2461] for defending the to perform any proxy ND operations [RFC-2461] for defending the
mobile node's home address on the home link. However, from the mobile node's home address on the home link. However, from the
routing perspective, the home network prefix is topologically routing perspective, the home network prefix is topologically
anchored on the local mobility anchor and is the gateway to that home anchored on the local mobility anchor.
network prefix.
5.3. Signaling Considerations 5.3. Signaling Considerations
Processing Binding Registrations Processing Binding Registrations
Upon receiving a Proxy Binding Update request from a mobile access Upon receiving a Proxy Binding Update request from a mobile access
gateway on behalf of a mobile node, the local mobility anchor MUST gateway on behalf of a mobile node, the local mobility anchor MUST
process the request as defined in Section 10.3 [RFC-3775], with one process the request as defined in Section 10.3 [RFC-3775], with one
exception that this request is a proxy binding registration request exception that this request is a proxy binding registration request
and hence the following additional considerations must be applied. and hence the following additional considerations must be applied.
o The local mobility anchor MUST observe the rules described in o The local mobility anchor MUST observe the rules described in
Section 9.2 [RFC-3775] when processing Mobility Headers in the Section 9.2 [RFC-3775] when processing Mobility Headers in the
received Proxy Binding Update request. received Proxy Binding Update request.
o The local mobility anchor MUST identify the mobile node from the o The local mobility anchor MUST identify the mobile node from the
identifier present in the NAI option of the Proxy Binding Update identifier present in the NAI option [RFC-4283] of the Proxy
request. If the NAI option is not present in the Proxy Binding Binding Update request. If the NAI option is not present in the
Update request, the local mobility anchor MUST reject the request Proxy Binding Update request, the local mobility anchor MUST
and send a Proxy Binding Acknowledgement message with Status field reject the request and send a Proxy Binding Acknowledgement
set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node message with Status field set to MISSING_MN_IDENTIFIER_OPTION
identifier). (Missing mobile node identifier).
o If the local mobility anchor cannot identify the mobile node, from o If the local mobility anchor cannot identify the mobile node, from
the NAI option present in the request, it MUST reject the Proxy the NAI option [RFC-4283] present in the request, it MUST reject
Binding Update request and send a Proxy Binding Acknowledgement the Proxy Binding Update request and send a Proxy Binding
message with Status field set to 133 (Not home agent for this Acknowledgement message with Status field set to 133 (Not home
mobile node). agent for this mobile node).
o If the local mobility anchor determines that the mobile node is o If the local mobility anchor determines that the mobile node is
not authorized for network-based mobility management service, it not authorized for network-based mobility management service, it
MUST reject the request and send a Proxy Binding Acknowledgement MUST reject the request and send a Proxy Binding Acknowledgement
message with Status field set to PROXY_REG_NOT_ENABLED (Proxy message with Status field set to PROXY_REG_NOT_ENABLED (Proxy
Registration not enabled). Registration not enabled).
o The local mobility anchor MUST ignore the check, specified in o The local mobility anchor MUST ignore the check, specified in
Section 10.3.1 [RFC-3775], related to the presence of Home Address Section 10.3.1 [RFC-3775], related to the presence of Home Address
destination option in the Proxy Binding Update request. destination option in the Proxy Binding Update request.
o The local mobility anchor MUST authenticate the Proxy Binding o The local mobility anchor MUST authenticate the Proxy Binding
Update request as described in Section 4.0. It MUST use the SPI Update request as described in Section 4.0. It MUST use the SPI
in the IPSec header [RFC-4306] of the received packet for locating in the IPSec header [RFC-4306] of the received packet for locating
the security association needed for processing the Proxy Binding the security association needed for authenticating the Proxy
Update request. Binding Update request.
o The local mobility anchor MUST apply the required policy checks, o The local mobility anchor MUST apply the required policy checks,
as explained in Section 4.0, to verify the sender is a trusted as explained in Section 4.0, to verify the sender is a trusted
mobile access gateway, authorized to send proxy binding mobile access gateway, authorized to send proxy binding
registration requests on behalf of this mobile node. registration requests on behalf of this mobile node.
o If the local mobility anchor determines that the requesting node o If the local mobility anchor determines that the requesting node
is not authorized to send proxy binding registration requests, it is not authorized to send proxy binding registration requests, it
MUST reject the Proxy Binding Update request and send a Proxy MUST reject the Proxy Binding Update request and send a Proxy
Binding Acknowledgement message with Status field set to Binding Acknowledgement message with Status field set to
skipping to change at page 16, line 34 skipping to change at page 17, line 45
Binding Update request, the local mobility anchor MUST reject the Binding Update request, the local mobility anchor MUST reject the
Proxy Binding Update request and send a Proxy Binding Proxy Binding Update request and send a Proxy Binding
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 present in the Proxy Binding Update request for performing option [RFC-4283] present in the Proxy Binding Update request for
the Binding Cache entry existence test. If the entry does not performing the Binding Cache entry existence test. If the entry
exist, the local mobility MUST consider this request as an initial does not exist, the local mobility MUST consider this request as
binding registration request. an initial binding registration request.
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 with 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
MUST ensure the allocated prefix is not in use by any other mobile MUST ensure the allocated prefix is not in use by any other mobile
node. node.
o If the local mobility anchor is unable to allocate a home network o If the local mobility anchor is unable to allocate a home network
prefix for the mobile node, it MUST reject the request and send a prefix for the mobile node, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to 130 Proxy Binding Acknowledgement message with Status field set to 130
(Insufficient resources). (Insufficient resources).
skipping to change at page 17, line 22 skipping to change at page 18, line 32
that request, MUST ensure the prefix is owned by the local that request, MUST ensure the prefix is owned by the local
mobility anchor and further the mobile node is authorized to use mobility anchor and further the mobile node is authorized to use
that prefix. If the mobile node is not authorized to use that that prefix. If the mobile node is not authorized to use that
prefix, the local mobility anchor MUST reject the request and send prefix, the local mobility anchor MUST reject the request and send
a Proxy Binding Acknowledgement message with Status field set to a Proxy Binding Acknowledgement message with Status field set to
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not authorized NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not authorized
to use that prefix). to use that prefix).
o Upon accepting the request, the local mobility anchor MUST create o Upon accepting the request, the local mobility anchor MUST create
a Binding Cache entry for the mobile node. It must set the fields a Binding Cache entry for the mobile node. It must set the fields
in the Binding Cache entry to the accepted value for that binding. in the Binding Cache entry to the accepted values for that
If there is a Link-local Address option present in the request, binding. If there is a Link-local Address option present in the
the address must be copied to the link-local address field in the request, the address must be copied to the link-local address
Binding Cache entry. field in the Binding Cache entry.
o Upon accepting the Proxy Binding Update request, the local o Upon accepting the Proxy Binding Update request, the local
mobility anchor MUST establish a tunnel to the mobile access mobility anchor MUST establish a bi-directional tunnel to the
gateway, as described in [RFC-2473]. Considerations from Section mobile access gateway, as described in [RFC-2473]. Considerations
5.5 must be applied. from Section 5.5 must be applied.
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 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 tunnel for this mobile node. Unless there exists an established bi-
to the mobile access gateway with the same transport and directional tunnel to the mobile access gateway with the same
encapsulation mode, the local mobility anchor MUST create a tunnel transport and encapsulation mode, the local mobility anchor MUST
to the mobile access gateway, as described in [RFC-2473] and also create a tunnel to the mobile access gateway, as described in
delete the existing tunnel established with the previous mobile [RFC-2473] and also delete the existing tunnel route to the
access gateway. It MUST also send a Proxy Binding Acknowledgement previous mobile access gateway. It MUST also send a Proxy Binding
message to the mobile access gateway with the Status field set to Acknowledgement message to the mobile access gateway with the
0 (Proxy Binding Update Accepted). Status field set to 0 (Proxy Binding Update Accepted).
Binding De-Registration: Binding De-Registration:
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 0, 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 its Binding
Cache entry, the local mobility anchor MAY either choose to ignore Cache entry, the local mobility anchor MAY either choose to ignore
the request or send a valid Proxy Binding Acknowledgement message the request or send a valid Proxy Binding Acknowledgement message
with the Status field set to 0 (Proxy Binding Update Accepted). with the Status field set to 0 (Proxy Binding Update Accepted).
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 [Section 9] amount of time, wait for MinDelayBeforeBCEDelete amount of time, before it deletes
before it deletes the mobile node's Binding Cache entry. Within the mobile node's Binding Cache entry. Within this wait period,
this wait period, if the local mobility anchor receives a Proxy if the local mobility anchor receives a Proxy Binding Update
Binding Update request message for the same mobile node and from a request message for the same mobile node and from a different
different mobile access gateway, with the lifetime value of mobile access gateway, with the lifetime value of greater than
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 new values. However, the local mobile anchor MUST send the values. However, the local mobile anchor MUST send the Proxy
Proxy Binding Acknowledgement message, immediately upon accepting Binding Acknowledgement message, immediately upon accepting the
the request. request.
o Upon accepting the request, the local mobility anchor MUST delete o Upon accepting the request, the local mobility anchor MUST delete
the mobile node's Binding Cache entry and remove the Routing state the mobile node's Binding Cache entry and remove the Routing state
for the mobile node's home network prefix. 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*/
Mobility Options Mobility Options
- Home Network Prefix Option - Home Network Prefix Option
skipping to change at page 19, line 32 skipping to change at page 20, line 44
an existing Binding Cache entry for that mobile node with the an existing Binding Cache entry for that mobile node with the
link-local address value of ALL_ZERO (value not set), or if there link-local address value of ALL_ZERO (value not set), or if there
was no existing Binding Cache entry, then the link-local address was no existing Binding Cache entry, then the link-local address
MUST be copied from the received Link-local Address option in the MUST be copied from the received 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 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 MUST be copied from the received o The identifier in the NAI option [RFC-4283] MUST be copied from
Proxy Binding Update request. If the Status field value is set to the received Proxy Binding Update request. If the Status field
MISSING_MN_IDENTIFIER_OPTION, the NAI option MUST NOT be present value is set to MISSING_MN_IDENTIFIER_OPTION, the NAI option MUST
in the reply message. NOT be present in the reply 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, created either dynamically or statically. mobile access gateway.
o The Type 2 Routing header, MUST NOT be present in the IPv6 header
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 RECOMMENDS the use of For solving this problem, this specification RECOMMENDS the use of
Timestamp option [Section 8.4]. The basic principle behind the use Timestamp option [Section 8.4]. The basic principle behind the use
of timestamps in binding registration messages is that the node of timestamps in binding registration messages is that the node
generating the message inserts the current time-of-day, and the node generating the message inserts the current time-of-day, and the node
receiving the message checks that this timestamp is greater than all receiving the message checks that this timestamp is greater than all
previously accepted timestamps. previously accepted timestamps.
Alternatively, the specification also allows the use of Sequence Alternatively, the specification also allows the use of Sequence
Number based scheme, as per [RFC-3775]. The sequence number MUST be Number based scheme, as per [RFC-3775]. The sequence number MUST be
skipping to change at page 20, line 40 skipping to change at page 22, line 9
o An implementation MUST support Timestamp option. If the Timestamp o An implementation MUST support Timestamp option. If the Timestamp
option is present in the received Proxy Binding Update request option is present in the received Proxy Binding Update request
message, then the local mobility anchor MUST include a valid message, then the local mobility anchor MUST include a valid
Timestamp option in the Proxy Binding Acknowledgement message that Timestamp option in the Proxy Binding Acknowledgement message that
it sends to the mobile access gateway. 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,
exchanging binding registration messages using Timestamp option exchanging binding registration messages using Timestamp option
must have adequately synchronized time-of-day clocks. These nodes must have adequately synchronized time-of-day clocks. These nodes
SHOULD synchronize their clocks to a common time source, using SHOULD synchronize their clocks to a common time source, using
Network Time Protocol [RFC-1305] or in any other ways suitable for Network Time Protocol [RFC-4330] or in any other ways suitable for
that specific deployment. 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 the same reference epoch, timestamp is the elapsed time past the same reference epoch, as
as specified in the format for the Timestamp option. specified in the format for the Timestamp option [Section 8.5].
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 o If the Timestamp option is present in the received Proxy Binding
skipping to change at page 22, line 11 skipping to change at page 23, line 25
o The bi-directional tunnel is used for routing the mobile node's o The bi-directional tunnel is used for routing the mobile node's
data traffic between the mobile access gateway and the local data traffic between the mobile access gateway and the local
mobility anchor. The tunnel hides the topology and enables a mobility anchor. The tunnel hides the topology and enables a
mobile node to use an address from its home network prefix from mobile node to use an address from its home network prefix from
any access link attached to the mobile access gateway. any access link attached to the mobile access gateway.
o The bi-directional tunnel is established after accepting the Proxy o The bi-directional tunnel is established after accepting the Proxy
Binding Update request message. The created tunnel may be shared Binding Update request message. The created tunnel may be shared
with other mobile nodes attached to the same mobile access gateway with other mobile nodes attached to the same mobile access gateway
and with the local mobility anchor having a binding cache entry and with the local mobility anchor having a Binding Cache entry
for those mobile nodes. Implementations MAY choose to use static for those mobile nodes. Implementations MAY choose to use static
tunnels as supposed to dynamically creating and tearing them down tunnels as supposed to dynamically creating and tearing them down
on a need basis. on a need basis.
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 registrations 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 Sent by the Mobile Node to the Corresponding 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 corresponding 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. tunneled packet is shown below. However, when using IPv4
transport, the format of the packet is as described in [ID-IPV4-
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-HNP ) /* Packet Header */ IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/ Upper layer protocols /* Packet Content*/
Figure 6: Tunneled Packets from LMA to MAG Figure 7: Tunneled Packets from LMA to MAG
Forwarding Packets Sent by the Corresponding Node to the Mobile Node Forwarding Packets Sent by the Mobile Node:
o All the reverse tunneled packets that the local mobility anchor o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner header MUST be routed to the destination specified in the inner
packet header. These routed packets will have the source address packet header. These routed packets will have the source address
field set to the mobile node's home address. field set to the mobile node's home address.
5.6. Local Mobility Anchor Address Discovery 5.6. Local Mobility Anchor Address Discovery
Dynamic Home Agent Address Discovery, as explained in Section 10.5 Dynamic Home Agent Address Discovery, as explained in Section 10.5
skipping to change at page 24, line 43 skipping to change at page 26, line 12
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 is beyond the scope of this document. that is achieved or the signaling interactions between those
functional entities is 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 28, line 11 skipping to change at page 29, line 28
o The identifier of the mobile node that the mobile access gateway o The identifier of the mobile node that the mobile access gateway
obtains as part of the access authentication or from the notified obtains as part of the access authentication or from the notified
network attachment event, can be a temporary identifier and this network attachment event, can be a temporary identifier and this
identifier may also change at each re-authentication. However, identifier may also change at each re-authentication. However,
the mobile access gateway MUST be able to authenticate the mobile the mobile access gateway MUST be able to authenticate the mobile
node based on this identifier and MUST be able to obtain the MN- node based on this identifier and MUST be able to obtain the MN-
Identifier from the policy store, such as from the RADIUS Identifier from the policy store, such as from the RADIUS
attribute, Chargeable-User-Identifier. attribute, Chargeable-User-Identifier.
o The MN-Identifier that the policy store delivers to the mobile o The MN-Identifier that the policy store delivers to the mobile
access gateway MAY NOT be the true identifier of the mobile node. access gateway may not be the true identifier of the mobile node.
However, the mobility access gateway MUST be able to use this However, the mobility access gateway MUST be able to use this
identifier in the signaling messages exchanged with the local identifier in the signaling messages exchanged with the local
mobility anchor. mobility anchor.
o The mobile access gateway MUST be able identify the mobile node by o The mobile access gateway MUST be able identify the mobile node by
its MN-Identifier and it MUST be able to associate this identity its MN-Identifier and it MUST be able to associate this identity
to the sender of any IPv4 or IPv6 packets on the access link. to the sender of any IPv4 or IPv6 packets on the access link.
6.7. Home Network Emulation 6.7. Home Network Emulation
skipping to change at page 29, line 14 skipping to change at page 30, line 31
for establishing the link-local address uniqueness on that new link. for 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 possibility,
with the odds of 1 to billion, of a link-local address collision with the odds of 1 to billion, of a link-local address collision
between the two neighbors on that access link. between the two neighbors on that access link.
One of the workarounds for this issue is to set the DNAv6 One of the workarounds for this issue is to set the DNAv6
configuration parameter, DNASameLinkDADFlag to TRUE and that will configuration parameter, DNASameLinkDADFlag to TRUE and that will
force the mobile node to redo DAD operation every time the interface force the mobile node to redo DAD operation every time the interface
comes up, even when DNAv6 does detect a link change . detects a handover, even when DNAv6 does not detect a link change.
However, this issues will not impact point-to-point links based on However, this issues will not impact point-to-point links based on
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
skipping to change at page 30, line 13 skipping to change at page 31, line 30
can change its own link-local address, if it detects an address can change its own link-local address, if it detects an address
collision. collision.
This issue is not relevant to the mobile node's global address. This issue is not relevant to the mobile node's global address.
Since, there is a unique home network prefix for each mobile node, Since, there is a unique home network prefix for each mobile node,
the uniqueness for the mobile node's global address is assured on the the uniqueness for the mobile node's global address is assured on the
access link. access link.
6.9. Signaling Considerations 6.9. Signaling Considerations
Initial binding registration 6.9.1. Binding Registrations
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 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, o The Proxy Binding Update message MUST have the NAI option [RFC-
identifying the mobile node, the Home Network Prefix option, 4283], identifying the mobile node, the Home Network Prefix
Timestamp option or a valid sequence number and optionally the option, Timestamp option or a valid sequence number and optionally
Link-local Address option. the Link-local Address option.
o If the mobile access gateway learns the mobile node's home network o If the mobile access gateway learns the mobile node's home network
prefix either from its policy store or from other means, the prefix either from its policy store or from other means, the
mobile access gateway MAY choose to specify the same in the Home mobile access gateway MAY choose to specify the same in the Home
Network Prefix option for requesting the local mobility anchor to Network Prefix option for requesting the local mobility anchor to
allocate that prefix. If the specified value is 0::/0, then the allocate that prefix. If the specified value is 0::/0, then the
local mobility anchor will consider this as a request for prefix local mobility anchor will consider this as a request for prefix
allocation. allocation.
Receiving binding registration reply Receiving Binding Registration Reply:
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
[RFC-3775] related to the presence of Type 2 Routing header in the
Proxy Binding Acknowledgement 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 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
skipping to change at page 31, line 40 skipping to change at page 33, line 14
mobile access gateway MUST create Binding Update List entry for mobile access gateway MUST create Binding Update List entry for
the mobile node and must setup a tunnel to the mobile node's local the mobile node and must setup a tunnel to the mobile node's local
mobility anchor, as explained in section 6.10. mobility anchor, as explained in section 6.10.
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 Binding Re-Registration:
o For extending the lifetime of a currently existing binding at the o For extending the lifetime of a currently existing binding at the
local mobility, the mobile access gateway MUST send a Proxy local mobility, the mobile access gateway MUST send a Proxy
Binding Update message to the local mobility anchor. The prefix Binding Update message to the local mobility anchor. The prefix
value in the Home Network Prefix option present in the request value in the Home Network Prefix option present in the request
SHOULD be set to the currently registered home network prefix and SHOULD be set to the currently registered home network prefix and
the value in the Link-local Address option may be set to ALL_ZERO the value in the Link-local Address option may be set to ALL_ZERO
or to the link-local address of the mobile node. or to the link-local address of the mobile node.
Binding De-Registration Binding De-Registration:
o At any point, the mobile access gateway detects that the mobile o At any point, 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.
Constructing the Proxy Binding Update Message Constructing the Proxy Binding Update Message:
o The mobile access gateway when sending the Proxy Binding Update o The mobile access gateway when sending the Proxy Binding Update
request to the local mobility anchor MUST construct the message as request to the local mobility anchor MUST construct the message as
specified below. specified below.
IPv6 header (src=Proxy-CoA, dst=LMAA) IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header Mobility header
-BU /*P & A flags are set*/ -BU /*P & A flags are set*/
Mobility Options Mobility Options
- Home Network Prefix option - Home Network Prefix option
skipping to change at page 33, line 5 skipping to change at page 34, line 31
o The Home Network Prefix option MUST be present. The prefix value o The Home Network Prefix option MUST be present. The prefix value
may be set 0::/0 or to a specific prefix value. may be set 0::/0 or to a specific prefix value.
o The Link-local Address option MAY be present. The value may be o The Link-local Address option MAY be present. The value may be
set to ALL_ZERO or the mobile node's link-local address. set to ALL_ZERO or the mobile node's link-local address.
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 NAI option MUST be present, the identifier field in the option o The NAI option [RFC-4283] MUST be present, the identifier field in
MUST be set to mobile node's identifier, MN-Identifier. the option MUST be set to mobile node's identifier, MN-Identifier.
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, created either dynamically or statically. mobile access gateway.
6.9.2. Router Solicitation Messages
The mobile node sends a Router Solicitation message on the access
link when ever the link-layer detects a media change. The Source
Address in the IPv6 header of the Router Solicitation message may
either be the link-local address of the mobile node or an unspecified
address (::).
o The mobile access gateway on receiving the Router Solicitation
message SHOULD send a Router Advertisement containing the mobile
node's home network prefix as the on-link prefix. However, before
sending the Router Advertisement message containing the mobile
node's home network prefix, it SHOULD complete the binding
registration process with the mobile node's local mobility anchor.
o If the local mobility anchor rejects the binding registration
request, or, if the mobile access gateway failed to complete the
binding registration process for what ever reasons, the mobile
access gateway MUST NOT advertise the mobile node's home network
prefix in the Router Advertisement messages that it sends on the
access link. However, it MAY choose to advertise a local visitor
network prefix to enable the mobile node for simple IPv6 access.
6.9.3. Retransmissions and Rate Limiting
The mobile access gateway is responsible for retransmissions and rate
limiting the binding registration requests that it sends for updating
a mobile node's binding. Implementations MUST follow the below
guidelines.
o When the mobile access gateway sends a Proxy Binding Update
request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT
[RFC-3775], for configuring the retransmission timer.
o If the mobile access gateway fails to receive a valid matching
response within the retransmission interval, it SHOULD retransmit
the message until a response is received.
o As specified in Section 11.8 [RFC-3775], the mobile access gateway
MUST use an exponential back-off process in which the timeout
period is doubled upon each retransmission, until either the node
receives a response or the timeout period reaches the value
MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway MAY
continue to send these messages at this slower rate indefinitely.
o If Timestamp based scheme is in use, the retransmitted Proxy
Binding Update messages MUST use the latest timestamp. If
Sequence number scheme is in use, the retransmitted Proxy Binding
Update messages MUST use a Sequence Number value greater than that
used for the previous transmission of this Proxy Binding Update
message, just as specified in [RFC-3775].
6.10. Routing Considerations 6.10. Routing Considerations
This section describes how the mobile access gateway handles the This section describes how the mobile access gateway handles the
traffic to/from the mobile node that is attached to one of its access traffic to/from the mobile node that is attached to one of its access
interface. interface.
Proxy-CoA LMAA Proxy-CoA LMAA
| | | |
+--+ +---+ +---+ +--+ +--+ +---+ +---+ +--+
skipping to change at page 36, line 13 skipping to change at page 38, line 39
this is achieved is beyond of the scope of this document. this is achieved is 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
Upon receipt of an encapsulated packet sent to its configured Proxy- Forwarding Packets sent to the Mobile Node's Home Network:
CoA address i.e. on receiving a packet from a tunnel, the mobile
access gateway MUST use the destination address of the inner packet
for forwarding it to the interface where the prefix for that address
is hosted. The mobile access gateway MUST remove the outer header
before forwarding the packet. If the mobile access gateway cannot
find the connected interface for that destination address, it MUST
silently drop the packet. For reporting an error in such scenario,
in the form of ICMP control message, the considerations from Generic
Packet Tunneling specification [RFC-2473] apply.
On receiving a packet from a mobile node connected to its access o On receiving a packet from the bi-directional tunnel established
with the mobile node's local mobility anchor, the mobile access
gateway MUST use the destination address of the inner packet for
forwarding it on the interface where the destination network
prefix is hosted. The mobile access gateway MUST remove the outer
header before forwarding the packet. If the mobile access gateway
cannot find the connected interface for that destination address,
it MUST silently drop the packet. For reporting an error in such
scenario, in the form of ICMP control message, the considerations
from Generic Packet Tunneling specification [RFC-2473] must be
applied.
o On receiving a packet from a corresponding node that is locally
connected, to the mobile node that is on the access link, the
mobile access gateway MUST check the configuration variable,
EnableMAGLocalRouting, to ensure the mobile access gateway is
allowed to route the packet directly to the mobile node. If the
mobile access gateway is not allowed to route the packet directly,
it MUST route the packet through the bi-directional tunnel
established between itself and the mobile node's local mobility
anchor. Otherwise, it can route the packet directly to the mobile
node.
Forwarding Packets Sent by the Mobile Node:
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.
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, to a destination that is locally connected, the mobile access link, to a destination that is locally connected, the mobile
gateway MUST check the configuration variable, EnableMAGLocalRouting, access gateway MUST check the configuration variable,
to ensure the mobile access gateway is allowed to route the packet EnableMAGLocalRouting, to ensure the mobile access gateway is
directly to the destination. If the mobile access gateway is not allowed to route the packet directly to the destination. If the
allowed to route the packet directly, it MUST route the packet mobile access gateway is not allowed to route the packet directly,
through the bi-directional tunnel established between itself and the it MUST route the packet through the bi-directional tunnel
mobile's local mobility anchor. established between itself and the mobile node's local mobility
anchor. Otherwise, it can route the packet directly to the
destination.
On receiving a packet from the mobile node to any destination i.e. o On receiving a packet from the mobile node connected to its access
not directly connected to the mobile access gateway, the packet MUST link, to a destination that is not directly connected, the packet
be forwarded to the local mobility anchor through the bi-directional MUST be forwarded to the local mobility anchor through the bi-
tunnel established between itself and the mobile's local mobility directional tunnel established between itself and the mobile
anchor. However, the packets that are sent with the link-local node's local mobility anchor. However, the packets that are sent
source address MUST not be forwarded. with the link-local source address MUST NOT be forwarded. The
format of the tunneled packet is shown below. However, when using
IPv4 transport, the format of the tunneled packet is as described
in [ID-IPV4-PMIP6].
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 12: Tunneled Packets from MAG to LMA
6.11. Interaction with DHCP Relay Agent 6.11. Interaction with DHCP Relay Agent
If Stateful Address Configuration using DHCP is supported on the link If Stateful Address Configuration using DHCP is supported on the link
where the mobile node is attached, the DHCP relay agent [RFC-3315] where the mobile node is attached, the DHCP relay agent [RFC-3315]
needs to be configured on that access link. needs to be configured on that access link.
When the mobile node sends a DHCPv6 Request message, the DHCP relay When the mobile node sends a DHCPv6 Request message, the DHCP relay
agent function on the access link will set the link-address field in agent function on the access link will set the link-address field in
the DHCPv6 message to the mobile node's home network prefix, so as to the DHCPv6 message to the mobile node's home network prefix, so as to
skipping to change at page 42, line 5 skipping to change at page 45, line 5
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.
8.1. Proxy Binding Update 8.1. Proxy Binding Update Message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P| Reserved | Lifetime | |A|H|L|K|M|R|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Proxy Binding Update Message Figure 13: Proxy Binding Update Message
A Binding Update message that is sent by a mobile access gateway to a A Binding Update message that is sent by a mobile access gateway to a
local mobility anchor is referred to as the "Proxy Binding Update" local mobility anchor is referred to as the "Proxy Binding Update"
message. A new flag (P) is included in the Binding Update message. message. A new flag (P) is included in the Binding Update message.
The rest of the Binding Update message format remains the same as The rest of the Binding Update message format remains the same as
defined in [RFC-3775]. defined in [RFC-3775].
Proxy Registration Flag (P) Proxy Registration Flag (P)
A new flag (P) is included in the Binding Update message to indicate A new flag (P) is included in the Binding Update message to indicate
to the local mobility anchor that the Binding Update message is a to the local mobility anchor that the Binding Update message is a
proxy registration. The flag MUST be set to the value of 1 for proxy proxy registration. The flag MUST be set to the value of 1 for proxy
registrations and MUST be set to 0 for direct registrations sent by a registrations and MUST be set to 0 for direct registrations sent by a
mobile node. mobile node.
For descriptions of other fields present in this message, refer to For descriptions of other fields present in this message, refer to
section 6.1.7 [RFC-3775]. section 6.1.7 [RFC-3775].
8.2. Proxy Binding Acknowledgement 8.2. Proxy Binding Acknowledgement Message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved | | Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Proxy Binding Acknowledgement Message Figure 14: Proxy Binding Acknowledgement Message
A Binding Acknowledgement message that is sent by a local mobility A Binding Acknowledgement message that is sent by a local mobility
anchor to a mobile access gateway is referred to as the "Proxy anchor to a mobile access gateway is referred to as the "Proxy
Binding Acknowledgement" message. A new flag (P) is included in the Binding Acknowledgement" message. A new flag (P) is included in the
Binding Acknowledgement message. The rest of the Binding Binding Acknowledgement message. The rest of the Binding
Acknowledgement message format remains the same as defined in [RFC- Acknowledgement message format remains the same as defined in [RFC-
3775]. 3775].
Proxy Registration Flag (P) Proxy Registration Flag (P)
skipping to change at page 44, line 43 skipping to change at page 47, line 43
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the 8-bit unsigned integer indicating the prefix length of the
IPv6 prefix contained in the option. IPv6 prefix contained in the option.
Home Network Prefix Home Network Prefix
A sixteen-byte field containing the mobile node's IPv6 Home A sixteen-byte field containing the mobile node's IPv6 Home
Network Prefix. Network Prefix.
Figure 13: Home Network Prefix Option Figure 15: Home Network Prefix Option
8.4. Link-local Address Option 8.4. Link-local Address Option
A new option, Link-local Address Option is defined for using it in A new option, Link-local Address Option is defined for using it in
the Proxy Binding Update and Proxy Binding Acknowledgement messages the Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between a local mobility anchor and a mobile access exchanged between a local mobility anchor and a mobile access
gateway. This option is used for exchanging the mobile node's link- gateway. This option is used for exchanging the mobile node's link-
local address. local address.
The Link-local Address option has an alignment requirement of 8n+6. The Link-local Address option has an alignment requirement of 8n+6.
skipping to change at page 45, line 36 skipping to change at page 48, line 36
8-bit unsigned integer indicating the length of the option 8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field in octets, excluding the type and length fields. This field
MUST be set to 16. MUST be set to 16.
Link-local Address Link-local Address
A sixteen-byte field containing the mobile node's link-local A sixteen-byte field containing the mobile node's link-local
address. address.
Figure 14: Link-local Address Option Figure 16: Link-local Address Option
8.5. Timestamp Option 8.5. Timestamp Option
A new option, Timestamp Option is defined for use in the Proxy A new option, Timestamp Option is defined for use in the Proxy
Binding Update and Proxy Binding Acknowledgement messages. Binding Update and Proxy Binding Acknowledgement messages.
The Timestamp option has an alignment requirement of 8n+2. Its The Timestamp option has an alignment requirement of 8n+2. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 46, line 33 skipping to change at page 49, line 33
Timestamp Timestamp
A 64-bit unsigned integer field containing a timestamp. The value A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1, 1970, 00:00 UTC, indicates the number of seconds since January 1, 1970, 00:00 UTC,
by using a fixed point format. In this format, the integer number by using a fixed point format. In this format, the integer number
of seconds is contained in the first 48 bits of the field, and the of seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/64K fractions of a remaining 16 bits indicate the number of 1/64K fractions of a
second. second.
Figure 15: 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 was processed successfully by the local mobility anchor. Status
skipping to change at page 48, line 16 skipping to change at page 51, line 16
gateway MUST route the traffic locally. gateway MUST route the traffic locally.
This aspect of local routing MAY be defined as policy on a per This aspect of local routing MAY be defined as policy on a per
mobile basis and when present will take precedence over this flag. mobile basis and when present will take precedence over this flag.
The local mobility anchor MUST allow the following variables to be The local mobility anchor MUST allow the following variables to be
configured by the system management. configured by the system management.
MinDelayBeforeBCEDelete MinDelayBeforeBCEDelete
This variable specifies the amount of time in milli-seconds the This variable specifies the amount of time in milliseconds the
local mobility anchor MUST wait before it deletes a binding cache local mobility anchor MUST wait before it deletes a Binding Cache
entry of a mobile node, upon receiving a Proxy Binding Update entry of a mobile node, upon receiving a Proxy Binding Update
message from a mobile access gateway with a lifetime value of 0. message from a mobile access gateway with a lifetime value of 0.
During this wait time, if the local mobility anchor receives a During this wait time, if the local mobility anchor receives a
Proxy Binding Update for the same mobile node, identified by its Proxy Binding Update for the same mobile node, identified by its
MN-Identifier, with lifetime value greater than 0, then it must MN-Identifier, with lifetime value greater than 0, then it must
update the binding cache entry with the accepted binding values. update the binding cache entry with the accepted binding values.
At the end of this wait-time, if the local mobility anchor did not At the end of this wait-time, if the local mobility anchor did not
receive any valid Proxy Binding Update message, it MUST delete the receive any valid Proxy Binding Update message, it MUST delete the
binding cache entry for that mobile node. Binding Cache entry for that mobile node.
The default value for this variable is 1000 milli-seconds. The default value for this variable is 1000 milliseconds.
10. IANA Considerations 10. IANA Considerations
This document defines a three new Mobility Header Options, the Home This document defines a three new Mobility Header Options, the Home
Network Prefix option, Link-local Address option and the Timestamp Network Prefix option, Link-local Address option and the Timestamp
option. These options are described in Sections 8.3, 8.4 and 8.5 option. These options are described in Sections 8.3, 8.4 and 8.5
respectively. The Type value for these options needs to be assigned respectively. The Type value for these options needs to be assigned
from the same numbering space as allocated for the other mobility from the same numbering space as allocated for the other mobility
options, as defined in [RFC-3775]. options, as defined in [RFC-3775].
skipping to change at page 49, line 32 skipping to change at page 52, line 32
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.
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, to reasonably ensure, using some out of band mechanisms, that node, should ensure the mobile node is definitively attached to the
the given mobile node is attached to that mobile access gateway that mobile access gateway that sent the binding registration request.
sent the 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.
This scenario is beyond the applicability of this document. This scenario is beyond the applicability of this document.
12. Acknowledgements 12. Acknowledgements
The authors would like to specially thank Julien Laganier, Christian The authors would like to specially thank Julien Laganier, Christian
Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for
skipping to change at page 50, line 20 skipping to change at page 53, line 19
shaped the draft to the current form. We acknowledge that ! shaped the draft to the current form. We acknowledge that !
The authors would also like to thank Ole Troan, Akiko Hattori, Parviz The authors would also like to thank Ole Troan, Akiko Hattori, Parviz
Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and
Tim Stammers for their input on this document. Tim Stammers for their input on this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC-2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
for IPv4, IPv6 and OSI", RFC 2030, October 1996. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003. RFC 3315, July 2003.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [RFC-4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
RFC 3776, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, November 2005. Network Access Identifier", RFC 4282, November 2005.
[RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283,
November 2005. November 2005.
[RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC
4303, December 2005. 4303, December 2005.
13.2. Informative References
[RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
2472, December 1998.
[RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and
P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
[RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
G., Liebsch, M., "Problem Statement for Network-based Localized G., Liebsch, M., "Problem Statement for Network-based Localized
Mobility Management", September 2006. Mobility Management", September 2006.
[RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
G., Liebsch, M., "Goals for Network-based Localized Mobility G., Liebsch, M., "Goals for Network-based Localized Mobility
Management", October 2006. Management", October 2006.
[RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based
Localized Mobility Management", September 2006. Localized Mobility Management", September 2006.
[RFC-4877] Devarapalli, V. and Dupont, F., "Mobile IPv6 Operation
with IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
13.2. Informative References
[RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
2472, December 1998.
[RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC-3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for
Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-00.txt, May Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01.txt, May
2007. 2007.
[ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6 [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol-03.txt, October 2006. Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006.
[ID-MN-AR-INTERFACE] Laganier, J. and Narayanan, S., "Network-based
Localized Mobility Management Interface between Mobile Node and
Mobility Access Gateway", draft-ietf-netlmm-mn-ar-if-02.txt, May
2007.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)",
draft-ietf-mip6-nemo-v4traversal-03.txt, October 2006.
Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure
Every mobile node that roams in a proxy Mobile IPv6 domain, would Every mobile node that roams in a proxy Mobile IPv6 domain, would
typically be identified by an identifier, MN-Identifier, and that typically be identified by an identifier, MN-Identifier, and that
identifier will have an associated policy profile that identifies the identifier will have an associated policy profile that identifies the
mobile node's home network prefix, permitted address configuration mobile node's home network prefix, permitted address configuration
modes, roaming policy and other parameters that are essential for modes, roaming policy and other parameters that are essential for
providing network-based mobility service. This information is providing network-based mobility service. This information is
typically configured in AAA. It is possible the home network prefix typically configured in AAA. It is possible the home network prefix
 End of changes. 82 change blocks. 
274 lines changed or deleted 401 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/