NETLMM WG S. Gundavelli
Internet-Draft K. Leung
Expires: July 9, 2007 Cisco Systems
V. Devarapalli
Azaire Networks
K. Chowdhury
Starent Networks
January 5, 2007
Proxy Mobile IPv6
draft-sgundave-mip6-proxymip6-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 9, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract
This specification describes a network-based mobility management
protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on
Mobile IPv6. This protocol is for providing mobility support to any
IPv6 host within a restricted and topologically localized portion of
Gundavelli, et al. Expires July 9, 2007 [Page 1]
Internet-Draft Proxy Mobile IPv6 January 2007
the network and with out requiring the participation of the host in
any mobility related signaling.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 5
4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 7
4.1. Peer Authorization Database Entries . . . . . . . . . . . 8
4.2. Security Policy Database Entries . . . . . . . . . . . . . 9
5. Home Agent Considerations . . . . . . . . . . . . . . . . . . 9
5.1. Extensions to Binding Cache Conceptual Data Structure . . 10
5.2. Bi-Directional Tunnel Management . . . . . . . . . . . . . 11
5.3. Routing Considerations . . . . . . . . . . . . . . . . . . 12
5.4. Dynamic Home Agent Address Discovery Considerations . . . 13
5.5. Sequencing Number Considerations . . . . . . . . . . . . . 14
5.6. IPv4 Home Address Mobility Support . . . . . . . . . . . . 15
5.7. Route Optimizations Considerations . . . . . . . . . . . . 15
5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 16
5.9. Home Agent Operation Summary . . . . . . . . . . . . . . . 16
6. Proxy Mobile Agent Considerations . . . . . . . . . . . . . . 17
6.1. Address Configuration Models . . . . . . . . . . . . . . . 18
6.2. Access Authentication . . . . . . . . . . . . . . . . . . 19
6.3. Home Network Emulation . . . . . . . . . . . . . . . . . . 19
6.4. Link-Local and Global Address Uniqueness . . . . . . . . . 20
6.5. IPv4 Home Address Mobility Support . . . . . . . . . . . . 20
6.6. Tunnel Management . . . . . . . . . . . . . . . . . . . . 21
6.7. Routing Considerations . . . . . . . . . . . . . . . . . . 21
6.8. Interaction with DHCP Relay Agent . . . . . . . . . . . . 23
6.9. Coexistence of CMIP & PMIP Nodes . . . . . . . . . . . . . 23
6.10. Proxy Mobile Agent Operation Summary . . . . . . . . . . . 24
6.11. Conceptual Data Structures . . . . . . . . . . . . . . . . 26
7. Mobile Node Considerations . . . . . . . . . . . . . . . . . . 26
7.1. Booting in the Proxy Mobile IPv6 Network . . . . . . . . . 27
7.2. Roaming in the Proxy Mobile IPv6 Network . . . . . . . . . 28
7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 28
8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . . 30
8.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . . 30
8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 31
8.4. Time Stamp Option . . . . . . . . . . . . . . . . . . . . 32
8.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Gundavelli, et al. Expires July 9, 2007 [Page 2]
Internet-Draft Proxy Mobile IPv6 January 2007
12.1. Normative References . . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Gundavelli, et al. Expires July 9, 2007 [Page 3]
Internet-Draft Proxy Mobile IPv6 January 2007
1. Introduction
The IP Mobility protocols designed in the IETF so far involve the
host in mobility management. There are some deployment scenarios
where a network-based mobility management protocol is considered
appropriate. The advantages to using a network-based mobility
protocol include avoiding tunneling overhead over the air and support
for hosts that do not implement any mobility management protocol.
The document describes a network-based mobility management protocol
based on Mobile IPv6. it is called Proxy Mobile IPv6 (PMIPv6). One
of the most important design considerations behind PMIPv6 has been to
re-use as much as possible from the existing mobility protocols.
There are many advantages to develop a protocol based on Mobile IPv6.
Mobile IPv6 is a very mature mobility protocol for IPv6. There have
been many implementations and inter-operability events where Mobile
IPv6 has been tested. There also numerous specifications enhancing
Mobile IPv6 that can be re-used. Further, the Proxy MIPv6 solution
described in this document allows the same Home Agent to provide
mobility to hosts that use Mobile IPv6 and hosts that do not use any
mobility management protocol. Proxy Mobile IPv6 provides solution to
a real deployment problem.
2. Conventions used in this document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
The following new terminology and abbreviations are introduced in
this document and all other general mobility related terms as
defined in Mobile IPv6 specification [2].
Proxy Mobile Agent (PMA)
The proxy mobile agent is a functional element on the access
router. This is the entity that makes the mobile node believe
it is on its home link, by emulating the home link properties.
It registers the location of the mobile node to the home agent
and establishes a tunnel for receiving packets sent to the
mobile node's home address.
Mobile Node (MN)
Gundavelli, et al. Expires July 9, 2007 [Page 4]
Internet-Draft Proxy Mobile IPv6 January 2007
This document uses the term mobile node to refer to an IPv6
host. This specification does not require the mobile node to
have the Mobile IPv6 client stack.
3. Proxy Mobile IPv6 Protocol Overview
This specification describes a network-based mobility management
protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on
Mobile IPv6. This protocol is for providing mobility support to any
IPv6 host, within a restricted and topologically localized portion of
the network and with out requiring the participation of the host in
any mobility related signaling.
Every mobile node that roams in a Proxy Mobile IPv6 network, would
typically be identified by an identifier, such as NAI and that
identifier will have an associated policy profile that identifies the
mobile's home network prefix, permitted address configuration modes,
roaming policy and other parameters that are essential for providing
network based mobility service. This information is typically
configured in a policy store, such as in AAA infrastructure. All the
network entities in the Proxy Mobile IPv6 network will have access to
this information.
Once a mobile node enters its Proxy Mobile IPv6 domain and performs
access authentication, the network will ensure the mobile node is
always on its home network and further ensures the mobile can always
obtain its home address on the access link and using any of the
address configuration procedures. In other words, there is home
address/prefix that is assigned for a mobile node and that address
always follows the node, where ever it roams within that PMIP domain.
From the perspective of the mobile node, the entire Proxy Mobile IPv6
domain appears as a single link.
Gundavelli, et al. Expires July 9, 2007 [Page 5]
Internet-Draft Proxy Mobile IPv6 January 2007
+-----+ +-----+
| HA1 | | HA2 |
+-----+ +-----+
| HAA1 | HAA2
+-\\----------------//-\\------+
| \\ PMIP Network// \\ |
+---\\------------//-----\\----+
\\ // \\
\\ // \\
\\ // \\
\\ // \\
\\ // \\
| CoA1 | CoA2
+----+ +----+
[MS1].__.|PMA1|.__.[MS2] |PMA2|
+----+ +----+
| .
| |
------------------- [MS5]
| | |
[MS3] [MS4] [MN]
Figure 1: Proxy Mobile IPv6 Domain
The Proxy Mobile IPv6 scheme introduces a new function, the Proxy
Mobile Agent (PMA). It is a function that runs on the access router
and is the entity that does the mobility related signaling on behalf
of the mobile node. From the perspective of the home agent, the
proxy mobile agent is a special element in the network that sends
Mobile IPv6 signaling messages on behalf of mobile node.
When the mobile node attaches to a link on the access router running
proxy mobile agent, the mobile node presents its identity to the
network in the form of NAI as part of the access authentication
procedure. After a successful authentication, the proxy mobile agent
obtains the mobile's profile from the policy store, such as from a
AAA infrastructure. It can now emulate the mobile's home network on
the access link. The proxy mobile agent sends Router Advertisements
to the mobile node advertising its home prefix.
The mobile node on receiving this Router Advertisement will try to
configure its interface either using statefull or stateless address
configuration modes, based on the permitted configuration modes on
that link. In any case, the mobile node will be able to obtain its
home address.
Gundavelli, et al. Expires July 9, 2007 [Page 6]
Internet-Draft Proxy Mobile IPv6 January 2007
For updating the home agent about the current location of the mobile,
the proxy mobile agent sends a Binding Update message to the mobile
node's home agent. The message will have the mobile node's NAI
identifier option. The source address of that message will be the
address of the proxy mobile agent on the egress interface. Upon
accepting the Binding Update request, the home agent sets up a tunnel
to the proxy mobile agent. It also sets up a route to the mobile
node's home address over the tunnel and sends Binding Acknowledgment
to the proxy mobile agent.
The proxy mobile agent on receiving this Binding Acknowledgment sets
up a tunnel to the home agent and adds a default route over the
tunnel to the home agent. All traffic from the mobile node gets
routed to the mobile node's home agent over the tunnel.
At this point, the mobile node has a valid home address at the point
of current attachment, the serving proxy mobile agent and the home
agent have proper routing states for handling the traffic sent by the
mobile node and also for the incoming traffic to the mobile station.
Home agent being the topological anchor point for the mobile's home
prefix, receives any packet from any corresponding node that is sent
to the mobile node. Home agent forwards the received packet to the
proxy mobile agent through the tunnel. The proxy mobile agent on
other end of the tunnel, after receiving the packet removes the
tunnel header and forwards the packet on the access link to the
mobile station.
The proxy mobile agent acts as a default router on the access link
and any packet that the mobile node sends to any corresponding node
is received by the proxy mobile agent and it forwards the packet to
the home agent through the tunnel. The home agent on the other end
of the tunnel, after receiving the packet removes the tunnel header
and routes the packet to the destination.
4. Proxy Mobile IPv6 Protocol Security
The signaling messages between the proxy mobile agent and the home
agent are protected using IPsec. Per-mobile node security
associations are not required between the proxy mobile agent and the
home agent to protect the Proxy Binding Update and Proxy Binding
Acknowledgment messages.
ESP in transport mode with mandatory integrity protection is used for
protecting the signaling messages. Confidentiality protection is not
required.
Gundavelli, et al. Expires July 9, 2007 [Page 7]
Internet-Draft Proxy Mobile IPv6 January 2007
IKEv2 is used to setup security associations between the proxy mobile
agent and the home agent to protect the Proxy Binding Update and
Proxy Binding Acknowledgment messages. The proxy mobile agent and
the home agent can use any of the authentication mechanisms, as
specified in IKEv2, for mutual authentication.
Mobile IPv6 specification requires the home agent to prevent a mobile
node from creating security associations or creating binding cache
entries for another mobile node's home address. In the protocol
described in this document, the mobile node is not involved in
creating security associations for protecting the signaling messages
or sending binding updates. Therefore, this is not a concern.
However, the home agent MUST allow only authorized proxy mobile
agents to create binding cache entries on behalf of the mobile nodes.
The actual mechanism by which the home agent verifies if a proxy
mobile agent is authorized to send Proxy Binding Updates on behalf of
a mobile node is out of scope for this document. One possible
solution is for the home agent to check with the AAA infrastructure
if a particular proxy mobile agent is authorized to send Proxy
Binding Updates on behalf of a mobile node.
4.1. Peer Authorization Database Entries
The following describes PAD entries on the proxy mobile agent and the
home agent. The PAD entries are only example configurations. Note
that the PAD is a logical concept and a particular proxy mobile agent
or a home agent implementation can implement the PAD in an
implementation specific manner. The PAD state may also be
distributed across various databases in a specific implementation.
proxy mobile agent PAD:
- IF remote_identity = home_agent_identity_1
Then authenticate (shared secret/certificate/)
and authorize CHILD_SA for remote address home_agent_1
home agent PAD:
- IF remote_identity = pma_11
Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SAs for remote address pma_address_1
The list of authentication mechanisms in the above examples is not
exhaustive. There could be other credentials used for authentication
stored in the PAD.
Gundavelli, et al. Expires July 9, 2007 [Page 8]
Internet-Draft Proxy Mobile IPv6 January 2007
4.2. Security Policy Database Entries
The following describes the security policy entries on the proxy
mobile agent and the home agent required to protect the Proxy Mobile
IPv6 signaling messages. The SPD entries are only example
configurations. A particular proxy mobile agent or a Home Agent
implementation could configure different SPD entries as long as they
provide the required security.
In the examples shown below, the identity of the proxy mobile agent
is assumed to be pma_1, the address of the proxy mobile agent is
assumed to be pma_address_1, and the IPv6 address of the Home Agent
is assumed to be home_agent_1.
mobile node SPD-S:
- IF local_address = pma_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = pma_1 to address home_agent_1
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = pma_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU
Then use SA ESP transport mode
5. Home Agent Considerations
For supporting the Proxy Mobile IPv6 scheme defined in this document,
the Mobile IPv6 home agent entity, defined in [RFC-3775], needs some
protocol enhancements. This section describes the required
enhancements and the protocol operation on the home agent for
supporting this scheme.
The base Mobile IPv6 specification [RFC-3775], defines the home agent
and the mobile node as the two key entities. The Proxy Mobile IPv6
scheme introduces a new entity, the Proxy Mobile Agent. This is the
entity that will participate in the mobility related signaling. From
the perspective of the home agent, the proxy mobile agent is a
special element in the network that has the privileges to send
mobility related signaling messages on behalf of the mobile node.
Typically, the home agent is provisioned with the list of proxy
mobile agents authorized to send proxy registrations.
Gundavelli, et al. Expires July 9, 2007 [Page 9]
Internet-Draft Proxy Mobile IPv6 January 2007
When the home agent receives a (Proxy) Binding Update message, the
source address and the alternate care-of address in the message is
the address that is configured on the egress interface of the sending
proxy mobile agent and the message is protected by the Security
Association of the Proxy Mobile Agent identified with that address.
The home agent can distinguish between a Binding Update message
received from a proxy mobile agent from a Binding Update message
received directly from a mobile node. This distinction is important
for using the right security association for validating the Binding
Update and this is achieved by relaxing the MUST requirement for
having the Home Address Option presence in Destination Options header
and by introducing a new flag in the Binding Update message. The
home agent as a traditional IPSec peer can use the SPI in the IPSec
header [RFC-4306] of the received packet for locating the correct
security association and for processing the Binding Update in the
context of Proxy Mobile IP scheme.
To allow configuration flexibility, the Proxy Mobile IPv6 scheme
allows multiple address configuration models, Per-MN-Prefix and the
usual Shared-Prefix addressing model. In the Per-MN-Prefix model,
each mobile is allocated a exclusively unique home prefix and the
prefix is not hosted on the home link. The home agent in this
addressing model is just a topological anchor point and the prefix is
physically hosted on the interface of the proxy mobile agent, where
the mobile is attached. Thus the home agent is not required to
perform any proxy ND operations [RFC-2461] for defending the home
address on the home link. The home agent is required to manage a
binding cache entry for managing the session state and a routing
state for properly routing the packets destined to the mobile node.
5.1. Extensions to Binding Cache Conceptual Data Structure
The home agent maintains a Binding Cache entry for each currently
registered mobile node. The Binding Cache is a conceptual data
structure, described in Section 9.1 of [RFC3775]. For supporting
this specification, the conceptual Binding Cache entry needs to be
extended with the following new fields.
o A flag indicating whether or not this Binding Cache entry is
created due to a proxy registration. This flag is enabled for
Binding Cache entries that are proxy registrations and is turned
off for all other entries that are direct registrations.
o A mobile identifier, NAI, for tagging the Binding Cache entry with
a global identifier of the mobile. This field is set to the value
set in the NAI option [RFC-4285].
Gundavelli, et al. Expires July 9, 2007 [Page 10]
Internet-Draft Proxy Mobile IPv6 January 2007
o A flag indicating whether or not the Binding Cache entry has a
home address that is on virtual interface. This flag is enabled,
if the home prefix of the mobile is configured on a virtual
interface. When the configured home prefix of a mobile is on a
virtual interface, the home agent is not required to function as a
Neighbor Discovery proxy for the mobile node.
o The IPv4 Home Address of the mobile if the mobile is a dual-stack
node and if it has obtained a IPv4 home address as part of the
IPv4 address configuration.
5.2. Bi-Directional Tunnel Management
The bi-directional tunnel between the home agent and the proxy mobile
agent is used for routing the traffic to and from the mobile node.
The tunnel hides the topology and enables the mobile node to use an
address that is topologically anchored at the home agent. The base
Mobile IPv6 specification [RFC-3775], uses the tunneling mechanism
for routing traffic to and from the mobile using its home address.
However, there are subtle differences in the way Proxy Mobile IPv6
uses the tunneling scheme.
As in Mobile IPv4 [RFC-3344], the tunnel between the home agent and
the proxy mobile agent is typically a shared tunnel and MAY be used
for routing traffic streams for different mobiles attached to the
same proxy mobile agent. This specification modifies the 1:1
relation between the tunnel and a binding cache entry to 1:m
relation, reflecting the shared nature of the tunnel.
The source address of the tunnel MUST be the address that is used as
the destination address for the Binding Update messages sent by the
proxy mobile agent.
The home agent SHOULD use a Tunnel-Life timer for managing the tunnel
life time. The timer value should be set to the accepted binding
life time and must be updated after each periodic registration. The
tunnel should be deleted after the expiry of the timer.
The home agent SHOULD maintain a tunnel-user-count counter for each
managed tunnel and this counter should reflect the active mobiles
sharing the tunnel. When the tunnel is being used for routing
traffic to multiple mobiles attached to the same proxy mobile agent,
the home agent MUST set the Tunnel-Life timer value to the highest
binding life time across all the binding life time that is granted
for all the mobiles sharing that tunnel.
Some implementations MAY choose to statically pre-establish the
Gundavelli, et al. Expires July 9, 2007 [Page 11]
Internet-Draft Proxy Mobile IPv6 January 2007
tunnels between the home agent and the proxy mobile agent and with
out having a need to create or tear down the tunnels dynamically on a
need basis.
5.3. Routing Considerations
This section describes how the data traffic to/from the mobile node
is handled at the home agent. The following entries explains the
routing state at the home agent when supporting 1.) Per-MN-Prefix
and 2.) Shared-Prefix addressing models. This section also covers
the routing states when supporting IPv4 home address allocation
support.
HAA - IPv6 global address that is configured on the home agent's
interface and is the address to where the proxy mobile agent
sent the binding update. This is one end-point of the tunnel.
CoA - IPv6 global address that is configured on the proxy mobile
agent's egress interface and is the registered care-of address
in the binding cache entry at the home agent. This is the
remote end point of the tunnel.
HoP - The IPv6 home prefix of the mobile.
HoA - The IPv6 home address of the mobile. This is the IPv6 global
address that the mobile obtained and configured on the remote
MN-AR link from its home prefix (HoP).
HoA_v4 - The IPv4 home address of the mobile. This is the IPv4
address that the mobile obtained, when functioning in the
dual-stack mode, and configured on the remote MN-AR link.
Gundavelli, et al. Expires July 9, 2007 [Page 12]
Internet-Draft Proxy Mobile IPv6 January 2007
Per-MN-Prefix Addressing Model:
===============================
HoP::/64 via tunnel0, next hop CoA
Shared-Prefix Addressing Model:
===============================
HoA::/128 via tunnel0, next hop CoA
IPv4 Home Address support:
==========================
HoA_v4/32 via tunnel0, next hop CoA
tunnel0:
========
Source: HAA
Destination: CoA
Tunnel Transport: IPv6
Tunnel Payload: IPv4, IPv6
The home agent functions as an anchor point for the mobile node's
home prefix. When the home agent receives a data packet from a
corresponding node, destined for the mobile node's home address, the
created routing state will forward the packet to the mobile node
through the bi-directional tunnel established between itself and the
serving proxy mobile agent. When the mobile is allocated a unique
and exclusive home prefix, the home agent will forward all packets
sent to that prefix through the tunnel to the proxy mobile agent, as
the prefix is hosted on the proxy mobile agent.
All the reverse tunneled packets that the home agent receives from
the tunnel, after removing the packet encapsulation will get routed
to the destination specified in the inner packet header. These
routed packets will have the source address field set to the mobile
node's home address.
5.4. Dynamic Home Agent Address Discovery Considerations
Dynamic Home Agent Address Discovery, as explained in Section 10.5 of
[RFC-3775], allows a mobile node to discover all the home agents on
its home link by sending ICMP Home Agent Address Discovery Request
message to the Mobile IPv6 Home-Agents anycast address, derived from
its home network prefix.
The Proxy Mobile IPv6 model assumes that the home agent address
information is pre-configured in the mobile's profile or it may
Gundavelli, et al. Expires July 9, 2007 [Page 13]
Internet-Draft Proxy Mobile IPv6 January 2007
obtained through other means and all the network entities can obtain
this information. It is important to note that there is little value
in using DHAAD for discovering the home agent as the proxy mobile
agents at different access routers will not predictably be able to
locate the current serving home agent for a mobile. However, if
there is only one home agent on the home link, the proxy mobile agent
can use Dynamic Home Agent Address Discovery scheme for discovering
the home agent address.
When the mobile is configured with a shared Shared-Prefix addressing
model, the proxy mobile agent serving the mobile will be able to
discover the mobile's home agent by sending the ICMP Home Agent
Address Discovery Request message to the Mobile IPv6 Home-Agents
anycast address derived from its home prefix. The home agent on the
mobile's home link will receive these messages and will be able to
reply to this message.
When the mobile is configured with a unique Per-MN-Prefix addressing
model, the home agent is a topological anchor point for that prefix
and with the prefix being hosted on the link attached to the proxy
mobile agent. For the discovery scheme to work, the home agent MUST
be able to receive the ICMP discovery packets sent to the anycast
address derived from the mobile's home prefix.
5.5. Sequencing Number Considerations
Sequence number is typically used by two communication end points as
a means to establish order of the exchanged packets. Mobile IPv6
uses the Sequence Number field in the registrations messages. The
home agent and the mobile are required to manage this counter.
In Proxy Mobile IPv6, the Binding Update messages that the home agent
receives on behalf of a specific mobile, may not be from the same
proxy mobile agent and thus the sequence number value in these
messages will have little meaning and the home agent will not be
predictably order the messages and thus may end up processing an
older message while ignoring the latest binding update message.
In the Proxy Mobile IP model, where the ordering of packets have to
established when multiple senders are involved, sequence number
scheme in the absence of time context transfers will not work. A
global scale such as a time stamp is the right way to ensure order of
packets. This document proposes the use of time stamp in all the
Binding Update messages sent by proxy mobile agents. By leveraging
NTP [RFC-1305] service, all the entities in the Proxy Mobile IP
Network will be able to synchronize the clocks and a time stamp field
Gundavelli, et al. Expires July 9, 2007 [Page 14]
Internet-Draft Proxy Mobile IPv6 January 2007
in the Binding Update message will enable the home agent to
predictable identify the latest messages from a list of messages
delivered in a out of order fashion.
The Proxy Mobile IP model, defined in this document requires the
Binding Update messages sent by the proxy mobile agent to have the
time stamp option. The home agent processing a proxy registration
MUST ignore the sequence number field and SHOULD use the value from
the Time Stamp option to establish ordering of the received Binding
Update messages. If the home agent receives a Binding Update message
with a invalid time stamp, the registration request MUST be rejected
and a Binding Acknowledgement must be sent with the status "Invalid
Time Stamp" and with the Time Stamp option.
5.6. IPv4 Home Address Mobility Support
The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the
same infrastructure. It is reasonable to assume that the mobile node
and the home agent are IPv4 and IPv6 enabled and further it is also
reasonable to expect the same mobility infrastructure to provide IPv4
and IPv6 address mobility. The Proxy Mobile IPv6 scheme defined in
this document allows the mobile node to obtain a IPv4 address and to
roam in the network using the same address.
A mobile node attached to a proxy mobile agent, when it sends a DHCP
request, the network will ensure it gets a IPv4 address from its home
address prefix. The DHCP Relay Agent on the access router will tag
the DHCP request from the mobile node with its home prefix hint and
the DHCP server will allocate an address from that prefix. The proxy
mobile agent will send this information in the option, IPv4 Home
Network Prefix Option as part of the Binding Update message. Upon
accepting the registration for the mobile from the proxy mobile
agent, the home address will add IPv4 host route over the tunnel to
the proxy mobile agent. Any IPv4 packets that the home agent
receives from the corresponding node will be routed to the proxy
mobile agent over the IPv6/IPv6 tunnel and any IPv4 packets that it
receives over the tunnel will be routed after removing the tunnel
header.
5.7. Route Optimizations Considerations
Mobile IPv6 route optimization, as defined in [RFC-3775], enables a
mobile node to communicate with a corresponding node directly using
its care-of address and further the Return Routability procedure
enables the corresponding node to have reasonable trust that the
Gundavelli, et al. Expires July 9, 2007 [Page 15]
Internet-Draft Proxy Mobile IPv6 January 2007
mobile node owns both the home address and care-of address.
In the Proxy Mobile IPv6 model, the mobile is not involved in any
mobility related signaling and also it does not operate in the dual-
address mode. Hence, the return routability procedure as defined in
RFC-3775 is not applicable for the proxy model. This document does
not address the Route Optimization problem and leaves this work item
for future enhancements.
This specification further recommends that the home agent MUST drop
all HoTI messages received from a home address that has corresponding
Binding Cache entry with the proxy registration flag set.
5.8. Mobile Prefix Discovery Considerations
The ICMP Mobile Prefix Advertisement message, described in Section
6.8 and Section 11.4.3 of [RFC-3775], allows a home agent to send a
Mobile Prefix Advertisement to the mobile node.
In Proxy Mobile IPv6 deployments, the mobile's home prefix
information would be typically configured in the mobile's profile and
so there is not much need for this dynamic nature of prefix
discovery. Thus, this specification does not support Mobile Prefix
Discovery.
5.9. Home Agent Operation Summary
After receiving a Proxy Binding Update request from a proxy mobile
agent on behalf of a mobile node, the home agent must process the
request as defined Section 10, of the base Mobile IPv6 specification
[RFC-3775], with one exception that this request is a proxy request
and proper authorization checks have to be enforced.
The home agent must use the NAI option present in the mobility header
of the Binding Update message for identifying the mobile and for
downloading the mobile's policy from the policy store. This policy
will contain the mobile's address configuration model, home prefix,
home address and other parameters.
The home agent has to verify the policy to ensure the proxy mobile
agent that is sending this request has the right to do so, else it
MUST reject the request and send a Proxy Binding Acknowledgment with
the proper status code.
The home agent MUST ignore the sequence number field in the Binding
Update for proxy registrations.
Gundavelli, et al. Expires July 9, 2007 [Page 16]
Internet-Draft Proxy Mobile IPv6 January 2007
If the received Binding Update does not have a home network prefix
option and if there is no Binding Cache entry for that mobile node,
the home agent MUST reject the registration with
HOME_ADDRESS_REQUIRED status code.
Upon accepting this request, the home agent must create a Binding
Cache entry with the home address from the Home Network Prefix Option
in the Binding Update and must set up a tunnel to the proxy mobile
agent serving the mobile node. This bi-directional tunnel between
the home agent and the proxy mobile agent is used for routing the
mobile traffic.
For supporting this scheme, the home agent MUST satisfy all the
requirements listed in Section 8.4 of [1]. The key differences of
this scheme for the Per-MN-Prefix configuration mode, when compared
to the base protocol is as follows:
The mobile node is not anchored on any physical interface on the home
agent. Thus the home agent is not required to perform any proxy ND
operations for defending the home address on the home link. The home
agent is required to manage a binding cache entry for managing the
session state and a routing state for properly routing the packets
destined to the mobile node.
Each mobile node has a home address in a prefix that is created
exclusively for that mobile node and no other mobile node will share
its home address from this prefix.
The route entry specifying that the mobile node's home prefix is
reachable via the tunnel is created as supposed to creating an route
entry just for the mobile node's home address.
If multiple mobile stations are currently visiting the same proxy
mobile agent, all the binding updates will share the same care-of
address and possibly the same tunnel.
6. Proxy Mobile Agent Considerations
The Proxy Mobile IPv6 scheme introduces a new function, the Proxy
Mobile Agent (PMA). It is a function that runs on the access router
and is the entity that does the mobility related signaling on behalf
of the mobile node.
From the perspective of the home agent, the proxy mobile agent is a
Gundavelli, et al. Expires July 9, 2007 [Page 17]
Internet-Draft Proxy Mobile IPv6 January 2007
special element in the network that sends Mobile IPv6 signaling
messages on behalf of a mobile station using its own identity. It is
the entity that binds the mobile node's home address to an address on
its own access interface.
The Proxy Mobile Agent has the following functional roles. It will
emulate the mobile node's home network on the access link, will
update the home agent about the current location of the mobile node
and sets up a data path for enabling the mobile node to use its home
address for communication from the access link.
This specification is independent of the underlying access technology
or the link model. The interface between the mobile and the access
router can be either:
o Point-to-Point Link
o Shared Link
This specification does not support split links. Also, it is to be
noted that from the current deployment perspective, Point-to-Point
link model appears to be the most common and required model.
6.1. Address Configuration Models
This specification supports the following address configuration
models:
o Per-MN-Prefix Model
o Shared-Prefix Model
In the Per-MN-Prefix model, there is a unique home prefix assigned
for each mobile node and that prefix is hosted on the access link.
The prefix just follows the mobile. In this addressing model, based
on the administrative policy, the mobile node can use either
Stateless Address Autoconfiguration or Statefull Address
Configuration using DHCP for obtaining the IPv6 address configuration
for its interface on the access link. Further, the mobile can also
generate interface identifiers with privacy considerations, as
specified in [RFC-3041].
In the Shared-Prefix model, the prefix is a shared prefix and the
mobile is not the only node using an address from that prefix block.
In this addressing model, Stateless Address Autoconfiguration is not
supported by this specification. The mobile is allowed to use only
Gundavelli, et al. Expires July 9, 2007 [Page 18]
Internet-Draft Proxy Mobile IPv6 January 2007
Statefull Address Configuration using DHCP for obtaining the address
configuration for its interface on the link.
The configured administrative policy for the mobile dictates the type
of addressing model that is supported for a mobile on the access
link. The proxy mobile agent on the access router will control this
by setting the relevant flags in the Router Advertisement
accordingly.
6.2. Access Authentication
Access authentication is outside scope of this document. This
specification does not deal with the access link security and further
assumes that there are proper authorization models in place for
ensuring only authorized nodes with their respective identities are
able to access the link.
Access authentication on any wireless access link, ensures a node
with a given MAC address and an Identifier such as NAI, is authorized
to use the link and the Layer-2 security ensures that. This
specification assumes such security mechanisms are in place.
6.3. Home Network Emulation
One of the key functions of the proxy mobile agent is to emulate the
mobile's home network on the access link. It has to ensure, the
mobile believes it is on its home link. After the access
authentication, the proxy mobile agent can obtain the mobile's
profile and from that it has to send the Router Advertisements to the
mobile advertising its home prefix and other parameters. Further if
the mobile uses statefull Address Configuration mode such as DHCP,
the proxy mobile agent or the DHCP Relay Agent [RFC-3315], MUST set
the link-address field of the DHCP request to the mobile's home
network prefix and the DHCP server will allocate an address from that
prefix block, as specified in Section 20.1.1 of [RFC-3315].
If the access link is a point-to-point link, the advertisements from
the proxy mobile agent on that link are not seen by any other mobile
stations. However, if the access link is a shared link, the proxy
mobile agent has to ensure that each of the mobile node that is
attached to that link receive only their home prefixes as the on-link
prefixes. For this to happen, the proxy mobile agent MUST unicast
the Router Advertisement to the mobile node. The destination field
of the Layer-2 header in the Router Advertisement MUST be the
mobile's node's MAC address and however, the destination field in the
IPv6 header can be the all-nodes-multicast address.
Gundavelli, et al. Expires July 9, 2007 [Page 19]
Internet-Draft Proxy Mobile IPv6 January 2007
6.4. Link-Local and Global Address Uniqueness
On a point-to-point link, when the mobile tries to establish a PPP
session [RFC-1661] with the access router, the PPP goes through the
Network layer Protocol phase and the IPv6 Control Protocol, IPCP6
[RFC-2472] gets triggered. Both the PPP peers negotiate a unique
identifier using Interface-Identifier option in IPV6CP and the
negotiated identifier is used for generating a unique link-local
address on that link. Now, if the mobile moves to a new access
router, the PPP session gets torn down and new PPP session with the
new access router will be established and the mobile obtains a new
link-local address. Now, even if the mobile is DNAv6 capable, as
specified in [draft-ietf-dna-protocol-03], the mobile still
configures a new link-local address when ever it moves to a new link.
However, if the link between the mobile node and the access router is
a shared link and if a DNAv6 capable mobile moves from access network
to the other, the mobile may not detect link change due to DNAv6 (how
ever this really depends on the wireless technology in use),
detecting the same link and there is a remote possibility for the
link local address collision on the new link. One of the work around
for this issue to the set following flag on the mobile,
DNASameLinkDADFlag to TRUE and that will force the mobile to redo DAD
operation even when the DNAv6 detected no link change.
For the global address or the home address uniqueness, the home agent
will not accept a Binding Update from a mobile, identified by a NAI,
for a home address that is already registered for some other mobile
station. Further, if the address configuration is based on statefull
Address Configuration using DHCP, the DHCP server will ensure the
uniqueness.
6.5. IPv4 Home Address Mobility Support
If the mobile node is permitted to roam using a IPv4 home address and
if the mobile has a dual-stack, the mobile can send a DHCP request
and can obtain the IPv4 address configuration for its interface. As
part of this configuration, the mobile node will obtain a IPv4
address, subnet address, subnet mask and default-router address. The
relay agent service on the access router will ensure the mobile node
is assigned an address from its home prefix, by marking the DHCP
request with the prefix hint.
However, the default-router address that is obtained from the DHCP
will be that of a router on its home link and the mobile node is on
the access link. In order for the mobile node to be able use the
default router for routing all IPv4 packets, the proxy mobile agent
Gundavelli, et al. Expires July 9, 2007 [Page 20]
Internet-Draft Proxy Mobile IPv6 January 2007
on the access link must respond to the ARP requests from the mobile
node for the default-router's IPv4 address. Now, if the mobile roams
to a new link, the proxy mobile agent on that link must send a
gratuitous ARP for the mobile's default-router address.
In IPv6, the nodes on the link use the link-local address of the
default router for routing packets and it is not required that the
default router needs to have a configured address from the prefix
that the node uses. However, in IPv4, the default-router address on
the link must be from the same subnet as of the IP address of the
node. Since, the proxy mobile agent will not have an address on the
mobile's home prefix, it must act as a proxy for the mobile router's
IPv4 gateway address.
6.6. Tunnel Management
In the traditional Mobile IPv6 model, there is a separate tunnel from
the home agent to every mobile node that has a binding entry. The
tunnel end-point of each these tunnels is the respective mobile
node's care-of address and that is unique to that mobile node. In
the case of Proxy Mobile IPv6, the care-of address or the tunnel end-
point is the address of the proxy mobile agent and there could be
multiple mobile stations attached to the same proxy mobile agent and
hence the tunnel is a shared tunnel serving multiple mobile stations.
This is identical to the Mobile IPv4 model [RFC-3344], where a tunnel
between the foreign agent and the home agent is shared by many
visiting mobile nodes.
The life of the Proxy Mobile IP tunnel should not be based on a
single binding cache entry. The tunnel may get created as part of
creating a mobility binding for a mobile node and later the same
tunnel may be associated with other binding entries. So, the tearing
down logic of the tunnel must be based on the number of visitors over
that tunnel. Implementations are free to pre-establish tunnels
between every home agent and every proxy mobile node in the network
and with out creating and destroying the tunnels on a need basis.
6.7. Routing Considerations
This section describes how the data traffic to/from the mobile node
is handled at the proxy mobile agent. The following entries explains
the routing state at the proxy mobile agent.
Gundavelli, et al. Expires July 9, 2007 [Page 21]
Internet-Draft Proxy Mobile IPv6 January 2007
HAA - IPv6 global address that is configured on the home agent's
interface and is the address to where the proxy mobile agent
sent the binding update. This is one end-point of the tunnel.
CoA - IPv6 global address that is configured on the proxy mobile
agent's egress interface and is the registered care-of address
in the binding cache entry at the home agent. This is the
remote end point of the tunnel.
HoP - The IPv6 home prefix of the mobile.
HoA - The IPv6 home address of the mobile. This is the IPv6 global
address that the mobile obtained and configured on the remote
MN-AR link from its home prefix (HoP).
HoA_v4 - The IPv4 home address of the mobile. This is the IPv4
address that the mobile obtained, when functioning in the
dual-stack mode, and configured on the remote MN-AR link.
Per-MN-Prefix Addressing Model:
===============================
For all traffic from the source address HoA to
0::/0 route via tunnel0, next hop HAA
HoA::/64 is on the interface locally connected
Shared-Prefix Addressing Model:
===============================
For all traffic from the source prefix HoA::/64 to
0::/0 route via tunnel0, next hop HAA
HoA::/128 is on the interface locally connected
IPv4 Home Address support:
==========================
For all IPv4 traffic from the source address HoA_v4 to
0.0.0.0/0.0.0.0 route via tunnel0, next hop HAA
HoA_v4/32 is on the interface locally connected
tunnel0:
========
Source: CoA
Destination: HAA
Tunnel Transport: IPv6
Gundavelli, et al. Expires July 9, 2007 [Page 22]
Internet-Draft Proxy Mobile IPv6 January 2007
Tunnel Payload: IPv4, IPv6
When the proxy mobile agent receives any packets from the mobile
station to any destination, the packet will be forwarded to the home
agent through the bi-directional tunnel established between itself
and the mobile's home agent. However, the packets that are sent with
link-local source address are not forwarded.
All the packets that the proxy mobile agent receives from the tunnel,
after removing the tunnel encapsulation, will get forwarded to the
mobile node on the connected interface.
6.8. Interaction with DHCP Relay Agent
If Statefull Address Configuration using DHCP is supported on the
access link, the DHCP Relay Agent [RFC-3315] needs to be configured
on the access router. When the mobile stations sends a DHCP Request,
the relay agent function on the access router must set the link-
address field in the DHCP message to the mobile node's home prefix,
so as to provide a prefix hint to the DHCP Server. On a point-to-
point link, this is just a normal DHCP relay agent configuration.
However, on the shared links supporting multiple mobile stations with
different home prefixes, there is some interaction required between
the relay agent and the proxy mobile agent, for setting the link-
address field to the requesting mobile node's home prefix. The proxy
mobile agent should also have the ability to learn the DHCP assigned
address to the mobile station.
If the mobile is permitted to roam using IPv4 home address, the
DHCPv4 relay agent service [RFC-2131] needs to be configured on that
link. Further, the giaddr field in the request packet must be set to
the mobile node's IPv4 home prefix.
6.9. Coexistence of CMIP & PMIP Nodes
In some operating environments, network operators may want to
provision a particular link attached to an access router running
proxy mobile agent for supporting nodes using Mobile IP signaling and
the nodes that depend on the network for doing the Mobile IP
signaling for achieving network mobility. This specification
supports links with such mixture of nodes.
Upon obtaining the mobile node's profile after a successful access
authentication and after a policy consideration, the proxy mobile
agent MUST determine if the network based mobility service should be
Gundavelli, et al. Expires July 9, 2007 [Page 23]
Internet-Draft Proxy Mobile IPv6 January 2007
offered to that mobile node. If the mobile is entitled for such
service, then the network should ensure the mobile believes it is on
its home link, as explained in various sections of this document.
If the mobile is not entitled for the network based mobility service,
the proxy mobile agent MUST ensure the mobile can obtain an IPv6
care-of address using normal IPv6 address configuration mechanisms.
The obtained address should be from a local visitor network prefix.
In other words the mobile should be able to operate as a traditional
mobile node roaming in a visitor network and with the ability to
obtain a care-of address from the local visitor network prefix hosted
on that link.
If the stateless address configuration mode is supported on that
link, the prefix information option in the router advertisements
should contain local visitor network prefix. If statefull address
configuration mode is enforced on the link and if DHCP is in used,
the mobile should obtain the IPv6 or IPv4 care-of address from the
local visitor network prefix.
If the link between the access router and the mobile node is a shared
link, the Router Advertisement has to unicasted to the mobile station
with the destination address in the layer-2 header set to the
mobile's MAC address and the destination address in the IPv6 header
set to the all-nodes multicast address.
6.10. Proxy Mobile Agent Operation Summary
After detecting a new mobile node on its access link and after a
successful access authentication, the proxy mobile agent using the
mobile's identifier will obtain the mobile's profiles from the policy
store. The mobile's policy can also be pushed to the proxy mobile
agent using context transfer procedure. Context Transfer is out of
scope for this current specification. The mobile's profile contains
the mobile node's home agent address, home prefix, addressing model,
permitted address configuration mechanisms and other parameters that
are needed to emulate the mobile's home network on the access
network.
The proxy mobile agent constructs a Router Advertisement containing
the mobile's home prefix and it will send it to the mobile node. If
the link between the mobile node and the access router is a shared
link, then the Router Advertisement will be unicasted to the mobile
station by setting the destination address in the layer-2 header to
the mobile's MAC address and the destination address in the IPv6
header set to the all-nodes multicast address.
Gundavelli, et al. Expires July 9, 2007 [Page 24]
Internet-Draft Proxy Mobile IPv6 January 2007
The proxy mobile agent sends a Proxy Binding Update to the home
agent. The source address of this message will be the configured
IPv6 address on the egress interface. The contents of the message
include the Mobile Node NAI Option, Home Network Prefix Option, IPv4
Home Address Option and Time Stamp Option. This message will be
protected by using IPSec security association created between the
proxy mobile agent and home agent.
If the mobile is configured for the Per-MN-Prefix model, the proxy
mobile agent will set the Home Network Prefix Option to the mobile's
home network that is learnt from the mobile's profile. The home
agent sets up a route for the whole prefix and there is no MUST
requirement that the mobile's home address is associated in the BCE
at the home agent. However, if the proxy mobile agent predictably
learns the address that the mobile is using from its home prefix, it
is recommended that the Home Network Prefix Option be set with the
specific home address, so that the Binding Cache entry on the home
agent will have a reachable address for the mobile.
If the mobile is configured for Per-MN-Address model, the proxy
mobile agent must set the Home Network Prefix Option to the DHCP
assigned address for that mobile. It is possible, the mobile is
DNAv6 capable and after attaching to a new link, it never initiates a
DHCP request. In that situation, the proxy mobile agent must send
the Binding Update with out the Home Network Prefix option and the
home agent will send the mobile's home address in Binding
Acknowledgement message, if there is a Binding Cache entry for that
mobile, else it will reject the Binding Update and the proxy mobile
agent must wait till the mobile triggers the DHCP for address
configuration.
After receiving a Proxy Binding Acknowledgment with the status code
indicating the acceptance of the Binding Acknowledgment, the proxy
mobile agent MUST setup a tunnel to the home agent, as explained in
the above sections.
If the home agent denies the Proxy Binding Update request, the proxy
mobile agent MUST NOT advertise the mobile node's home prefix on the
link and there by denying the mobility service to the mobile station.
At any point, if the proxy mobile agent detects that the mobile node
has roamed away from its home link, it MUST send a Binding Update to
the home agent with the lifetime value of 0 and it must remove the
route over the tunnel for that mobile and also delete the tunnel if
no other mobile traffic route is setup over that tunnel.
Gundavelli, et al. Expires July 9, 2007 [Page 25]
Internet-Draft Proxy Mobile IPv6 January 2007
6.11. Conceptual Data Structures
Every proxy mobile agent maintains a Binding Update List for each
currently registered visitor. The Binding Update List is a
conceptual data structure, described in Section 11.1 [RFC-3775]. For
supporting this specification, the conceptual Binding Update List
must be extended with the following new fields.
o The Identifier of the mobile node in the form of NAI. This is
obtained as part of the Access Authentication procedure. This
identifier is required for downloading the mobile node's profile
from the policy store.
o A flag specifying whether or not the configured addressing model
for the mobile is Per-MN-Prefix model. If the flag is not set,
indicates the configured addressing model is a Shared-Prefix
model.
o The link-local address of the mobile node on the link. This
address is learned through the Source Address of the Router
Solicitation messages received from the mobile node on the link.
o The IPv4 home address of the mobile, if IPv4 home address mobility
is supported.
o The IPv4 home network prefix length of the mobile, if IPv4 home
address mobility is supported.
o The IPv4 default router address of the mobile, if IPv4 home
address mobility is supported. This is the address that is
configured on the home agent.
7. Mobile Node Considerations
The Proxy Mobile IPv6 scheme, defined in this document, enables a
mobile node to achieve network mobility with out requiring its
participation in any mobility related signaling. The specification
assumes the mobile node is a IPv6 host, and optionally IPv4 capable,
if it is operating as a dual-stack node.
Once the mobile enters a Proxy Mobile IPv6 domain and attaches to an
access network, the network identifies the mobile as part of the
access authentication procedure and ensures the mobile using any of
Gundavelli, et al. Expires July 9, 2007 [Page 26]
Internet-Draft Proxy Mobile IPv6 January 2007
the address configuration mechanisms permitted by the network for
that mobile, will be able to obtain an address and move anywhere in
that managed domain. From the perspective of the mobile, the entire
Proxy Mobile IPv6 domain appears as a single link, the network
ensures the mobile believes it is always on its home link. If the
mobile is Mobile IPv6 client, as per [RFC-3775], the mobile will not
detect movement and hence it will not trigger the Mobile IPv6
registrations.
7.1. Booting in the Proxy Mobile IPv6 Network
When the mobile node attaches to a link on the access router running
proxy mobile agent, it will present its identity to the network in
the form of NAI as part of the access authentication procedure.
After performing the required access authentication procedures, the
network knows the mobile's home prefix, address configuration models
and other parameters.
After a successful access authentication, the mobile node will send a
Router Solicitation message. The proxy mobile agent on the link will
respond to the Router Solicitation message with a Router
Advertisement. The Router Advertisement will have the mobile node's
home prefix, default router and other address configuration
parameters. The address configuration parameters such as Managed
Address Configuration, statefull Configuration flag values will be
consistent with the home link policy.
If the Router Advertisement has the Managed Address Configuration
flag set, the mobile node, as it would normally do, will send a DHCP
Request and again the proxy mobile agent on that link will ensure,
the mobile node gets its home address as a lease from the DHCP
server.
If the Router Advertisement does not have the Managed Address
Configuration flag set, the mobile node can autoconfigure itself by
appending its link-layer address (EUI-64 format) to the advertised
local home network prefix or it can configure an address per [RFC-
3041] specification.
Once the address configuration is complete, the mobile node will
always be able to use that IPv6/IPv4 address anywhere with in that
managed network where proxy mobile agents are deployed. Further, the
mobile node will always get the same Address even after a reboot.
Gundavelli, et al. Expires July 9, 2007 [Page 27]
Internet-Draft Proxy Mobile IPv6 January 2007
7.2. Roaming in the Proxy Mobile IPv6 Network
After booting in the network and obtaining a IPv6 and possibly IPv4
address as well (if the network supports dual-stack mode), the mobile
when it moves from one access network to the other in that Proxy
Mobile IP domain, will always detect its home link, home prefix and
obtains the same IPv6/IPv4 address, if it uses DHCP for address
configuration. However, the mobile always detects a new default-
router on the new link advertising its home prefix and with a
different link-local address. Any Router Solicitation messages from
the mobile node will result in a Router Advertisement advertising its
home prefix, default router and other configuration parameters
consistent with the home link properties.
7.3. IPv6 Host Protocol Parameters
This specification assumes the mobile node to be a normal IPv6 host,
with its protocol operation consistent with the base IPv6
specification [RFC-2460]. All aspects of Neighbor Discovery
Protocol, including Router Discovery, Neighbor Discovery, Address
Configuration procedures will just remain consistent with the base
IPv6 Neighbor Discovery Specification [RFC-2461]. However, the
protocol RECOMMENDS the mobile station to adjust the following IPv6
operating parameters to the below recommended values for protocol
efficiency and for achieving faster hand-offs.
Lower Default Router List Cache Time-out:
As per the base IPv6 specification [RFC-2460], each IPv6 host will
maintain certain host data structures including a Default Router
list. This is the list of on-link routers that have sent Router
Advertisement messages and are eligible to be a default routers on
that link. The Router Lifetime field in the received Router
Advertisement defines the life of this entry.
In the Proxy IPv6 scenario, when the mobile node moves from one link
to another, the received Router Advertisement messages advertising
the mobile's home prefix on the new access link are from a different
link-local address and thus making the mobile believe that there is a
new default router on the link. It is important that the mobile node
uses the newly learnt default router as supposed to the previous
learnt default router. The mobile node must update its default-
router list with the new default router entry and must age out the
previously default router entry from its cache, just as specified in
Gundavelli, et al. Expires July 9, 2007 [Page 28]
Internet-Draft Proxy Mobile IPv6 January 2007
Section 6.3.5 of the base IPv6 ND specification [1]. This action is
critical for minimizing packet losses during a hand off switch.
On detecting a reachability problem, the mobile node will certainly
detect the neighbor or the default router unreachability by
performing a Neighbor Unreachability Detection procedure, but it is
important that the mobile node times out the previous default router
entry at the earliest. If a given IPv6 host implementation has the
provision to adjust these flush timers, still conforming to the base
IPv6 ND specification, it is desirable to keep the flush-timers to
suit the above consideration.
However, if the proxy mobile agent has the ability to with draw the
previous router entry, by multicasting a Router Advertisement using
the link-local address that of the previous mobility proxy agent and
with the Router Lifetime field set to zero, then it is possible to
force the flush out of the Previous Default Router entry from the
mobile node's cache. This certainly requires the proxy mobile agent
to notify its link-local address to the home agent as part of the
binding update and the home agent to associate this opaque data with
the binding cache entry so that a new proxy mobile agent can learn
the link-local address of the previous router and send a Router
Advertisement with that link-local address.
There are other solutions possible for this problem, including the
assignment of a unique link-local address for all the access routers
in the Proxy Mobile IP Network. In either case, this is an
implementation choice and has no bearing on the protocol
interoperability. Implementations are free to adopt the best
approach that suits their target deployments.
8. Message Formats
This section defines extensions to the Mobile IPv6 [RFC-3775]
protocol messages.
Gundavelli, et al. Expires July 9, 2007 [Page 29]
Internet-Draft Proxy Mobile IPv6 January 2007
8.1. Proxy Binding Update
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Proxy Binding Update Message
A new flag, the 'P' flag, is added to the Binding Update message
[RFC-3775]. The 'P' flag indicates that the registration is a Proxy
Registration. When a proxy mobile agent sends a registration to the
home agent, the P flag MUST be set to value of 1, to indicate to the
home agent that this registration is a proxy registration sent by a
proxy mobile agent on behalf of a mobile node.
For descriptions of other fields present in this message, refer to
[RFC3775].
A Binding Update message that is sent by proxy mobile agent is also
referred to as "Proxy Binding Update".
8.2. Proxy Binding Acknowledgment
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gundavelli, et al. Expires July 9, 2007 [Page 30]
Internet-Draft Proxy Mobile IPv6 January 2007
Figure 9: Proxy Binding Acknowledgment Message
Proxy Registration Flag (P)
A new flag, the 'P' flag, is added to the Binding Acknowledgement
message [RFC-3775]. The Proxy Registration Flag is set to a value of
1, to indicate that the home agent that processed the Proxy Binding
Update supports Proxy Registration. This flag value is set only if
the corresponding Proxy Binding Update had the Proxy Registration
Flag set.
For descriptions of other fields present in this message, refer to
[RFC3775].
A Binding Acknowledgment message that is sent by proxy mobile agent
is also referred to as "Proxy Binding Acknowledgement".
8.3. Home Network Prefix Option
A new option, Home Network Prefix Option is defined for using it in
the Proxy Binding Update and Acknowledgment messages exchanged
between the home agent to the proxy mobile agent. This option can be
used for exchanging the mobile node's home prefix and home address
information.
The home network prefix Option has an alignment requirement of 8n+4.
Its format is as follows:
Gundavelli, et al. Expires July 9, 2007 [Page 31]
Internet-Draft Proxy Mobile IPv6 January 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<IANA>
Length
Eight-bit unsigned integer indicating the length in octets of
the option, excluding the type and length fields. Set to 18.
Reserved
This field is unused for now. The value MUST be initialized
to 0 by the sender and MUST be ignored by the receiver.
Prefix Length
Eight-bit unsigned integer indicating the prefix length of
the IPv6 prefix contained in the option. If the prefix length
is set to the value 128, indicates the presence of the
mobile's home address.
Home Network Prefix
A sixteen-byte field containing the Home Network Prefix
Figure 10: Home Network Prefix Option
8.4. Time Stamp Option
A new option, Time Stamp Option is defined for use in Proxy Binding
Update and Acknowledgement messages. This option MUST be present in
Gundavelli, et al. Expires July 9, 2007 [Page 32]
Internet-Draft Proxy Mobile IPv6 January 2007
all Proxy Binding Update and Acknowledgement messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<IANA>
Length
Eight-bit unsigned integer indicating the length in octets of
the option, excluding the type and length fields. Set to 18.
Timestamp
64bit time stamp
Figure 11: Time Stamp Option
8.5. Status Codes
Binding Acknowledgment Status Values
The following status code values are defined for using them in the
Binding Acknowledgment message when using PMIPv6 protocol.
145: Proxy Registration not supported by the home agent
146: Proxy Registrations from this proxy mobile agent not allowed
147: No home address for this NAI is configured and the Home Network
Prefix Option not present in the Binding Update.
148: Invalid Time Stamp Option in the Binding Update
Gundavelli, et al. Expires July 9, 2007 [Page 33]
Internet-Draft Proxy Mobile IPv6 January 2007
Status values less than 128 indicate that the Binding Update was
processed successfully by the receiving nodes. Values greater than
128 indicate that the Binding Update was rejected by the Home Agent.
The value allocation for this usage needs to be approved by the IANA
and must be updated in the IANA registry.
9. IANA Considerations
This document defines a new Mobility Header Option, the Mobile Home
Network Prefix Option. This option is described in Section 8.3. The
Type value for this option needs to be assigned from the same
numbering space as allocated for the other mobility options defined
in [RFC-3775].
This document defines a new Mobility Header Option, the Time Stamp
Option. This option is described in Section 8.4. The type value for
this option needs to be assigned from the same numbering space as
allocated for the other mobility options defined in [RFC-3775].
This document also defines new Binding Acknowledgement status values
as described in Section 8.5. The status values MUST be assigned from
the same space used for Binding Acknowledgement status values in
[RFC-3775].
10. Security Considerations
The Mobile IPv6 base specification [RFC-3775] requires the signaling
messages between the home agent and the mobile node to be secured by
the use of IPsec extension headers.
This document introduces a new functional entity, proxy mobile agent,
a function that will be implemented in the access routers. This
entity is responsible for performing the Mobile IPv6 signaling on
behalf of the mobile node, also called as Proxy Mobile IPv6
Signaling.
All signaling messages between the Proxy Mobile Agent and the Home
Agent MUST be authenticated by IPsec [RFC-4301]. The use of IPsec to
protect Mobile IPv6 signaling messages is described in detail in the
HA-MN IPsec specification [RFC-3776]. The signaling messages
described in this document just extend Mobile IPv6 messages and just
requires some subtle changes to what is described in the HA-MN IPSec
Gundavelli, et al. Expires July 9, 2007 [Page 34]
Internet-Draft Proxy Mobile IPv6 January 2007
specification.
As described in the base Mobile IPv6 specification [RFC-3775],
Section 5.1 both the mobile client (in this case, its the proxy
mobile agent) and the home agent MUST support and SHOULD use the
Encapsulating Security Payload (ESP) header in transport mode and
MUST use a non-NULL payload authentication algorithm to provide data
origin authentication, data integrity and optional anti-replay
protection.
This document does not cover the security requirements for
authorizing the mobile node for the use of the access link. It is
assumed that there are proper Layer-2 based authentication
procedures, such as EAP, in place and will ensure the mobile node is
properly identified and authorized before permitting it to access the
network. It is further assumed that the same security mechanism will
ensure the mobile session is not hijacked by malicious nodes on the
access link.
The proxy solution allows one device creating a routing state for
some other device at the home agent. It is important that the home
agent has proper authorization services in place to ensure a given
proxy mobile agent is permitted to be a proxy for a specific mobile
node. If proper security checks are not in place, a malicious node
may be able to hijack a session or may do a denial-of-service
attacks.
11. Acknowledgements
The authors would like to thank Julien Laganier, Alex Petrescu, Brian
Haley, Ahmad Muhanna, Mohamed Khalil, Fred Templing, Nishida
Katsutoshi, James Kempf, Vidya Narayanan, Henrik Levkowetz, Phil
Roberts, Jari Arkko, Ashutosh Dutta, Hesham Soliman and many others
for their passionate discussions in the working group mailing list on
the topic of Proxy Mobile IPv6 and NETLMM. These discussions
stimulated much of the thinking and shaped the draft to the current
form. We acknowledge that ! The authors would also like to thank
Ole Troan, Akiko Hattori and Perviz Yegani for their input on this
document.
12. References
Gundavelli, et al. Expires July 9, 2007 [Page 35]
Internet-Draft Proxy Mobile IPv6 January 2007
12.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
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
IPv6 Specification", RFC 2473, December 1998.
[RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", Work in Progress.
[RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
RFC 3776, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283,
November 2005.
[RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC
2406, December 2005.
[RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[draft-ietf-netlmm-nohost-req-05.txt] Kempf, J., Leung, K., Roberts,
P., Nishida, K., Giaretta, G., Liebsch, M., "Goals for Network-based
Localized Mobility Management", October 2006.
[draft-ietf-netlmm-nohost-ps-05.txt] Kempf, J., Leung, K., Roberts,
P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for
Gundavelli, et al. Expires July 9, 2007 [Page 36]
Internet-Draft Proxy Mobile IPv6 January 2007
Network-based Localized Mobility Management", September 2006.
[draft-ietf-netlmm-threats-04.txt] Vogt, C., Kempf, J., "Security
Threats to Network-Based Localized Mobility Management", September
2006.
12.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.
[RFC2434] 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.
[RFC3344] 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.
[draft-ietf-dna-protocol-03] Kempf, J., et al "Detecting Network
Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol-03,
October 2006.
[draft-ietf-mip6-ikev2-ipsec-08] Devarapalli, V. and F. Dupont,
"Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture"
December 2006.
Gundavelli, et al. Expires July 9, 2007 [Page 37]
Internet-Draft Proxy Mobile IPv6 January 2007
Authors' Addresses
Sri Gundavelli
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Kent Leung
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: kleung@cisco.com
Vijay Devarapalli
Azaire Networks
4800 Great America Pkwy
Santa Clara, CA 95054
USA
Email: vijay.devarapalli@azairenet.com
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA
Email: kchowdhury@starentnetworks.com
Gundavelli, et al. Expires July 9, 2007 [Page 38]
Internet-Draft Proxy Mobile IPv6 January 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gundavelli, et al. Expires July 9, 2007 [Page 39]