idnits 2.17.1 draft-liu-dhc-ho-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 4 instances of too long lines in the document, the longest one being 7 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 (February 16, 2013) is 4087 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 80, 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 == Unused Reference: 'TS23402' is defined on line 337, 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. 'TS23402' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: August 20, 2013 ZTE Corporation 6 February 16, 2013 8 HO from 3GPP to a trusted non-3GPP access 9 draft-liu-dhc-ho-03.txt 11 Abstract 13 This document adds DHCP client and server behavior description in a 14 scenario for handover from 3GPP to a trusted non-3GPP access. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 20, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Convention & Terminology . . . . . . . . . . . . . . . . . . . 4 52 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. DHCPv4 Requirement . . . . . . . . . . . . . . . . . . . . 7 54 3.2. DHCPv6 Requirement . . . . . . . . . . . . . . . . . . . . 8 55 4. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 10 56 4.1. DHCPv4 Protocol . . . . . . . . . . . . . . . . . . . . . 10 57 4.2. DHCPv6 Protocol . . . . . . . . . . . . . . . . . . . . . 10 58 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 11 59 5.1. DHCPv4 Protocol . . . . . . . . . . . . . . . . . . . . . 11 60 5.2. DHCPv6 Protocol . . . . . . . . . . . . . . . . . . . . . 11 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 In 3GPP TS 23.402, 3GPP EPS supports the use of non-3GPP IP access 69 networks to access the EPC, and also supports handover between 3GPP 70 and non-3GPP access. 72 This document describes DHCP client and server behavior in a scenario 73 for handover from 3GPP to a trusted non-3GPP access. 75 2. Convention & Terminology 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 [RFC 2119]. 81 The terminology in this document is based on the definitions in 82 [RFC2131,RFC3315], in addition to the ones specified in this section 84 3GPP 3rd Generation Partnership Project 86 TS Technical Specification 88 EPC Evolved Packet Core 90 EPS Evolved Packet System 92 APN Access Point Name 94 PDN Packet Data Network 96 GTP GPRS Tunnelling Protocol 98 PMIP Proxy Mobile IP 100 PDN GW PDN Gateway 102 3. Problem Statement 104 During handover from 3GPP to a non-3GPP access, UE IP address 105 allocated by 3GPP network needs be reused after handover to non-3GPP 106 access in order to keep UE service continuous. For non-3GPP access, 107 it needs to know UE capability for the IP address preservation, and 108 in 3GPP TS 23.402, the information can be gotten from IKEv2 109 authentication procedure for untrusted non-3GPP access, however, a 110 method how the trusted non-3GPP access get UE capability for the IP 111 address preservation isn't described explicitly shown as follows. 113 +---------+ +------------------+ +--------+ +------------+ 114 | UE | | Trusted Non-3GPP| | PDN GW | | HSS/AAA | 115 | | | IP Access | +--------+ +------------+ 116 +---------+ +------------------+ | | 117 | | | | 118 | 1. 3GPP Access Procedure | | 119 |/--------------------------------------------------------\| 120 |\--------------------------------------------------------/| 121 --------------------- | | | 122 | 2. UE discovers | | | | 123 | Trusted Non-3GPP | | | | 124 | Access and | | | | 125 | initiates HO | | | | 126 --------------------- | | | 127 |3.Access Authentication 3.Authentication&Authorization | 128 |/-------------------\|/--------------------|-------------\| 129 |\-------------------/|\--------------------|-------------/| 130 | | | | 131 --------------------------- | | 132 | 4.L3 Attach Trigger | | | 133 | | | | 134 --------------------------- | | 135 | |5.PBU/Create Session Request | 136 | |-------------------->| 6. Update PDN GW Address 137 | | |<------------>| 138 | |7.PBA/Create Session Response | 139 | |<--------------------| | 140 | | | | 141 --------------------------- | | 142 | 8.L3 Attach Completion | | | 143 | | | | 144 --------------------------- | | 145 | | | | 146 | 9. UE-initiated additional PDN Connection | 147 |/--------------------------------------------------------\| 148 |\--------------------------------------------------------/| 149 | 10. 3GPP EPS Bearer Release | | 150 |/-----------------------------------------\| | 151 |\-----------------------------------------/| | 153 Figure 1: Handover from 3GPP to a non-3GPP access 155 From above figure, the step 4 is involved for the problem, the 156 description is as follows.Step 4: After successful authentication and 157 authorization, the L3 attach procedure is triggered. At the latest, 158 in this step, the UE should indicate its capability for the IP 159 address preservation. How this information is signalled from the UE 160 to the access network is outside of the scope of 3GPP. 162 From step 4 description, it is considered that the capability for the 163 IP address preservation must be transferred to Trusted Non-3GPP IP 164 Access in step 4, if this information hasn!_t been transferred before 165 step 4. For the capability for the IP address preservation, it 166 indicates UE need to reuse the previously assigned address. 168 Currently, DHCP message, especially for IPv4 type, is considered of 169 preferred method for triggering Trusted Non-3GPP IP Access to access 170 3GPP EPC, and UE is integrated with DHCP client and trusted non-3GPP 171 access is integrated with DHCP server. And then, DHCP messages need 172 to support to transfer UE capability for the IP address preservation 173 from UE to Trusted Non-3GPP IP Access. 175 3.1. DHCPv4 Requirement 177 In RFC2131 section 3.2, there are procedures for Client-server 178 interaction - reusing a previously allocated network address, in the 179 procedures shown as follow figure, DHCP client in INIT-REBOOT state 180 sends DHCPREQUEST message to DHCP server, where 'requested IP 181 address' option must be filled in with client's notion of its 182 previously assigned address, 'ciaddr' MUST be zero and 'server 183 identifier' MUST NOT be filled in, and the server will return DHCP 184 ACK message to the client. 186 Server Client Server 188 v v v 189 | | | 190 | Begins | 191 | initialization | 192 | | | 193 | /|\ | 194 | _________ __/ | \__________ | 195 | /DHCPREQU EST | DHCPREQUEST\ | 196 |/ | \| 197 | | | 198 Locates | Locates 199 configuration | configuration 200 | | | 201 |\ | /| 202 | \ | ___________/ | 203 | \ | / DHCPACK | 204 | \ _______ |/ | 205 | DHCPACK\ | | 206 | Initialization | 207 | complete | 208 | \| | 209 | | | 210 | (Subsequent | 211 | DHCPACKS | 212 | ignored) | 213 | | | 214 | | | 215 v v v 217 Figure 2: procedures for reusing a previously allocated network 218 address 220 If above procedure is applied for the scenario of handover from 3GPP 221 to a trusted non-3GPP access, DHCP server can implicitly get the 222 capability for the IP address preservation by detecting the 223 parameters in received DHCPREQUEST message. But the requirement for 224 DHCP client and DHCP server behavior in this specific scenario isn!_t 225 included in RFC2131 and needs to be described in more detailed than 226 one of RFC2131. 228 3.2. DHCPv6 Requirement 230 In RFC3315, there is following description associated with handover 231 scenario, for example, in any situation when a client may have moved 232 to a new link, the client must initiate a Confirm/Reply message 233 exchange. The client includes any IAs assigned to the interface that 234 may have moved to a new link, along with the addresses associated 235 with those IAs, in its Confirm message. in its Any responding servers 236 will indicate whether those addresses are appropriate for the link to 237 which the client is attached with the status in the Reply message it 238 returns to the client. If confirm message is applied for the 239 scenario of handover from 3GPP to a trusted non-3GPP access, DHCP 240 server can implicitly get the capability for the IP address 241 preservation if receiving confirm message and get previously 242 allocated IP address from confirm message. But the requirement for 243 DHCP client and DHCP server behavior in this specific scenario isn!_t 244 included in RFC3315 and needs to be described in more detailed than 245 one of RFC3315. This document is intended to describe DHCP client 246 and server behavior in specific scenario for handover from 3GPP to a 247 trusted non-3GPP access. 249 4. DHCP Client Behavior 251 4.1. DHCPv4 Protocol 253 When UE decides to handover from 3GPP to a non-3GPP access, UE will 254 notify DHCP client move to INIT-REBOOT state, and DHCP client sends 255 DHCPREQUEST message to DHCP Server, and the included parameters refer 256 to the description for 'DHCPREQUEST generated during INIT-REBOOT 257 state' in RFC2131 section 4.3.2. 259 Subsequently, the client receives the DHCPACK message with 260 configuration parameters. The client performs a final check on the 261 parameters and notes the duration of the lease specified in the 262 DHCPACK message, more detailed description refer to 'DHCPREQUEST 263 generated during INIT-REBOOT state' in RFC2131. 265 4.2. DHCPv6 Protocol 267 When UE decides to handover from 3GPP to a non-3GPP access, UE will 268 notify DHCP client to send confirm message to DHCP Server, and the 269 included parameters refer to the description for 'Creation and 270 Transmission of Confirm Messages' in RFC3315 section18.1.2. 272 Subsequently, the client receives the Reply message with 273 configuration parameters. The client SHOULD perform duplicate 274 address detection on each of the addresses in any IAs it receives in 275 the Reply message before using that address for traffic, more 276 detailed description refer to 'Receipt of Reply Messages' in RFC3315 277 section 18.1.8. 279 5. DHCP Server Behavior 281 5.1. DHCPv4 Protocol 283 WDHCP server receives DHCPREQUEST message from DHCP client and deal 284 with the message, if the 'server identifier' isn!_t be filled in, 285 'requested IP address' option is filled in with client's notion of 286 its previously assigned address. 'ciaddr' is zero, which corresponds 287 to the requirements of 'DHCPREQUEST generated during INIT-REBOOT 288 state' in RFC2131, then DHCP server will notify trusted non-3GPP 289 access to send PMIP or GTP message to 3GPP PDN GW, which includes 290 handover indication for reusing a previously allocated network 291 address. 293 Subsequently, when trusted non-3GPP access receives the response 294 message from PDN GW, it will notify DHCP server to respond with a 295 DHCPACK message to the client, whose format and requirement refer to 296 the description for 'Table 3: Fields and options used by DHCP 297 servers' in RFC2131. 299 5.2. DHCPv6 Protocol 301 DHCP server receives confirm message from DHCP client and deal with 302 the message, if the parameters match the requirements of 'Receipt of 303 Confirm Messages' in RFC3315 section 18.2.2, then DHCP server will 304 notify trusted non-3GPP access to send PMIP or GTP message to 3GPP 305 PDN GW, which includes handover indication for reusing a previously 306 allocated network address. 308 Subsequently, when trusted non-3GPP access receives the response 309 message from PDN GW, it will notify DHCP server to respond with a 310 Reply message to the client, whose format and requirement refer to 311 the description for 'Transmission of Reply Messages' in RFC3315 312 section18.2.8. 314 6. Security Considerations 316 Security considerations in DHCPv4 are described in [RFC3118]. 318 Security considerations in DHCPv6 are described in [RFC3315]. 320 7. IANA Considerations 322 This document does not introduce any new namespaces for the IANA to 323 manage and does not request any new code point assignments. 325 8. 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 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 338 2011. 340 Authors' Addresses 342 Guoyan Liu 343 ZTE Corporation 344 No.68 Zijinghua Avenue, Yuhuatai District 345 Nanjing 346 China 348 Phone: +86-25-5287-1362 349 Email: liu.guoyan@zte.com.cn 351 Yangwei Tu 352 ZTE Corporation 353 No.68 Zijinghua Avenue, Yuhuatai District 354 Nanjing 355 China 357 Phone: +86-25-5287-1362 358 Email: tu.yangwei@zte.com.cn 360 Chunhui Zhu 361 ZTE Corporation 362 No.68 Zijinghua Avenue, Yuhuatai District 363 Nanjing 364 China 366 Phone: +86-25-5287-4634 367 Email: zhu.chunhui@zte.com.cn