idnits 2.17.1 draft-liu-dhc-3gpp-option-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 63 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2013) is 4063 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) == Missing Reference: 'RFC 2119' is mentioned on line 85, but not defined == Missing Reference: 'RFC4301' is mentioned on line 109, but not defined == Missing Reference: 'RFC 5555' is mentioned on line 109, but not defined == Missing Reference: 'RFC5213' is mentioned on line 310, but not defined == Missing Reference: 'RFC3118' is mentioned on line 316, but not defined == Unused Reference: 'RFC2119' is defined on line 327, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. 'TS23401' -- Possible downref: Non-RFC (?) normative reference: ref. 'TS23402' -- Possible downref: Non-RFC (?) normative reference: ref. 'TS24008' Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc G. Liu 3 Internet-Draft Y. Tu 4 Intended status: Standards Track C. Zhu 5 Expires: September 12, 2013 ZTE Corporation 6 W. Hendericks 7 D. Derksen 8 L. Thiebaut 9 Alcatel-Lucent 10 March 11, 2013 12 DHCP Options for 3GPP Service 13 draft-liu-dhc-3gpp-option-03.txt 15 Abstract 17 This document defines a new option that can be used by DHCP clients 18 in their signaling sent to DHCP servers, when those clients need to 19 associate a request for an IP address or IPv6 prefix with a given 20 3GPP packet service.It is intended for scenarios of interworking 21 between a non-3GPP access and a 3GPP network. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 12, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Convention & Terminology . . . . . . . . . . . . . . . . . . . 4 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 60 4. 3GPP-Service Option Format . . . . . . . . . . . . . . . . . . 6 61 4.1. APN Sub-option Format . . . . . . . . . . . . . . . . . . 7 62 4.2. Non Seamless WLAN Offload 63 (3GPP-Service-Type)Sub-option Format . . . . . . . . . . . 7 64 5. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 10 65 6. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 11 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 The Dynamic Host Configuration Protocol (DHCP) is built on a client- 74 server model, where designated DHCP server allocate network addresses 75 and deliver configuration parameters to dynamically configured hosts. 76 The changes to [RFC2131][RFC3315] defined in this document defines 77 the use of 3GPP specific option transferred to DHCP server by DHCP 78 client. 80 2. Convention & Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC 2119]. 86 The terminology in this document is based on the definitions in 87 [RFC2131][RFC3315], in addition to the ones specified in this section 89 3GPP 3rd Generation Partnership Project 91 TS Technical Specification 93 EPC Evolved Packet Core 95 APN Access Point Name 97 PDN Packet Data Network 99 GTP GPRS Tunnelling Protocol 101 PMIP Proxy Mobile IP 103 3. Problem Statement 105 In 3GPP TS 23.402, 3GPP UE can access the 3GPP EPC through non-3GPP 106 IP access. 108 When the non 3GPP access is Trusted, there is no need for the 3GPP UE 109 to establish a Layer 3 tunnel (IPSec [RFC4301], DSMIPv6 [RFC 5555]) 110 to access the EPC as it can rely upon the non 3GPP access security 111 mechanisms. In this case, the 3GPP UE may send DHCP signaling to non 112 3GPP access to acquire an IP address. However, the 3GPP UE may wish 113 to associate its request for an IP address with IP services provided 114 by the 3GPP EPC or may conversely explicitly require that its traffic 115 is not sent to the EPC but offloaded, even though the UE has been 116 authenticated via its 3GPP credentials (the service is called "NSO" 117 i.e. Non Seamless Offload). 119 The APN (Access Point Name) is the parameter by which a 3GPP UE 120 signals the kind of EPC service it desires. Based on the value of 121 this parameter, a 3GPP IP Edge (a PDN GW) is selected and the PDN GW 122 is able to determine the IP features to deliver to the traffic 123 exchanged by the UE as part of this APN. 125 It should be noted that the set of IP configuration parameters that 126 the UE may receive via a DHCP response (e.g. the DNS server(s) 127 address) may also be influenced by the value of the APN. 129 Thus when requesting an IP address via DHCP, a 3GPP UE should be able 130 to indicate: 132 o Whether this IP address is for NSO or whether it is for an EPC 133 service. 135 o If the IP address is for an EPC service, the value of the APN 136 corresponding to the IP services reached when using this IP address. 137 The UE may also request an EPC service without providing an APN 138 value; in this case, the network uses a default APN value. 140 Such DHCP request may be sent when the UE requests access to EPC via 141 non 3GPP access, or when the UE performs mobility from a 3GPP access 142 to a non 3GPP access. 144 This document is intended to define a new DHCP option for "3GPP 145 Service". 147 4. 3GPP-Service Option Format 149 A DHCP client within a 3GPP based device sets the "3GPP-Service" 150 Option in the DHCP request it sends to the network to indicate the 151 desired 3GPP service associated with that request. 153 A DHCP server willing to indicate it has taken into account the 154 parameters / sub-options of a "3GPP-Service" Option included by the 155 client in a DHCP request mirrors these parameters in the DHCP 156 signaling it sends back to the client. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | 3GPP-SERVICE | option-length | sub-options... 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: 3GPP Service Option Format for DHCPv4 166 option-code 3GPP-Service (TBD) 167 option-len The number of octets in the option, minimum 1. 168 Sub-options The "3GPP-Service" Option may contain one or more Sub-options further defined in this document 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | 3GPP-SERVICE | option-length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | sub-options | - 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 2: 3GPP Service Option Format for DHCPv6 180 option-code 3GPP-Service (TBD) 181 option-len The number of octets in the option, minimum 1. 182 Sub-options The "3GPP-Service" Option may contain one or more Sub-options further defined in this document 184 4.1. APN Sub-option Format 186 The purpose of 3GPP-APN (Access Point Name) Sub-option is sent by UE 187 to network for identifing the packet data network associated with the 188 DHCP message. The APN is defined in 3GPP TS 23.401[TS23401]. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Code | Length | Value 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 3: APN Sub-option Format for DHCPv4 198 Code 3GPP-APN(TBD). 199 Length The number of octets in the option, minimum 1. 200 Value The APN value, as defined in 3GPP TS 24.008 [TS24008] section 10.5.6.1. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Code | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | value | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 4: APN Sub-option Format for DHCPv6 212 Code 3GPP-APN(TBD). 213 Length The number of octets in the option, minimum 1. 214 Value The APN value, as defined in 3GPP TS 24.008 [TS24008] section 10.5.6.1. 216 The 3GPP-APN Sub-option SHOULD only be present once in a DHCP 217 message. If it is present more than once, the value of the last 218 occurrence of the option supersedes the value of the other 219 occurrences of this sub-option. 221 4.2. Non Seamless WLAN Offload (3GPP-Service-Type)Sub-option Format 223 The purpose of 3GPP-Service-Type (Non Seamless Offload) Sub-option is 224 to identify whether the DHCP message is to be associated with a Non 225 Seamless Offload service or with an EPC service. 227 The 3GPP Non Seamless Offload service is defined in 3GPP TS 23.402 228 [TS23402]. 230 0 231 0 1 2 3 4 5 6 7 8 9 232 +-+-+-+-+-+-+-+-+-+-+ 233 | Code |S| V | 234 +-+-+-+-+-+-+-+-+-+-+ 236 Figure 5: 3GPP-Service-Type Sub-option Format for DHCPv4 238 Code 3GPP-Service-Type (TBD). 239 S Bit 4 of octet 1 is spare and shall be coded as zero. 240 V The 3GPP-Service-Type value, the defination is as follows, 241 Bits 0 1 242 0 1 NSO 243 0 0 EPC 244 All other values are reserved. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Code | S | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | V | 252 +-+-+ 254 Figure 6: 3GPP-Service-Type Sub-option Format for DHCPv6 256 Code 3GPP-Service-Type (TBD). 257 S This is spare and shall be coded as zero. 258 V The 3GPP-Service-Type value, the defination of is as follows, 259 Bits 0 1 260 0 1 NSO 261 0 0 EPC 262 All other values are reserved. 264 The presence of the 3GPP-Service-Type Sub-option in a DHCP message 265 indicates whether the DHCP signalling is associated with a NSO 266 service or an EPC service rendered to the UE. 268 The 3GPP-Service-Type Sub-option SHOULD NOT be provided in the same 269 DHCP message than the 3GPP-APN Sub-option, when the 3GPP-Service-Type 270 sub-option includes NSO indication. If present, the 3GPP-APN Sub- 271 option SHOULD be provided in the same DHCP message than the 3GPP- 272 Service-Type Sub-option, when the 3GPP-Service-Type sub-option 273 includes EPC indication. NSO indication and EPC indication are 274 exclusive. 276 If the 3GPP-Service-Type Sub-option includes NSO indication, and if 277 3GPP-APN Sub-option is included, the 3GPP-APN Sub-option is ignored. 279 5. DHCP Client Behavior 281 For DHCPv4 protocol, a DHCP client may include a "3GPP-Service" 282 option in the option payload of DHCPDISCOVER and DHCP REQUEST 283 messages being sent toward a DHCP server in order to associate its 284 request with IP services provided by the 3GPP EPC or to explicitly 285 require that its traffic is not sent to the EPC but offloaded 287 For DHCPv6 protocol, DHCP client may include a "3GPP-Service" option 288 in the option payload of SOLICIT message being sent toward a DHCP 289 server in order to associate its request with IP services provided by 290 the 3GPP EPC or to explicitly require that its traffic is not sent to 291 the EPC but offloaded. 293 If the answer from the DHCP server does not include a "3GPP-Service" 294 option, the DHCP client assumes that the answer is not associated 295 with an EPC service. 297 6. DHCP Server Behavior 299 A DHCP server that receives a "3GPP-Service" option from a DHCP 300 client but does not support this option, MUST ignore this option and 301 MUST NOT provide this option in the signaling it sends back towards 302 the DHCP client. 304 Conversely, when a DHCP server has taken this option into account it 305 MUST provide this option in the signaling it sends back towards the 306 DHCP client. 308 A DHCP server supporting this option SHOULD take the content of this 309 option into account when trying to serve the DHCP client. This may 310 involve making sure relevant signaling (e.g. GTP,PMIP [RFC5213]) is 311 sent to an EPC gateway determined using the parameters of the "3GPP- 312 Service" option. 314 7. Security Considerations 316 Security considerations in DHCPv4 are described in [RFC3118]. 318 Security considerations in DHCPv6 are described in [RFC3315]. 320 8. IANA Considerations 322 IANA is requested to assign one new DHCP option code defined in 323 section 5. 325 9. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 331 RFC 2131, March 1997. 333 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 334 and M. Carney, "Dynamic Host Configuration Protocol for 335 IPv6 (DHCPv6)", RFC 3315, July 2003. 337 [TS23401] 3GPP, "General Packet Radio Service (GPRS) enhancements 338 for Evolved Universal Terrestrial Radio Access Network(E- 339 UTRAN) access", 2011. 341 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 342 2011. 344 [TS24008] 3GPP, "Mobile radio interface Layer 3 specification; Core 345 network protocols", 2010. 347 Authors' Addresses 349 Guoyan Liu 350 ZTE Corporation 351 No.68 Zijinghua Avenue, Yuhuatai District 352 Nanjing 353 China 355 Phone: +86-25-5287-1362 356 Email: liu.guoyan@zte.com.cn 358 Yangwei Tu 359 ZTE Corporation 360 No.68 Zijinghua Avenue, Yuhuatai District 361 Nanjing 362 China 364 Phone: +86-25-5287-1362 365 Email: tu.yangwei@zte.com.cn 367 Chunhui Zhu 368 ZTE Corporation 369 No.68 Zijinghua Avenue, Yuhuatai District 370 Nanjing 371 China 373 Phone: +86-25-5287-4634 374 Email: zhu.chunhui@zte.com.cn 376 Wim Hendericks 377 Alcatel-Lucent 379 Email: Wim.Henderickx@alcatel-lucent.com 381 Daniel Derksen 382 Alcatel-Lucent 384 Email: Daniel.Derksen@alcatel-lucent.com 385 Laurent Thiebaut 386 Alcatel-Lucent 388 Email: laurent.thiebaut@alcatel-lucent.com