idnits 2.17.1 draft-krishnan-intarea-pd-epc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2010) is 5146 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-korhonen-v6ops-3gpp-eps-00 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft F. Garneij 4 Intended status: Standards Track Ericsson 5 Expires: August 28, 2010 J. Korhonen 6 Nokia Siemens Networks 7 T. Savolainen 8 Nokia 9 February 24, 2010 11 Prefix Delegation in Evolved Packet Core networks 12 draft-krishnan-intarea-pd-epc-00 14 Abstract 16 This document describes the operation of IPv6 prefix delegation in 17 the 3GPP evolved packet core networks. It also identifies a 18 deficiency in the current prefix delegation mechanism and proposes a 19 fix. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 28, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Optimizing prefix delegation . . . . . . . . . . . . . . . . . 3 64 4. PCC impacts . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 5. DHCPv6 Prefix delegation problem . . . . . . . . . . . . . . . 6 66 5.1. Problem description and solution proposal . . . . . . . . . 6 67 5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Requirements notation 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 In the current evolved packet core (EPC) networks every User 84 Equipment (UE) is allocated a /64 prefix as described in 85 [I-D.korhonen-v6ops-3gpp-eps] and similarly for the General Packet 86 Radio Services (GPRS) in [RFC3314]. If the UE needs to act as a 87 router and support a network behind it, it requires a shorter prefix 88 to be delegated to it. To support this, the EPC network can reserve 89 a shorter prefix (e.g. a /56) for the UE even before the UE requests 90 delegation of a prefix. 92 3. Optimizing prefix delegation 94 A carefully planned prefix delegation model can help with minimizing 95 the impact on the routing and policy control infrastructures. 96 Irrespective of the length of the shorter prefix or the method used 97 for delegation, it is preferable that the initial /64 assigned to the 98 UE be a part of the shorter prefix intended to be delegated to the 99 UE. 101 4. PCC impacts 103 The Policy & Charging Control Architecture (PCC) provides network 104 control regarding the service data flow detection, gating & QoS 105 towards the PCEF (Policy Control Enforcement Function) and the BBERF 106 (Bearer Binding and Event Reporting Function). In addition PCC also 107 provides network control of flow based charging towards the PCEF. 108 The main objective of PCC is to interconnect the signaling plane with 109 the data plane to provide policy, QoS control and charging. To 110 achieve this interconnection PCC performs session binding as 111 described in [3GPP.23.203] Section 6.1.1.2. Session binding requires 112 a match between the AF session (Rx signalling interface) and IP-CAN 113 session [3GPP.32.251] parameters. For an IPv6 session the IP-CAN 114 parameter containing the UE IPv6 prefix is the DIAMETER Framed-IPv6- 115 Prefix AVP defined in [RFC4005]. An IP-CAN Session can only contain 116 one Framed-IPv6-Prefix AVP. [RFC3162] defines the following coding 117 of the Framed-IPv6-Prefix AVP: 119 Framed-IPv6-Prefix 121 Description 123 This Attribute indicates an IPv6 prefix (and corresponding route) 124 to be configured for the user. It MAY be used in Access-Accept 125 packets, and can appear multiple times. It MAY be used in an 126 Access-Request packet as a hint by the NAS to the server that it 127 would prefer these prefix(es), but the server is not required to 128 honor the hint. Since it is assumed that the NAS will plumb a 129 route corresponding to the prefix, it is not necessary for the 130 server to also send a Framed-IPv6-Route attribute for the same 131 prefix. 133 A summary of the Framed-IPv6-Prefix Attribute format is shown 134 below. The fields are transmitted from left to right. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type | Length | Reserved | Prefix-Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Prefix 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Prefix 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Prefix 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Prefix | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Type 152 97 for Framed-IPv6-Prefix 154 Length 156 At least 4 and no larger than 20. 158 Reserved 160 This field, which is reserved and MUST be present, is always 161 set to zero. 163 Prefix-Length 165 The length of the prefix, in bits. At least 0 and no larger 166 than 128. 168 Prefix 170 The Prefix field is up to 16 octets in length. Bits outside 171 of the Prefix-Length, if included, must be zero. 173 Framed-IPv6-Prefix 175 Looking at this definition it can be recognized that if the original 176 Prefix-Length value, contained here after a initial UE PDN Connection 177 is established, may be changed to a shorter prefix if obtained by the 178 UE using prefix delegation mechanism. If the original IPv6 prefix is 179 part of the shorter delegated IPv6 prefix as described below example, 180 updating the Prefix-Length field in the Framed-IPv6-Prefix AVP would 181 allow for successful session binding for all addresses contained 182 within the delegated prefix. 184 A 2001:db8:4000:FF00::/56 delegation example: 186 o UE request IPv6 prefix using existing 3GPP defined procedures 188 o As an exception from existing mechanisms there is a reservation 189 for a /56 IPv6 prefix for the requesting UE, possibly configured 190 per Access Point Name (APN) for the subscriber. However, this 191 step does not change the existing PDN Connection setup signaling 193 o SLAAC returns "the last/highest" or "the first/lowest" /64 IPv6 194 prefix of the reserved prefix using existing 3GPP defined 195 procedures (e.g. 2001:db8:4000:FFFF::/64) 197 o Extend initial 2001:db8:4000:FFFF::/64 to 2001:db8:4000:FF00:/56 198 by using DHCPv6 PD 200 o GW perform IP-CAN session modification 202 o UE uplink subnet is kept as the initial received prefix 2001:db8: 203 4000:FFFF::/64 205 o Available /64 interface subnets 2001:db8:4000:FF00-FFFE::/64 207 o First available subnet for UE downlink interfaces 2001:db8:4000: 208 FF00::/64 210 o Last available subnet for UE downlink interfaces 2001:db8:4000: 211 FFFE::/64 213 If the IP-CAN session Framed-IPv6-Prefix AVP Length field is modified 214 to represent a shorter prefix (from 64 to 56) a match can be made to 215 all /64 that are included in the shorter prefix including the UE 216 initial /64 received using existing 3GPP defined procedures. 218 Impact on PCC would be minimal if the following applies: 220 o Keep current restrictions on only one IPv4 address and only one 221 IPv6 prefix for a single connection (PDP Context/PDN Connection) 223 o Allow a shorter prefix length for a single connection (PDP 224 Context/PDN Connection) 226 o Add possibility to adjust prefix length within a connection 228 5. DHCPv6 Prefix delegation problem 230 5.1. Problem description and solution proposal 232 The IPv6 Prefix Options for DHCPv6 document [RFC3633] specifies a 233 mechanism for using DHCPv6 for delegating prefixes from a delegating 234 router to a requesting router. This mechanism is very well suited 235 for use in EPC networks but it has a restriction that limits its 236 usage. Section 12.1 of [RFC3633] contains the following text "..the 237 requesting router MUST NOT assign any delegated prefixes or subnets 238 from the delegated prefix(es) to the link through which it received 239 the DHCP message from the delegating router." that does not allow the 240 UE to use a /64 out of the delegated prefix on the interface where it 241 received the delegation. This restriction means that two different 242 prefixes need to be allocated for each UE (one /64 and one shorter) 243 and this causes a significant impact on the routing and policy 244 infrastructures. This draft recommends that this restriction be 245 removed for UEs in EPC networks. 247 5.2. Discussion 249 Although the solution for the DHCPv6 prefix delegation problem is 250 only scoped to cover 3GPP EPC networks, there are still concerns 251 whether the solution is fully backward compatible with all possible 252 deployment models. There are concerns that network identifying UE's 253 EPC readiness is not sufficient. Especially the model where the 3GPP 254 capable UE is only acting as a 'bridge-like' modem, for example, for 255 a notebook where the host IP stack is running. The actual prefix 256 delegation request originates from the notebook IP stack. This 257 particular deployment model has to be verified whether it can be 258 deployed without breaking IP and existing stack implementations that 259 also understand prefix delegation. 261 6. IANA Considerations 263 This document does not require any IANA action. 265 7. Security Considerations 267 The be defined in later revision of this specification. 269 8. References 271 8.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 277 Host Configuration Protocol (DHCP) version 6", RFC 3633, 278 December 2003. 280 8.2. Informative References 282 [3GPP.23.203] 283 3GPP, "Policy and charging control architecture", 3GPP 284 TS 23.203 7.12.0, December 2009. 286 [3GPP.32.251] 287 3GPP, "Telecommunication management; Charging management; 288 Packet Switched (PS) domain charging", 3GPP TS 32.251 289 6.10.0, June 2007. 291 [I-D.korhonen-v6ops-3gpp-eps] 292 Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 293 Bajko, G., and K. Iisakkila, "IPv6 in 3GPP Evolved Packet 294 System", draft-korhonen-v6ops-3gpp-eps-00 (work in 295 progress), February 2010. 297 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 298 RFC 3162, August 2001. 300 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 301 Generation Partnership Project (3GPP) Standards", 302 RFC 3314, September 2002. 304 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 305 "Diameter Network Access Server Application", RFC 4005, 306 August 2005. 308 Authors' Addresses 310 Suresh Krishnan 311 Ericsson 312 8400 Decarie Blvd. 313 Town of Mount Royal, QC 314 Canada 316 Phone: +1 514 345 7900 x42871 317 Email: suresh.krishnan@ericsson.com 319 Fredrik Garneij 320 Ericsson 322 Email: fredrik.garneij@ericsson.com 324 Jouni Korhonen 325 Nokia Siemens Networks 327 Email: jouni.nospam@gmail.com 329 Teemu Savolainen 330 Nokia 332 Email: teemu.savolainen@nokia.com