NETLMM Working Group V. Devarapalli
Internet-Draft WiChorus
Intended status: Standards Track October 27, 2008
Expires: April 30, 2009
Separating Control and Data Plane for Proxy Mobile IPv6
draft-devarapalli-netlmm-pmipv6-data-plane-00.txt
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 April 30, 2009.
Abstract
Proxy Mobile IPv6 is a network-based mobility management protocol.
The mobility entities involved in the Proxy Mobile IPv6 protocol, the
Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA),
setup tunnels dynamically to manage mobility for a mobile node within
the Proxy Mobile IPv6 domain. This document describes an extension
to the Proxy Mobile IPv6 protocol to register a data plane address,
that is different from the Proxy Care-of Address with the LMA. This
allows separation of control and data plane.
Devarapalli Expires April 30, 2009 [Page 1]
Internet-Draft PMIPv6 Data Plane Option October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Control and Data Plane Separation . . . . . . . . . . . . . . . 4
3.1. Extensions to Binding Update List and Binding Cache
Data Structures . . . . . . . . . . . . . . . . . . . . . . 5
4. Data Plane Address Mobility Option . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Devarapalli Expires April 30, 2009 [Page 2]
Internet-Draft PMIPv6 Data Plane Option October 2008
1. Introduction
Proxy Mobile IPv6 [2] enables network-based mobility for IPv6 hosts
that do not implement any mobility protocols. The protocol is
described in detail in [2]. In order to facilitate the network-based
mobility, the PMIPv6 protocol defines a Mobile Access Gateway (MAG),
which acts as a proxy for the Mobile IPv6 [4] signaling, and the
Local Mobility Anchor (LMA) which acts similar to a Home Agent,
anchoring a Mobile Node's sessions within a Proxy Mobile IPv6
(PMIPv6) domain. The LMA and the MAG establish a bidirectional
tunnel for forwarding all data traffic belonging to the Mobile Nodes.
Some of the deployments of Proxy Mobile IPv6 are planning to separate
the control and data plane end points for the Mobile Access Gateway.
There will be a separate IP address for the entity that sends and
receives the Proxy Mobile IPv6 signaling messages. Similarly, there
will be a separate IP address for the entity that encapsulates and
decapsulates the data traffic to/from the mobile node. According to
RFC 5213 [2] and RFC 3775 [4], the LMA stores only IP address, the
Proxy Care-of Address (PCOA), in the proxy binding cache entry at the
LMA. Therefore the LMA uses the same IP address of a MAG for
signaling messages and data traffic.
In order to allow the separation of the control and data plane, this
document describes an extension to register two IP addresses with the
LMA. The IP address used for the signaling messages will continue to
be called the Proxy Care-of Address. A separate IP address for the
data plane is carried in the Proxy Binding Update to indicate the
tunnel end point for the data traffic.
The separation of control and data plane allows a number of
scenarios. It is possible to keep the control plane end point the
same for a mobile node as it moves across the MAGs in the PMIPv6
domain. The new MAG, the mobile node attaches to, is only used as
the data plane end point. This helps in avoiding access
authentication every time the mobile node moves and attaches to a
different MAG. The mechanism described in the document also enables
some load balancing scenarios, where the data traffic is directed to
different application blades in a chassis-based PMIPv6 network entity
implementation, with a fewer number of blades handling the control
traffic.
The control and data plane separation might require some interaction
between the control plane and data plane end points. For example,
the data plane end point would need to install some forwarding
entries for the mobile node based on the PMIPv6 signaling messages
exchanged by the control plane end point. Future versions of this
document may specify the messages required for such an interaction.
Devarapalli Expires April 30, 2009 [Page 3]
Internet-Draft PMIPv6 Data Plane Option October 2008
It is out of scope for this document for now.
The mechanism described in the document can be used by both the MAG
and the LMA for control and data plane separation.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
3. Control and Data Plane Separation
If a MAG wants to register a separate data plane address, it MUST
include the Data Plane Address mobility option described in
Section 4, in the Proxy Binding Update. The MAG MUST include the
IPv6 address of the data plane end point in the Data Plane Address
mobility option In case there is an IPv4 transport network between
the MAG and the LMA as described in [3], the MAG MUST include the
IPv4 address of the data plane end point.
When the LMA receives a Proxy Binding Update message with the Data
Plane Address mobility option, it MUST store the address in the
mobility option as the end point for the PMIPv6 tunnel created for
carrying the mobile node's traffic. The source address of the Proxy
Binding Update message or the address in the Alternate Care-of
Address option [4], if present, is stored as the Proxy Care-of
Address for the particular binding. If the Data Plane Address option
was successfully processed, the LMA MUST include the Data Plane
Address option in the Proxy Binding Acknowledgment message without
any IP address in the mobility option. In case the LMA does not
support the mechanism described in this document, it will not
recognize the Data Plane Address mobility option and will skip
processing the option. If the LMA recognizes the option, but does
not want use separate IP addresses for the control and data planes,
it MUST send a Proxy Binding Acknowledgment message with a failed
status, "DATA_PLANE_SEPARATION_NOT_ALLOWED".
If the MAG receives a Proxy Binding Acknowledgment message without
the Data Plane mobility option in response to a Proxy Binding Update
in which it had included a Data Plane Address option, it MUST
conclude that the LMA does not support the separation of control and
data plane. The MAG MUST then raise an alarm for an administrative
action. If the MAG receives a Proxy Binding Acknowledgment message
with status, "DATA_PLANE_SEPARATION_NOT_ALLOWED", it MUST NOT send
any more Proxy Binding Update messages to the particular LMA and MUST
Devarapalli Expires April 30, 2009 [Page 4]
Internet-Draft PMIPv6 Data Plane Option October 2008
raise an alarm for an administrative action.
Even though the mechanism described in this document is primarily
intended for separation of control and data plane on the MAG, it is
possible to use it for the LMA also. If the LMA wants to use a
separate data plane address, it should include the data plane end
point in the Data Plane Address mobility option in the Proxy Binding
Acknowledgment message. The MAG would use this address as the LMA
tunnel end point for data traffic.
3.1. Extensions to Binding Update List and Binding Cache Data
Structures
This document extends the Binding Update List entry on the MAG and
the Binding Cache Entry on the LMA to include the data plane address
in addition to the Proxy Care-of Address. The Proxy Care-of Address
MUST be used for all Proxy Mobile IPv6 signaling messages, including
messages initiated by the LMA like the Binding Revocation Indication
message [7]. The Data Plane address MUST be used for tunneling the
data traffic meant for the mobile node.
4. Data Plane Address Mobility Option
The following shows the message format for a new mobility option for
carrying the data plane address, or the tunnel end point. The Data
Plane Address Mobility Option is only valid in a Proxy Binding Update
and Proxy Binding Acknowledgment messages. It has an alignment
requirement of 4n+1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Plane Address .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field that indicates that it is a Data Plane Address
mobility option.
Length
A 8-bit field that indicates the length of the option in octets
excluding the 'Type' and 'Length' fields. It is set to '5' if an
IPv4 address is carried in the option. It is set to '17' if an
Devarapalli Expires April 30, 2009 [Page 5]
Internet-Draft PMIPv6 Data Plane Option October 2008
IPv6 address is carried in the option. If there is no address
being carried in the option, i.e., it is being sent by the LMA
just to acknowledge the processing of the Data Plane Address
mobility option in the Proxy Binding Acknowledgment, then it is
set to '1'.
Reserved
A 8-bit field that is set to '0' and ignored by the receiver.
Data Plane Address
A 32-bit or 128-bit field to carry the IPv4 or IPv6 address of the
Proxy Mobile IPv6 tunnel end point. This field is absent if the
LMA is sending this option in the Proxy Binding Acknowledgment
messages to indicate that it processed the Data Plane Address
mobility option in the preceding Proxy Binding Update message.
5. Security Considerations
Since the Data Plane Address mobility option is carried in the Proxy
Binding Update and Proxy Binding Acknowledgment messages, no
additional security beyond what is described in RFC 5213. According
to RFC 5213 [2], these messages are protected by the use of IPsec
[5].
As a result of the control and data plane separation, if there is an
interface with new messages between the control plane and data plane
end points, the messages exchanged on this interface MUST be secured.
Integrity protection is mandatory. Confidentiality protection is
optional. If the messages use the Mobility Header protocol [4], it
is recommended that these messages are protected by the use of IKEv2
[6] and IPsec [5].
6. IANA Considerations
The Data Plane Address mobility option defined in Section 4 must have
the type value allocated from the same space as the Mobility Options
defined in RFC 3775 [4].
A new Proxy Binding Ack status value from the "Status Codes" registry
defined by RFC 3775 [4] should be allocated. The new status code is
a failure status code, (>128) and is called
"DATA_PLANE_SEPARATION_NOT_ALLOWED".
Devarapalli Expires April 30, 2009 [Page 6]
Internet-Draft PMIPv6 Data Plane Option October 2008
7. Acknowledgments
The author would like to think the folks involved in the discussion
on the NETLMM mailing list on the topic of separating the control and
data plane for Proxy Mobile IPv6.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[3] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile
IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 (work in
progress), September 2008.
8.2. Informative References
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[7] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P.
Yegani, "Binding Revocation for IPv6 Mobility",
draft-ietf-mext-binding-revocation-01 (work in progress),
August 2008.
Author's Address
Vijay Devarapalli
WiChorus
3950 North First Street
San Jose, CA 95134
USA
Email: vijay@wichorus.com
Devarapalli Expires April 30, 2009 [Page 7]
Internet-Draft PMIPv6 Data Plane Option October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Devarapalli Expires April 30, 2009 [Page 8]