Mobile IPv6 Extensions Group F. Zhao
Internet-Draft S. Faccin
Expires: January 7, 2009 A. Damle
Marvell
July 6, 2008
IKEv2 based Mobile Network Prefix Assignment
draft-zhao-mext-mnp-ikev2-00
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 January 7, 2009.
Zhao, et al. Expires January 7, 2009 [Page 1]
Internet-Draft MNP Assigment July 2008
Abstract
This document proposes a mechanism for the Mobile Router to
dynamically obtain the Mobile Network Prefix through IKEv2. The
mechanisms to renew, release and update the allocated Mobile Network
Prefixes are also described.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Attribute Format . . . . . . . . . . . . . . . . . . . . . 4
4. Mobile Network Prefix Assignment . . . . . . . . . . . . . . . 6
5. Mobile Network Prefix Management . . . . . . . . . . . . . . . 8
5.1. Renewing the Mobile Network Prefix . . . . . . . . . . . . 8
5.2. Releasing the Mobile Network Prefix . . . . . . . . . . . 8
5.3. Updating the Mobile Network Prefix . . . . . . . . . . . . 9
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 10
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Zhao, et al. Expires January 7, 2009 [Page 2]
Internet-Draft MNP Assigment July 2008
1. Introduction
With the specification of the Network Mobility (NEMO) Basic Support
Protocol defined in RFC 3963 [1], a Mobile Router needs to advertise
an IPv6 prefix, called the Mobile Network Prefix, on the link
associated with the Mobile Network in order for the Mobile Network
Nodes to perform IP address configuration and thus obtain IP
connectivity. Static configuration of the Mobile Network Prefix on
the Mobile Router is inefficient, especially when the Mobile Networks
are to be deployed at a large scale. However, the NEMO Basic Support
protocol [1] does not specify a dynamic Mobile Network Prefix
assignment mechanism for the Mobile Router.
Besides the Mobile Network Prefix, the Mobile Router needs its Home
Agent address, its Home Address, and the necessary information (such
as IPsec security associations) shared with the Home Agent to protect
signaling and/or data traffic, when it powers up and uses the NEMO/
DSMIPv6 protocol to obtain network connectivity. The procedure for
the Mobile Node to obtain such information is called bootstrapping
[2] in the context of Mobile IPv6. Bootstrapping solutions [3] [4]
are proposed for both split and integrated scenarios, such as Home
Agent discovery via DHCP or DNS and Home Address assignment via
IKEv2. In order to reduce complexity and costs of implementation, it
is desired that the components of the Mobile IPv6 bootstrapping
mechanism are re-used as much as possible for NEMO Mobile Router
bootstrapping.
In this document, we propose that the Mobile Router obtains the
Mobile Network Prefix through IKEv2, i.e. using the same message
exchange for the Home Address assignment. In addition, we describe
mechanisms to renew, release and update the allocated Mobile Network
Prefix.
2. Terminology
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 [5].
Mobility terminology used throughout this document is defined in [6],
[7] and [8].
Zhao, et al. Expires January 7, 2009 [Page 3]
Internet-Draft MNP Assigment July 2008
3. New Attribute Format
We propose a new IKEv2 Configuration Attribute, called
MOBILE_NETWORK_PREFIX6. This attribute is carried in the IKEv2
Configuration Payload and is used to convey an IPv6 Mobile Network
Prefix between the Mobile Router and the Home Agent. Figure 1 shows
the format of the MOBILE_NETWORK_PREFIX6 Configuration Attribute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Mobile Network Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
Figure 1: The format of the MOBILE_NETWORK_PREFIX6 attribute
Reserved (1 bit)
This bit MUST be set to zero and MUST be ignored on receipt.
Attribute Type (15 bits)
A unique identifier for the MOBILE_NETWORK_PREFIX6 attribute
(to be determined by IANA).
Length (2 octets)
Length in octets of fields, including IPv6 Mobile Network
Prefix, Prefix Lifetime and Prefix Length. This can be 0 or
21.
Prefix Lifetime (4 octets)
The length of time period during which the Mobile Network
Prefix remains valid. This should not be longer than the
lifetime of the IKE security association used when the Mobile
Network Prefix is assigned to the Mobile Router.
Zhao, et al. Expires January 7, 2009 [Page 4]
Internet-Draft MNP Assigment July 2008
IPv6 Mobile Network Prefix (16 octets)
The IPv6 Mobile Network Prefix to be advertised to the Mobile
Network.
Prefix Length (1 octet)
The length in bits of the Mobile Network Prefix specified in
the IPv6 Mobile Network Prefix field.
When the Mobile Router requests a new Mobile Network Prefix, the
Mobile Router includes the MOBILE_NETWORK_PREFIX6 attribute in the
CFG_REQUEST payload and the value of the Length field is zero or the
IPv6 Mobile Network Prefix field is set as zero. The Mobile Router
may indicate the preferred Mobile Network Prefix in this attribute
and the Home Agent should return the indicated Mobile Network Prefix,
if available. The Mobile Router may explicitly request a lifetime by
specifying a value in the Prefix Lifetime field. Such value must not
be zero if the Mobile Router specifies a preferred Mobile Network
Prefix and is set as 2^32-1 if the Mobile Router wants the assigned
Mobile Network Prefix remains valid for the lifetime of the IKEv2
security association. The Mobile Router may request multiple Mobile
Network Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes
in one IKEv2 request message.
If such request from the Mobile Router is valid, the Home Agent
includes the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REPLY
payload and sends it back to the Mobile Router in one IKEv2 response
message. The attribute contains the allocated Mobile Network Prefix
and the lifetime authorized by the Home Agent. If the Mobile Router
requests multiple Mobile Network Prefixes in one IKEv2 request
message, the Home Agent should return multiple Mobile Network
Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes in one
IKEv2 response message.
There are different mechanisms for the Home Agent to allocate the
Mobile Network Prefix. For example, the Home Agent may manage a pool
of network prefixes by itself or communicate with a DHCP server
located in the home domain for this task. The details of such
mechanisms are out of scope of this document.
Zhao, et al. Expires January 7, 2009 [Page 5]
Internet-Draft MNP Assigment July 2008
4. Mobile Network Prefix Assignment
When the Mobile Router powers up, based on its configuration or some
mechanisms that are out of scope of this document, the Mobile Router
may choose hosted based mobility protocols, such as DSMIPv6/NEMO, to
set up network connectivity. Figure 2 shows the steps performed by
the Mobile Router during bootstrapping.
MR Access network HA
| | |
| IP address configuration | |
|<-------------------------->| |
| | |
| Home Agent discovery | |
|<--------------------> | |
| | |
| IKE_SA_INIT{...} |
|<------------------------------------------------------->|
| |
| IKE_AUTH{CFG_REQUEST(HoA/HNP, MNP)} |
|-------------------------------------------------------->|
| |
| IKE_AUTH{CFG_REPLY(HoA/HNP, MNP)} |
|<--------------------------------------------------------|
| |
| BU/BA |
|<------------------------------------------------------->|
| |
Figure 2: The procedure of the Mobile Network Prefix assignment via
IKEv2
o When attaching to a new link, the Mobile Router configures an IP
address on its interface that attaches to this link, for example,
by performing IP address stateless configuration using Router
Solicitation and Router Advertisement messages.
o The Mobile Router discovers the IP address of the Home Agent, for
example, by using mechanisms defined in [6] [3] and [4].
o The Mobile Router starts to establish a security association and
firstly completes the IKE_SA_INIT exchange with the discovered
Home Agent.
o During the IKE_AUTH exchange, in addition to a Home Address or
Home Network Prefix, the Mobile Router also requests a Mobile
Network Prefix from the Home Agent by including the
MOBILE_NETWORK_PREFIX6 attribute in the CFG_REQUEST payload.
Zhao, et al. Expires January 7, 2009 [Page 6]
Internet-Draft MNP Assigment July 2008
o The Home Agent verifies this request based on its policy and
configuration. If this request is valid, the Home Agent allocates
a Mobile Network Prefix in addition to a Home Address or Home
Network Prefix. The information regarding the allocated Mobile
Network Prefix, including the lifetime, is carried in the
MOBILE_NETWORK_PREFIX6 attribute and sent back to the Mobile
Router. The Mobile Router configures the Home Address and the
Mobile Network Prefix based on the received CFG_REPLY payload.
o If the Mobile Router attaches to its home link (the details of the
home link detection mechanism is out of scope of this document),
the Mobile Router does not perform binding registration with the
Home Agent. Otherwise, the Mobile Router follows the procedure
specified in the NEMO Basic Support Protocol [1] to register the
binding between its Care-of address and its Home Address and the
Mobile Network Prefix with the Home Agent. In addition to an
IPSec security association to protect mobility signaling messages,
the Mobile Router may negotiate an IPSec child security
association with the Home Agent to protect the data traffic
from/to itself and the Mobile Network Nodes.
Zhao, et al. Expires January 7, 2009 [Page 7]
Internet-Draft MNP Assigment July 2008
5. Mobile Network Prefix Management
After the Mobile Router obtains the Mobile Network Prefix, in the
most common case, the Mobile Network Prefix is used until the current
IKEv2 security association expires or is explicitly deleted or re-
authenticated, i.e. the Mobile Network Prefix is valid through the
lifetime of the IKEv2 security association. In this case, either the
Mobile Router or the Home Agent can initiate the procedure to renew,
release and update the allocated Mobile Network Prefix by performing
operations, such as rekeying or re-establishing the IKEv2 security
association as specified in the IKEv2 protocol [9].
On the other hand, with the Informational Exchange already defined in
the IKEv2 protocol [9], an allocated Mobile Network Prefix can also
be renewed, released and updated while the IKEv2 security association
is still valid. Such Informational Exchange is protected by the
IKEv2 security association.
In the following, we focus on mechanisms for renewing, releasing and
updating the Mobile Network Prefix in the second case.
5.1. Renewing the Mobile Network Prefix
When the lifetime of the allocated Mobile Network Prefix is about to
expire, the Mobile Router needs to extend the lifetime of the Mobile
Network Prefix, if it still wants to use the same Mobile Network
Prefix. Otherwise, if the Home Agent does not receive any renewal
request before expiration, the Home Agent will recycle the expired
Mobile Network Prefix for re-allocation later.
The renewal procedure is usually initiated by the Mobile Router. To
renew a Mobile Network Prefix, the Mobile Router initiates the IKEv2
Informational Exchange with the Home Agent and includes the Mobile
Network Prefix to be renewed and a new lifetime in the CFG_REQUEST
payload. If such request is valid, the Home Agent sends back the
same Mobile Network Prefix with the authorized lifetime in the CFG-
REPLY payload to the UE.
5.2. Releasing the Mobile Network Prefix
The Mobile Network Prefix release procedure can be initiated by
either the Mobile Router or the Home Agent.
To release an allocated Mobile Network Prefix, the Mobile Router
initiates the IKEv2 Informational Exchange with the Home Agent. In
the CFG_REQUEST payload carried in the IKEv2 request message, the
Mobile Router includes the Mobile Network Prefix to be released and
the lifetime set as zero in the MOBILE_NETWORK_PREFIX6 attribute. As
Zhao, et al. Expires January 7, 2009 [Page 8]
Internet-Draft MNP Assigment July 2008
a reply, the Home Agent returns a CFG_REPLY payload indicating the
released Mobile Network Prefix and the lifetime set as zero.
To release an allocated Mobile Network Prefix, the Home Agent can
also initiate the IKEv2 Informational Exchange with the Mobile
Router. In the IKEv2 Informational Exchange message sent to the
Mobile Router, the Home Agent uses the CFG_REQUEST payload to carry
the MOBILE_NETWORK_PREFIX6 attribute that indicates the Mobile
Network Prefix to be released and the lifetime set as zero. When the
Mobile Router receives such IKEv2 request message, it removes the
corresponding configuration and replies with a CFG_REPLY payload to
carry the MOBILE_NETWORK_PREFIX6 attribute that indicates the
released Mobile Network Prefix and the lifetime set as zero. When
the Home Agent receives this responses, it recycles the released
Mobile Network Prefix.
5.3. Updating the Mobile Network Prefix
The Mobile Network Prefix update procedure can be initiated by either
the Mobile Router or the Home Agent.
One way to perform the Mobile Router initiated Mobile Network Prefix
update procedure is that the Home Agent returns a different Mobile
Network Prefix when the Mobile Router requests to renew a Mobile
Network Prefix. Another way is that the Mobile Router indicates the
release of the old Mobile Network Prefix and the request of a new
Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6
attributes in one CFG_REQUEST payload. The Home Agent should return
a new Mobile Network Prefix and confirm the release of the old Mobile
Network Prefix by using two separate MOBILE_NETWORK_PREFIX6
attributes in one CFG_REPLY payload.
To perform the Home Agent initiated Prefix update procedure, the Home
Agent indicates the release of the old Mobile Network Prefix and the
assignment of a new Mobile Network Prefix by using two separate
MOBILE_NETWORK_PREFIX6 attributes in one CFG_REQUEST payload. In
this case, the Mobile Node should confirm the assignment of the new
Mobile Network Prefix and the release of the old Mobile Network
Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one
CFG_REPLY payload.
Zhao, et al. Expires January 7, 2009 [Page 9]
Internet-Draft MNP Assigment July 2008
6. Security Consideration
This document describes the use of a new IKEv2 Configuration
Attribute to assign the Mobile Network Prefix to the Mobile Router.
The security issues related to the IKEv2 protocol are discussed in
the "Security Considerations" section of the Internet Key Exchange
(IKEv2) Protocol [9]. This document does not introduce any
additional security considerations related to such IKEv2 message
exchange.
When the Mobile Router requests a Mobile Network Prefix from the Home
Agent during the IKEv2 message exchange, in addition to verifying the
identity of the Mobile Router, the Home Agent must also verify
whether the Mobile Router is eligible to request a Mobile Network
Prefix, based on the Mobile Router's profile and network policies.
This is because the policy of the home network operator may not allow
the Mobile Router to request the Mobile Network Prefix from a Home
Agent located in the certain roaming domain. Such verification can
be performed as a part of IKEv2 authentication process, for example,
by checking the Mobile Router's profile after authenticating the
identity of the Mobile Router and associated credentials using
certain authentication protocols (e.g. EAP).
The NEMO Basic Support protocol [1] requires that the Home Agent
check if a Mobile Network Prefix received in a Binding Update message
is authorized to be used. To do so, the Home Agent can associate the
mobile node identity used in the IKEv2 authentication process with
the Home Network Prefix allocated.
In some deployment, the Home Agent itself manages the allocation of
Mobile Network Prefixes, for example, from a locally managed prefix
pool. It is also possible that additional back-end servers are used
for Mobile Network Prefix assignment. For example, the Home Agent
can act as a DHCP Requesting Router and interact with a DHCP
Delegating Router. The security mechanism protecting the interaction
between the Home Agent and such back-end servers could be generic
security mechanisms, such as IPSec, or specific to the protocols used
in between, such as DHCP authentication option. Once allocated, the
Mobile Network Prefix must not be assigned to a different Mobile
Router until such Mobile Network Prefix is returned to the Home
Agent.
7. IANA Consideration
This document defines one new IKEv2 Configuration Attribute Type,
MOBILE_NETWORK_PREFIX6. The value of such type is expected to be
assigned from the "IKEv2 Configuration Payload Attribute Types"
Zhao, et al. Expires January 7, 2009 [Page 10]
Internet-Draft MNP Assigment July 2008
namespace [9] by IANA.
8. References
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2] Patel, A. and G. Giaretta, "Problem Statement for Bootstrapping
Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
[4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft draft-ietf-mip6-bootstrapping-integrated-06, April 2008.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[8] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[10] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[11] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[12] Ernst, T., "Network Mobility Support Goals and Requirements",
RFC 4886, July 2007.
[13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
Zhao, et al. Expires January 7, 2009 [Page 11]
Internet-Draft MNP Assigment July 2008
[14] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Authors' Addresses
Fan Zhao
Marvell Semiconductor, Inc.
5488 Marvell Lane
Santa Clara, CA 95054
US
Email: fanzhao@marvell.com
Stefano Faccin
Marvell Semiconductor, Inc.
5488 Marvell Lane
Santa Clara, CA 95054
US
Email: smfaccin@marvell.com
Ameya Damle
Marvell Semiconductor, Inc.
5488 Marvell Lane
Santa Clara, CA 95054
US
Email: adamle@marvell.com
Zhao, et al. Expires January 7, 2009 [Page 12]
Internet-Draft MNP Assigment July 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.
Zhao, et al. Expires January 7, 2009 [Page 13]