Internet DRAFT - draft-sarikaya-v6ops-prefix-delegation
draft-sarikaya-v6ops-prefix-delegation
Network Working Group B. Sarikaya
Internet-Draft F. Xia
Intended status: Informational Huawei USA
Expires: August 13, 2012 T. Lemon
Nominum
February 10, 2012
DHCPv6 Prefix Delegation in Long Term Evolution (LTE) Networks
draft-sarikaya-v6ops-prefix-delegation-11.txt
Abstract
As interest on IPv6 deployment is increasing in cellular networks
several migration issues are being raised and IPv6 prefix management
is the one addressed in this document. Based on the idea that DHCPv6
servers can manage prefixes, we address prefix management issues such
as the access router offloading delegation and release tasks of the
prefixes to a DHCPv6 server using DHCPv6 Prefix Delegation. The
access router first requests a prefix for an incoming mobile node
from the DHCPv6 server. The access router may next do stateless or
stateful address allocation to the mobile node, e.g. with a Router
Advertisement or using DHCP. We also describe prefix management
using Authentication Authorization and Accounting servers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Sarikaya, et al. Expires August 13, 2012 [Page 1]
Internet-Draft Prefix Delegation February 2012
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . . 4
3. Prefix Delegation Using DHCPv6 . . . . . . . . . . . . . . . . 5
3.1. Prefix Request Procedure for Stateless Address
Configuration . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Prefix Request Procedure for Stateful Address
Configuration . . . . . . . . . . . . . . . . . . . . . . 7
3.3. MN as Requesting Router in Prefix Delegation . . . . . . . 8
3.4. Prefix Release Procedure . . . . . . . . . . . . . . . . . 8
3.5. Miscellaneous Considerations . . . . . . . . . . . . . . . 9
3.5.1. How to Generate IAID . . . . . . . . . . . . . . . . . 9
3.5.2. Policy to Delegate Prefixes . . . . . . . . . . . . . 10
4. Prefix Delegation Using RADIUS and Diameter . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Sarikaya, et al. Expires August 13, 2012 [Page 2]
Internet-Draft Prefix Delegation February 2012
1. Introduction
Figure 1 illustrates the key elements of a typical cellular access
network. In a Long Term Evolution (LTE) network, access router is
the packet data network (PDN) gateway [ThreeGPP23401].
+-------------+
| +------+ |
| |DHCP | |
+-----+ +-----+ +------+ +------+ | |Server| | +------+
| MN |---| BS |---+Access+--+Access+-+ +------+ +-+Border|
+-----+ +-----+ | GW | |Router| |IP Network(s)| |Router+-Internet
+--+---+ +--+---+ | | +------+
| | +-------------+
+-----+ +-----+ | | +------+
| MN |---| BS |------+ | |AAA |
+-----+ +-----+ +--- |Server|
+------+
Figure 1: Key elements of a typical cellular network
Mobile node (MN) attaches to a base station (BS) through LTE air
interface. A BS manages connectivity of UEs and extends connections
to an Access Gateway (GW), e.g. the serving gateway (S-GW) in an LTE
network. The access gateway and the Access Router (AR) are connected
with an IP network. The access router is the first hop router of MNs
and it is in charge of address/prefix management.
Access router is connected to an IP network which is owned by the
operator which is connected to the public Internet via a Border
Router. The network contains servers for subscriber management
including Quality of Service, billing and accounting as well as
Dynamic Host Configuration Protocol (DHCP) server [RFC6342].
As to IPv6 addressing, because mobile network links are point-to-
point (p2p) Per-MN interface prefix model is used [RFC3314],
[RFC3316]. In Per-MN interface prefix model, prefix management is an
issue.
When an MN attaches an AR, the AR requests one or more prefixes for
the MN. When the MN detaches the AR, the prefixes should be
released. When the MN becomes idle, the AR should hold the prefixes
allocated.
This document describes how to use DHCPv6 Prefix Delegation (PD) in
mobile networks such as networks based on standards developed by the
3rd Generation Partnership Project (3GPP) and it could easily be
adopted to Worldwide Interoperability for Microwave Access (WiMAX)
Sarikaya, et al. Expires August 13, 2012 [Page 3]
Internet-Draft Prefix Delegation February 2012
Forum as well. In view of migration to IPv6, the number of mobile
nodes connected to the network at a given time may become very high.
Traditional techniques such as prefix pools are not scalable. In
such cases DHCPv6 PD becomes the viable approach to take.
The techniques described in this document have not been approved
either by the IETF or by 3GPP, except what is described below in
Section 3.3. This document is not a standard or best current
practice. This document is published only as a possibility for
consideration by operators.
This document is useful when address space needs to be managed by
DHCPv6-PD. There are obviously other means of managing address
space, including having the AR track internally what address space is
used by what mobile.
2. Terminology and Acronyms
3GPP 3rd Generation Partnership Project
AAA Authentication Authorization and Accounting
AR Access Router
BS Base Station
DHCP Dynamic Host Control Protocol
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GPRS General Packet Radio Service
LTE Long Term Evolution
MN Mobile node
PDN Packet data network
PD Prefix Delegation
p2p Point-to-point
Serving Gateway S-GW
WiMAX Worldwide Interoperability for Microwave Access
Sarikaya, et al. Expires August 13, 2012 [Page 4]
Internet-Draft Prefix Delegation February 2012
3. Prefix Delegation Using DHCPv6
Access router refers to the cellular network entity that has DHCP
Client. According to [ThreeGPP23401] DHCP Client is located in PDN
Gateway. So AR is the PDN Gateway in LTE architecture.
3.1. Prefix Request Procedure for Stateless Address Configuration
There are two function modules in the AR, DHCP Client and DHCP Relay.
DHCP messages should be relayed if the AR and a DHCP server are not
connected directly, otherwise DHCP relay function in the AR is not
necessary. Figure 2 illustrates the scenario that the AR and the
DHCP Server aren't connected directly:
+-------+ +----------------------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ |DHCP | Relay | +-----------+
| |Client | Agent | |
| +----------------------+ |
|1 Initial NW Entry | |
|or attach procedure| |
|<----------------->| |
| |2 Solicit |
| |---------> Relay-forward |
| | --------------->|
| | 3 Relay-reply |
| |Advertise <---------------|
| |<-------- |
| |4 Request |
| |---------> Relay-forward |
| | --------------->|
| | 5 Relay-reply |
| |Repl <---------------|
| |<-------- |
|6 Attach | |
| Completed | |
|<----------------->| |
|7 Router | |
| Solicitation | |
|------------------>| |
| 8 Router | |
| Advertisement | |
|<------------------| |
Figure 2: Prefix request
Sarikaya, et al. Expires August 13, 2012 [Page 5]
Internet-Draft Prefix Delegation February 2012
1. An MN (UE=User Equipment in 3GPP) performs initial network entry
and authentication procedures, a.k.a. attach procedure.
2. On successful completion of Step 1, the AR initiates DHCP Solicit
procedure to request prefixes for the MN. The DHCP Client in AR
creates and transmits a Solicit message as described in sections
17.1.1, "Creation of Solicit Messages" and 17.1.2, "Transmission
of Solicit Messages" of [RFC3315]. The DHCP Client in AR that
supports DHCPv6 Prefix Delegation [RFC3633] creates an Identity
Association for Prefix Delegation (IA_PD) and assigns it an
Identity Association IDentifier (IAID). The client must include
the IA_PD option in the Solicit message. DHCP Client as
Requesting Router must set prefix-length field to a value less
than, e.g. 48 or equal to 64 to request a /64 prefix. Next, the
Relay Agent in AR sends Relay-Forward message to the DHCP Server
encapsulating Solicit message.
3. The DHCP server sends an Advertise message to the AR in the same
way as described in section 17.2.2, "Creation and transmission of
Advertise messages" of [RFC3315]. Advertise message with IA_PD
shows that the DHCP server is capable of delegating prefixes.
This message is received encapsulated in Relay-Reply message by
the Relay Agent in AR and sent as Advertise message to the DHCP
Client in AR.
4. The AR (DHCP Client and Relay Agent) uses the same message
exchanges as described in section 18, "DHCP Client-Initiated
Configuration Exchange" of [RFC3315] and [RFC3633] to obtain or
update prefixes from the DHCP server. The AR (DHCP Client and
Relay Agent) and the DHCP server use the IA_PD Prefix option to
exchange information about prefixes in much the same way as IA
Address options are used for assigned addresses. This is
accomplished by the AR sending a DHCP Request message and the
DHCP server sending a DHCP Reply message.
5. AR stores the prefix information it received in the Reply
message.
6. A connection between MN and AR is established and the link
becomes active. This step completes the PDP Context Activation
Procedure in UMTS and PDN connection establishment in LTE
networks.
7. The MN may send a Router Solicitation message to solicit the AR
to send a Router Advertisement message.
8. The AR advertises the prefixes received in IA_PD option to MN
with router advertisement (RA) once the PDP Context/PDN
connection is established or in response to Router Solicitation
message sent from the MN.
4-way exchange between AR as requesting router (RR) and DHCP server
as delegating router (DR) in Figure 2 may be reduced into a two
message exchange using the Rapid Commit option [RFC3315]. DHCP
Client in AR acting as RR includes a Rapid Commit option in the
Sarikaya, et al. Expires August 13, 2012 [Page 6]
Internet-Draft Prefix Delegation February 2012
Solicit message. DR then sends a Reply message containing one or
more prefixes.
3.2. Prefix Request Procedure for Stateful Address Configuration
Stateful address configuration requires a different architecture than
shown in Figure 2. There are two function modules in the AR, DHCP
Server and DHCP Client.
After the initial attach is completed, a connection to the AR is
established for the MN. DHCP Client function at the AR as requesting
router and DHCP server as delegating router follow Steps 2 through 5
of the procedure shown in Figure 2 to get the new prefix for this
interface of MN from IA_PD Option exchange defined in [RFC3633].
DHCPv6 client at the MN sends DHCP Request to AR. DHCP Server
function at the AR must use the IA_PD option received in DHCP PD
exchange to assign an address to MN. IA_PD option must contain the
prefix. AR sends DHCP Reply message to MN containing IA address
option (IAADDR). Figure 3 shows the message sequence.
MN configures its interface with the address assigned by DHCP server
in DHCP Reply message.
In Figure 3 AR may be the home gateway of a fixed network to which MN
gets connected during MN's handover.
Sarikaya, et al. Expires August 13, 2012 [Page 7]
Internet-Draft Prefix Delegation February 2012
+----------+ +--------------+ +-----------+
| MN | | AR | |DHCP Server|
| |DHCP | | DHCP |DHCP | +-----------+
| |Client| |Server|Client |
+----------+ +--------------+
| Initial NW Entry | |
|or attach procedure | |
|<-----------------> | |
| | DHCP PD exchange |
| | similar to Steps 2-5 |
| Solicit | of Figure 2 (IA_PD) |
|---------------------->| |
| Advertise | |
|<----------------------| |
| Request | |
|---------------------->| |
| | |
| | |
| | use prefix in IA_PD |
| Reply | to assign IAADDR |
|<--------------------- | |
Figure 3: Stateful Address Configuration Following PD
3.3. MN as Requesting Router in Prefix Delegation
AR may use DHCPv6 prefix delegation exchange to get a delegated
prefix shorter than /64 by setting prefix-length field to a value
less than 64, e.g. 56 to get a /56 prefix. Each newly attaching MN
first goes through the steps in Figure 2 in which AR requests a
shorter prefix to establish a default connection with the MN.
MN may next request additional prefixes (/64 or shorter) from the AR
using DHCPv6 prefix delegation where MN is the requesting router and
AR is the delegating router [RFC6459], Section 5.3.1.2.6 in
[ThreeGPP23401]. In this case the call flow is similar to Figure 3.
Solicit message must include the IA_PD option with prefix-length
field set to 64. MN may request more than one /64 prefixes. AR as
delegating router must delegate these prefixes excluding the prefix
assigned to the default connection.
3.4. Prefix Release Procedure
Prefixes can be released in two ways, prefix aging or DHCP release
procedure. In the former way, a prefix should not be used by an MN
when the prefix ages, and the DHCP Server can delegate it to another
MN. A prefix lifetime is delivered from the DHCPv6 server to the MN
Sarikaya, et al. Expires August 13, 2012 [Page 8]
Internet-Draft Prefix Delegation February 2012
through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information
option [RFC4861]. Figure 4 illustrates how the AR releases prefixes
to a DHCP Server which isn't connected directly:
1. An MN detachment signaling, such as switch-off or handover,
triggers prefix release procedure.
2. The AR initiates a Release message to give back the prefixes to
the DHCP server.
3. The server responds with a Reply message, and then the prefixes
can be reused by other MNs.
+-------+ +-------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ +-------+ +-----------+
| | |
| 1 De-registration | |
| Handover, or others | |
|<--------------------->| |
| |2 Relay-forward/Release|
| |---------------------->|
| | |
| |3 Relay-reply/Reply |
| |<--------------------- |
| | |
| | |
Figure 4: Prefix Release
3.5. Miscellaneous Considerations
3.5.1. How to Generate IAID
IAID is 4 bytes in length and should be unique in an AR scope.
Prefix table should be maintained. Prefix table contains IAID, MAC
address and the prefix(es) assigned to MN. In LTE networks,
International Mobile station Equipment Identity (IMEI) uniquely
identifies MN's interface and thus corresponds to the MAC address.
MAC address of the interface should be stored in the prefix table and
this field is used as the key for searching the table.
IAID should be set to Start_IAID, an integer of 4 octets. The
following IAID generation algorithm is used:
1. Set this IAID value in IA_PD Prefix Option. Request prefix for
this MN as in Section 3.1 or Section 3.2.
2. Store IAID, MAC address and the prefix(es) received in the next
entry of the prefix table.
Sarikaya, et al. Expires August 13, 2012 [Page 9]
Internet-Draft Prefix Delegation February 2012
3. Increment IAID.
Prefix table entry for an MN that hands over to another AR must be
removed. IAID value is released to be reused.
3.5.2. Policy to Delegate Prefixes
In point-to-point links, if /64 prefixes of all the MNs connected to
one or more ARs are broadcast dynamically upstream as the route
information this causes high routing protocol traffic (IGP, OSPF,
etc.) due to Per-MN interface prefixes. There are two solutions this
problem. One is to use static configuration, which would be
preferable in many cases. No routing protocols are needed, because
each AR has a known piece of address space. If the DHCP servers know
this space, too, then they will assign from that space to a
particular AR.
The other method is to use route aggregation. For example, each AR
can be assigned a /48 or /32 prefix (aggregate prefix, aka service
provider common prefix) while each interface of MN can be assigned a
/64 prefix. The /64 prefix is an extension of /48 one, for example,
an AR's /48 prefix is 2001:DB8:0::/48, an interface of MN is assigned
2001:DB8:0:2::/64 prefix. The border router (BR) in Figure 1 may be
manually configured to broadcast only individual AR's /48 or /32
prefix information to Internet.
4. Prefix Delegation Using RADIUS and Diameter
In the initial network entry procedure Figure 2, AR as Remote
Authentication Dial In User Service (RADIUS) client sends Access-
Request message with MN information to RADIUS server. If the MN
passes the authentication, the RADIUS server may send Access-Accept
message with prefix information to the AR using Framed-IPv6-Prefix
attribute. AAA server also provides routing information to be
configured for MN on the AR using Framed-IPv6-Route attribute. Using
such a process AR can handle initial prefix assignments to MNs but
managing lifetime of the prefixes is totally left to the AR. Framed-
IPv6-Prefix is not designed to support delegation of IPv6 prefixes.
For this Delegated-IPv6-Prefix attribute can be used which is
discussed next.
[RFC4818] defines a RADIUS attribute Delegated-IPv6-Prefix that
carries an IPv6 prefix to be delegated. This attribute is usable
within either RADIUS or Diameter. [RFC4818] recommends the
delegating router to use AAA server to receive the prefixes to be
delegated using Delegated-IPv6-Prefix attribute/AVP.
Sarikaya, et al. Expires August 13, 2012 [Page 10]
Internet-Draft Prefix Delegation February 2012
DHCP server as the delegating router in Figure 2 may send an Access-
Request packet containing Delegated-IPv6-Prefix attribute to the
RADIUS server to request prefixes. In the Access-Request message,
the delegating router may provide a hint that it would prefer a
prefix, for example, a /48 prefix. As the RADIUS server is not
required to honor the hint, the server may delegate longer prefix,
e.g. /56 or /64 in an Access-Accept message containing Delegated-
IPv6-Prefix attribute [RFC4818]. The attribute can appear multiple
times when RADIUS server delegates multiple prefixes to the
delegating router. The delegating router sends the prefixes to the
requesting router using IA_PD Option and AR as RR uses them for MN's
as described in Section 3.
When Diameter is used, DHCP server as the delegating router in
Figure 2 sends AA-Request message. AA-Request message may contain
Delegated-IPv6-Prefix AVP. Diameter server replies with AA-Answer
message. AA-Answer message may contain Delegated-IPv6-Prefix AVP.
The AVP can appear multiple times when Diameter server assigns
multiple prefixes to MN. The Delegated-IPv6-Prefix AVP may appear in
an AA-Request packet as a hint by the AR to the Diameter server that
it would prefer a prefix, for example, a /48 prefix. Diameter server
may delegate in an AA-Answer message with a /64 prefix which is an
extension of the /48 prefix. As in the case of RADIUS, the
delegating router sends the prefixes to the requesting router using
IA_PD Option and AR as RR uses them for MN's as described in
Section 3.
5. Security Considerations
This draft introduces no additional messages. Comparing to
[RFC3633], [RFC2865] and [RFC3588] there is no additional threats to
be introduced. DHCPv6, RADIUS and Diameter security procedures
apply.
6. IANA Considerations
None.
7. Acknowledgements
We are grateful to Suresh Krishnan, Hemant Singh, Qiang Zhao, Ole
Troan, Qin Wu, Jouni Korhonen, Cameron Byrne, Brian Carpenter, Jari
Arkko and Jason Lin who provided in depth reviews of this document
that have led to several improvements.
Sarikaya, et al. Expires August 13, 2012 [Page 11]
Internet-Draft Prefix Delegation February 2012
8. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
Wiljakka, "Internet Protocol Version 6 (IPv6) for Some
Second and Third Generation Cellular Hosts", RFC 3316,
April 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6
Deployment", RFC 6342, August 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.
[ThreeGPP23401]
"3GPP TS 23.401 V11.0.0, General Packet Radio Service
(GPRS) enhancements for Evolved Universal Terrestrial
Radio Access Network (E-UTRAN) access (Release 11).",
Sarikaya, et al. Expires August 13, 2012 [Page 12]
Internet-Draft Prefix Delegation February 2012
2011.
Authors' Addresses
Behcet Sarikaya
Huawei USA
5340 Legacy Dr.
Plano, TX 75074
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Ted Lemon
Nominum
2000 Seaport Blvd
Redwood City, CA 94063
Phone:
Email: mellon@nominum.com
Sarikaya, et al. Expires August 13, 2012 [Page 13]
