NETEXT Working Group Y. Tu Internet-Draft ZTE Intended status: Standards Track December 31, 2012 Expires: July 4, 2013 MN IP Capability for Wifi-EPC Integration draft-tu-netext-mn-ip-capability-00 Abstract WiFi is beginning to be considered as a trusted non-3GPP access network which can provide the service of accessing to the EPC core network to the user. And EAP/AKA(and EAP/AKA') is specified as the access authentication protocol in this case. This document defines a new EAP attribute to provide the mobile node IPv4/IPv6/IPv4v6 capability to the network so that mobile node IP address/prefix assignment and PMIP session establishment can be processed accordingly. 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 July 4, 2013. Copyright Notice Copyright (c) 2012 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 Tu Expires July 4, 2013 [Page 1] Internet-Draft MN IP Capability for Wifi-EPC Integration December 2012 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. MN IP Capability for Wifi-EPC Integration . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Attribute Extensions . . . . . . . . . . . . . . . . . . . 4 3.2.1. AT_IP_CAPABILITY . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Tu Expires July 4, 2013 [Page 2] Internet-Draft MN IP Capability for Wifi-EPC Integration December 2012 1. Introduction The 3GPP networks support multiple PDN connections, and the PDN type of these connections can be IPv4 or IPv6 or IPv4v6. When the mobile node attaches to the 3GPP networks or requests to establish a new PDN connection, it will request for a specific PDN type based on its IP stack configuration, and the MME compares the requested PDN type to the PDN type in the subscription records stored in the HSS and sets the PDN type accordingly. For a specific PDN connection, the MN IP address/prefix assignment and session establishment should be based on this final PDN type. When the mobile node accesses to the 3GPP network by WiFi which works as a trusted non-3GPP access technology, the final PDN type also should be set according to the PDN type of Mobile node requested and stored in the subscription records. However, these is no existing way for the mobile node to carry PDN type or MN IP stack capability information to the Wifi access network. This document defines a new EAP attribute, the MN IP Capability, that can be used by the mobile node for carrying information to the wifi access network about the MN IP capability, which can be used for IP address/prefix assignment and session(e.g. PMIP or GTP) establishment. 2. Conventions used in this document 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]. 3. MN IP Capability for Wifi-EPC Integration 3.1. Overview EAP AKA(and EAP AKA') is always used as the access authentication protocol in the case of WiFi-EPC integration. The information carried in the payload of EAP protocol between the mobile node and network elements, such as HO indication or APN, can be used to trigger the PMIP or GTP session establishment. Mobile node IP capability has very tight relationship with the type of PMIP or GTP session that the MN requests to establish.If the MN IP capability is IPv4 or IPv6, then the mobile node only allow to request for a IPv4 or IPv6 PMIP/GTP session establishment even if the PDN type in the subscription records is IPv4v6, and only IPv4 address or IPv6 prefix can be assigned to the mobile node. And if the MN IP Tu Expires July 4, 2013 [Page 3] Internet-Draft MN IP Capability for Wifi-EPC Integration December 2012 capability is IPv4v6, the mobile node shall request for a IPv4v6 PMIP/GTP session establishment, then if the PDN type in the subscription records is allowed to be IPv4v6, both IPv4 address and IPv6 prefix can be assigned to this mobile node when the IPv4v6 type PMIP/GTP session is established. This draft makes use of the EAP Authentication procedure to carry the MN IP capability from the mobile node to the network elements, which can be used for IP address/prefix assignment and session(e.g. PMIP or GTP) establishment. 3.2. Attribute Extensions 3.2.1. AT_IP_CAPABILITY A new EAP attribute, called AT_IP_CAPABILITY, is defined to be included in any of the EAP Request messages that are integrity protected, such as the EAP-Response/AKA-Challenge. This attribute is used for conveying the mobile node's IP stack capability information. Its format is the following: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_IP | Length | MN IP Capability | | _CAPABILITY | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: AT_IP_CAPABILITY Attribute MN IP Capability MN IP capability shall have one of the following values: 0: Reserved 1: IPv4 2: IPv6 3: IPv4v6 Tu Expires July 4, 2013 [Page 4] Internet-Draft MN IP Capability for Wifi-EPC Integration December 2012 4. Security Considerations TBD 5. IANA Considerations TBD 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, May 2009. Author's Address Yangwei Tu ZTE Nanjing Nanjing China Email: tu.yangwei@zte.com.cn Tu Expires July 4, 2013 [Page 5]