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]