dhc G. Liu Internet-Draft ZTE Corporation Intended status: Standards Track September 29, 2011 Expires: April 1, 2012 HO from 3GPP to a trusted non-3GPP access draft-liu-dhc-ho-00.txt Abstract This document defines a new option that can be used by DHCP clients to send to DHCP servers. This new option includes some sub-options. It also defines standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged. It may be used for scenarios interworking with non-3GPP and 3GPP network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 1, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Liu Expires April 1, 2012 [Page 1] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Convention & Terminology . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. DHCPv4 Requirement . . . . . . . . . . . . . . . . . . . . 7 3.2. DHCPv6 Requirement . . . . . . . . . . . . . . . . . . . . 8 4. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. DHCPv4 Protocol . . . . . . . . . . . . . . . . . . . . . 10 4.2. DHCPv6 Protocol . . . . . . . . . . . . . . . . . . . . . 10 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 11 5.1. DHCPv4 Protocol . . . . . . . . . . . . . . . . . . . . . 11 5.2. DHCPv6 Protocol . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Liu Expires April 1, 2012 [Page 2] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 1. Introduction In 3GPP TS 23.402, 3GPP EPS supports the use of non-3GPP IP access networks to access the EPC, and also supports handover between 3GPP and non-3GPP access. This document describes DHCP client and server behavior in a scenario for handover from 3GPP to a trusted non-3GPP access. Liu Expires April 1, 2012 [Page 3] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 2. Convention & Terminology 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 [RFC 2119]. The terminology in this document is based on the definitions in [RFC2131,RFC3315], in addition to the ones specified in this section 3GPP 3rd Generation Partnership Project TS Technical Specification EPC Evolved Packet Core EPS Evolved Packet System APN Access Point Name PDN Packet Data Network GTP GPRS Tunnelling Protocol PMIP Proxy Mobile IP PDN GW PDN Gateway Liu Expires April 1, 2012 [Page 4] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 3. Problem Statement During handover from 3GPP to a non-3GPP access, UE IP address allocated by 3GPP network needs be reused after handover to non-3GPP access in order to keep UE service continuous. For non-3GPP access, it needs to know UE capability for the IP address preservation, and in 3GPP TS 23.402, the information can be gotten from IKEv2 authentication procedure for untrusted non-3GPP access, however, a method how the trusted non-3GPP access get UE capability for the IP address preservation isn't described explicitly shown as follows. Liu Expires April 1, 2012 [Page 5] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 +---------+ +------------------+ +--------+ +------------+ | UE | | Trusted Non-3GPP| | PDN GW | | HSS/AAA | | | | IP Access | +--------+ +------------+ +---------+ +------------------+ | | | | | | | 1. 3GPP Access Procedure | | |/--------------------------------------------------------\| |\--------------------------------------------------------/| --------------------- | | | | 2. UE discovers | | | | | Trusted Non-3GPP | | | | | Access and | | | | | initiates HO | | | | --------------------- | | | |3.Access Authentication 3.Authentication&Authorization | |/-------------------\|/--------------------|-------------\| |\-------------------/|\--------------------|-------------/| | | | | --------------------------- | | | 4.L3 Attach Trigger | | | | | | | --------------------------- | | | |5.PBU/Create Session Request | | |-------------------->| 6. Update PDN GW Address | | |<------------>| | |7.PBA/Create Session Response | | |<--------------------| | | | | | --------------------------- | | | 8.L3 Attach Completion | | | | | | | --------------------------- | | | | | | | 9. UE-initiated additional PDN Connection | |/--------------------------------------------------------\| |\--------------------------------------------------------/| | 10. 3GPP EPS Bearer Release | | |/-----------------------------------------\| | |\-----------------------------------------/| | Figure 1: Handover from 3GPP to a non-3GPP access From above figure, the step 4 is involved for the problem, the description is as follows.Step 4: After successful authentication and authorization, the L3 attach procedure is triggered. At the latest, in this step, the UE should indicate its capability for the IP address preservation. How this information is signalled from the UE Liu Expires April 1, 2012 [Page 6] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 to the access network is outside of the scope of 3GPP. From step 4 description, it is considered that the capability for the IP address preservation must be transferred to Trusted Non-3GPP IP Access in step 4, if this information hasn!_t been transferred before step 4. For the capability for the IP address preservation, it indicates UE need to reuse the previously assigned address. Currently, DHCP message, especially for IPv4 type, is considered of preferred method for triggering Trusted Non-3GPP IP Access to access 3GPP EPC, and UE is integrated with DHCP client and trusted non-3GPP access is integrated with DHCP server. And then, DHCP messages need to support to transfer UE capability for the IP address preservation from UE to Trusted Non-3GPP IP Access. 3.1. DHCPv4 Requirement In RFC2131 section 3.2, there are procedures for Client-server interaction - reusing a previously allocated network address, in the procedures shown as follow figure, DHCP client in INIT-REBOOT state sends DHCPREQUEST message to DHCP server, where 'requested IP address' option must be filled in with client's notion of its previously assigned address, 'ciaddr' MUST be zero and 'server identifier' MUST NOT be filled in, and the server will return DHCP ACK message to the client. Liu Expires April 1, 2012 [Page 7] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 Server Client Server v v v | | | | Begins | | initialization | | | | | /|\ | | _________ __/ | \__________ | | /DHCPREQU EST | DHCPREQUEST\ | |/ | \| | | | Locates | Locates configuration | configuration | | | |\ | /| | \ | ___________/ | | \ | / DHCPACK | | \ _______ |/ | | DHCPACK\ | | | Initialization | | complete | | \| | | | | | (Subsequent | | DHCPACKS | | ignored) | | | | | | | v v v Figure 2: procedures for reusing a previously allocated network address If above procedure is applied for the scenario of handover from 3GPP to a trusted non-3GPP access, DHCP server can implicitly get the capability for the IP address preservation by detecting the parameters in received DHCPREQUEST message. But the requirement for DHCP client and DHCP server behavior in this specific scenario isn!_t included in RFC2131 and needs to be described in more detailed than one of RFC2131. 3.2. DHCPv6 Requirement In RFC3315, there is following description associated with handover scenario, for example, in any situation when a client may have moved to a new link, the client must initiate a Confirm/Reply message Liu Expires April 1, 2012 [Page 8] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 exchange. The client includes any IAs assigned to the interface that may have moved to a new link, along with the addresses associated with those IAs, in its Confirm message. in its Any responding servers will indicate whether those addresses are appropriate for the link to which the client is attached with the status in the Reply message it returns to the client. If confirm message is applied for the scenario of handover from 3GPP to a trusted non-3GPP access, DHCP server can implicitly get the capability for the IP address preservation if receiving confirm message and get previously allocated IP address from confirm message. But the requirement for DHCP client and DHCP server behavior in this specific scenario isn!_t included in RFC3315 and needs to be described in more detailed than one of RFC3315. This document is intended to describe DHCP client and server behavior in specific scenario for handover from 3GPP to a trusted non-3GPP access. Liu Expires April 1, 2012 [Page 9] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 4. DHCP Client Behavior 4.1. DHCPv4 Protocol When UE decides to handover from 3GPP to a non-3GPP access, UE will notify DHCP client move to INIT-REBOOT state, and DHCP client sends DHCPREQUEST message to DHCP Server, and the included parameters refer to the description for 'DHCPREQUEST generated during INIT-REBOOT state' in RFC2131 section 4.3.2. Subsequently, the client receives the DHCPACK message with configuration parameters. The client performs a final check on the parameters and notes the duration of the lease specified in the DHCPACK message, more detailed description refer to 'DHCPREQUEST generated during INIT-REBOOT state' in RFC2131. 4.2. DHCPv6 Protocol When UE decides to handover from 3GPP to a non-3GPP access, UE will notify DHCP client to send confirm message to DHCP Server, and the included parameters refer to the description for 'Creation and Transmission of Confirm Messages' in RFC3315 section18.1.2. Subsequently, the client receives the Reply message with configuration parameters. The client SHOULD perform duplicate address detection on each of the addresses in any IAs it receives in the Reply message before using that address for traffic, more detailed description refer to 'Receipt of Reply Messages' in RFC3315 section 18.1.8. Liu Expires April 1, 2012 [Page 10] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 5. DHCP Server Behavior 5.1. DHCPv4 Protocol WDHCP server receives DHCPREQUEST message from DHCP client and deal with the message, if the 'server identifier' isn!_t be filled in, 'requested IP address' option is filled in with client's notion of its previously assigned address. 'ciaddr' is zero, which corresponds to the requirements of 'DHCPREQUEST generated during INIT-REBOOT state' in RFC2131, then DHCP server will notify trusted non-3GPP access to send PMIP or GTP message to 3GPP PDN GW, which includes handover indication for reusing a previously allocated network address. Subsequently, when trusted non-3GPP access receives the response message from PDN GW, it will notify DHCP server to respond with a DHCPACK message to the client, whose format and requirement refer to the description for 'Table 3: Fields and options used by DHCP servers' in RFC2131. 5.2. DHCPv6 Protocol DHCP server receives confirm message from DHCP client and deal with the message, if the parameters match the requirements of 'Receipt of Confirm Messages' in RFC3315 section 18.2.2, then DHCP server will notify trusted non-3GPP access to send PMIP or GTP message to 3GPP PDN GW, which includes handover indication for reusing a previously allocated network address. Subsequently, when trusted non-3GPP access receives the response message from PDN GW, it will notify DHCP server to respond with a Reply message to the client, whose format and requirement refer to the description for 'Transmission of Reply Messages' in RFC3315 section18.2.8. Liu Expires April 1, 2012 [Page 11] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 6. Security Considerations Security considerations in DHCPv4 are described in [RFC3118]. Security considerations in DHCPv6 are described in [RFC3315]. Liu Expires April 1, 2012 [Page 12] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 7. IANA Considerations This document does not introduce any new namespaces for the IANA to manage and does not request any new code point assignments. Liu Expires April 1, 2012 [Page 13] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 2011. Liu Expires April 1, 2012 [Page 14] Internet-Draft HO from 3GPP to trusted non-3GPP access September 2011 Author's Address Guoyan Liu ZTE Corporation No.68 Zijinghua Avenue, Yuhuatai District Nanjing China Phone: +86-25-5287-1362 Email: liu.guoyan@zte.com.cn Liu Expires April 1, 2012 [Page 15]