Network Working Group S. Krishnan
Internet-Draft F. Garneij
Intended status: Standards Track Ericsson
Expires: August 28, 2010 J. Korhonen
Nokia Siemens Networks
T. Savolainen
Nokia
February 24, 2010
Prefix Delegation in Evolved Packet Core networks
draft-krishnan-intarea-pd-epc-00
Abstract
This document describes the operation of IPv6 prefix delegation in
the 3GPP evolved packet core networks. It also identifies a
deficiency in the current prefix delegation mechanism and proposes a
fix.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 28, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Krishnan, et al. Expires August 28, 2010 [Page 1]
Internet-Draft Prefix Delegation in EPC February 2010
This document is subject to BCP 78 and the IETF Trust's Legal
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 BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Optimizing prefix delegation . . . . . . . . . . . . . . . . . 3
4. PCC impacts . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. DHCPv6 Prefix delegation problem . . . . . . . . . . . . . . . 6
5.1. Problem description and solution proposal . . . . . . . . . 6
5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Krishnan, et al. Expires August 28, 2010 [Page 2]
Internet-Draft Prefix Delegation in EPC February 2010
1. Requirements notation
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 [RFC2119].
2. Introduction
In the current evolved packet core (EPC) networks every User
Equipment (UE) is allocated a /64 prefix as described in
[I-D.korhonen-v6ops-3gpp-eps] and similarly for the General Packet
Radio Services (GPRS) in [RFC3314]. If the UE needs to act as a
router and support a network behind it, it requires a shorter prefix
to be delegated to it. To support this, the EPC network can reserve
a shorter prefix (e.g. a /56) for the UE even before the UE requests
delegation of a prefix.
3. Optimizing prefix delegation
A carefully planned prefix delegation model can help with minimizing
the impact on the routing and policy control infrastructures.
Irrespective of the length of the shorter prefix or the method used
for delegation, it is preferable that the initial /64 assigned to the
UE be a part of the shorter prefix intended to be delegated to the
UE.
4. PCC impacts
The Policy & Charging Control Architecture (PCC) provides network
control regarding the service data flow detection, gating & QoS
towards the PCEF (Policy Control Enforcement Function) and the BBERF
(Bearer Binding and Event Reporting Function). In addition PCC also
provides network control of flow based charging towards the PCEF.
The main objective of PCC is to interconnect the signaling plane with
the data plane to provide policy, QoS control and charging. To
achieve this interconnection PCC performs session binding as
described in [3GPP.23.203] Section 6.1.1.2. Session binding requires
a match between the AF session (Rx signalling interface) and IP-CAN
session [3GPP.32.251] parameters. For an IPv6 session the IP-CAN
parameter containing the UE IPv6 prefix is the DIAMETER Framed-IPv6-
Prefix AVP defined in [RFC4005]. An IP-CAN Session can only contain
one Framed-IPv6-Prefix AVP. [RFC3162] defines the following coding
of the Framed-IPv6-Prefix AVP:
Krishnan, et al. Expires August 28, 2010 [Page 3]
Internet-Draft Prefix Delegation in EPC February 2010
Framed-IPv6-Prefix
Description
This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept
packets, and can appear multiple times. It MAY be used in an
Access-Request packet as a hint by the NAS to the server that it
would prefer these prefix(es), but the server is not required to
honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same
prefix.
A summary of the Framed-IPv6-Prefix Attribute format is shown
below. The fields are transmitted from left to right.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
97 for Framed-IPv6-Prefix
Length
At least 4 and no larger than 20.
Reserved
This field, which is reserved and MUST be present, is always
set to zero.
Prefix-Length
The length of the prefix, in bits. At least 0 and no larger
than 128.
Krishnan, et al. Expires August 28, 2010 [Page 4]
Internet-Draft Prefix Delegation in EPC February 2010
Prefix
The Prefix field is up to 16 octets in length. Bits outside
of the Prefix-Length, if included, must be zero.
Framed-IPv6-Prefix
Looking at this definition it can be recognized that if the original
Prefix-Length value, contained here after a initial UE PDN Connection
is established, may be changed to a shorter prefix if obtained by the
UE using prefix delegation mechanism. If the original IPv6 prefix is
part of the shorter delegated IPv6 prefix as described below example,
updating the Prefix-Length field in the Framed-IPv6-Prefix AVP would
allow for successful session binding for all addresses contained
within the delegated prefix.
A 2001:db8:4000:FF00::/56 delegation example:
o UE request IPv6 prefix using existing 3GPP defined procedures
o As an exception from existing mechanisms there is a reservation
for a /56 IPv6 prefix for the requesting UE, possibly configured
per Access Point Name (APN) for the subscriber. However, this
step does not change the existing PDN Connection setup signaling
o SLAAC returns "the last/highest" or "the first/lowest" /64 IPv6
prefix of the reserved prefix using existing 3GPP defined
procedures (e.g. 2001:db8:4000:FFFF::/64)
o Extend initial 2001:db8:4000:FFFF::/64 to 2001:db8:4000:FF00:/56
by using DHCPv6 PD
o GW perform IP-CAN session modification
o UE uplink subnet is kept as the initial received prefix 2001:db8:
4000:FFFF::/64
o Available /64 interface subnets 2001:db8:4000:FF00-FFFE::/64
o First available subnet for UE downlink interfaces 2001:db8:4000:
FF00::/64
o Last available subnet for UE downlink interfaces 2001:db8:4000:
FFFE::/64
If the IP-CAN session Framed-IPv6-Prefix AVP Length field is modified
to represent a shorter prefix (from 64 to 56) a match can be made to
all /64 that are included in the shorter prefix including the UE
Krishnan, et al. Expires August 28, 2010 [Page 5]
Internet-Draft Prefix Delegation in EPC February 2010
initial /64 received using existing 3GPP defined procedures.
Impact on PCC would be minimal if the following applies:
o Keep current restrictions on only one IPv4 address and only one
IPv6 prefix for a single connection (PDP Context/PDN Connection)
o Allow a shorter prefix length for a single connection (PDP
Context/PDN Connection)
o Add possibility to adjust prefix length within a connection
5. DHCPv6 Prefix delegation problem
5.1. Problem description and solution proposal
The IPv6 Prefix Options for DHCPv6 document [RFC3633] specifies a
mechanism for using DHCPv6 for delegating prefixes from a delegating
router to a requesting router. This mechanism is very well suited
for use in EPC networks but it has a restriction that limits its
usage. Section 12.1 of [RFC3633] contains the following text "..the
requesting router MUST NOT assign any delegated prefixes or subnets
from the delegated prefix(es) to the link through which it received
the DHCP message from the delegating router." that does not allow the
UE to use a /64 out of the delegated prefix on the interface where it
received the delegation. This restriction means that two different
prefixes need to be allocated for each UE (one /64 and one shorter)
and this causes a significant impact on the routing and policy
infrastructures. This draft recommends that this restriction be
removed for UEs in EPC networks.
5.2. Discussion
Although the solution for the DHCPv6 prefix delegation problem is
only scoped to cover 3GPP EPC networks, there are still concerns
whether the solution is fully backward compatible with all possible
deployment models. There are concerns that network identifying UE's
EPC readiness is not sufficient. Especially the model where the 3GPP
capable UE is only acting as a 'bridge-like' modem, for example, for
a notebook where the host IP stack is running. The actual prefix
delegation request originates from the notebook IP stack. This
particular deployment model has to be verified whether it can be
deployed without breaking IP and existing stack implementations that
also understand prefix delegation.
Krishnan, et al. Expires August 28, 2010 [Page 6]
Internet-Draft Prefix Delegation in EPC February 2010
6. IANA Considerations
This document does not require any IANA action.
7. Security Considerations
The be defined in later revision of this specification.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
8.2. Informative References
[3GPP.23.203]
3GPP, "Policy and charging control architecture", 3GPP
TS 23.203 7.12.0, December 2009.
[3GPP.32.251]
3GPP, "Telecommunication management; Charging management;
Packet Switched (PS) domain charging", 3GPP TS 32.251
6.10.0, June 2007.
[I-D.korhonen-v6ops-3gpp-eps]
Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3GPP Evolved Packet
System", draft-korhonen-v6ops-3gpp-eps-00 (work in
progress), February 2010.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
Krishnan, et al. Expires August 28, 2010 [Page 7]
Internet-Draft Prefix Delegation in EPC February 2010
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Fredrik Garneij
Ericsson
Email: fredrik.garneij@ericsson.com
Jouni Korhonen
Nokia Siemens Networks
Email: jouni.nospam@gmail.com
Teemu Savolainen
Nokia
Email: teemu.savolainen@nokia.com
Krishnan, et al. Expires August 28, 2010 [Page 8]