v6ops Working Group Y. Cui Internet-Draft Q. Sun Intended status: Standards Track Tsinghua University Expires: August 17, 2014 February 13, 2014 Lightweight 4over6 for LTE Networks draft-cui-v6ops-lte-lw4over6-00 Abstract Operators of Long Term Evolution (LTE) networks have been suffering from IPv4 address shortages and are forced to migrate to IPv6. Many operators prefer to build new LTE networks based on IPv6. However, at present there are still a lot of IPv4-only mobile terminals. A large number of high-quality applications are also in the IPv4-only Internet. There exist needs from IPv4 users to access IPv4 Internet across an IPv6-only LTE network. This document describes a tunneling mechanism that enables the IPv4 users to connect to the IPv4 Internet through an IPv6-only LTE network. Port-restricted public IPv4 addresses are assigned to eNodeBs to remove the NAT functionality on the PGW, which helps to offload the processing burden of PGW. The eNodeB is extended to allocate private IPv4 addresses to UEs, as well as the private- public IPv4 address translation. 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 August 17, 2014. Copyright Notice Copyright (c) 2014 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 Cui & Sun Expires August 17, 2014 [Page 1] Internet-Draft lw4over6 for LTE February 2014 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 5. IP Address Configuration on eNodeB . . . . . . . . . . . . . 4 6. The Modification of Nodes . . . . . . . . . . . . . . . . . . 5 7. The GTP Tunnel Usage . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Contributors List . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Long Term Evolution (LTE) is a standard for wireless communication based on 3GPP technologies, providing high-speed data transmission for mobile terminals. LTE's long-term goal is to simplify and redesign network architecture, making it an IP network, which helps reduce the potential adverse factors in the transformation of 3G. "Always online" is one of the goals of LTE system. The so-called "always online" does not mean that each section of connection or bearer between UE and the Evolved Packet Core (EPC) network exists at any time. When a UE registers to the network, the network will save the user's UE context. When we initiate the connection to the UE at any time, the network can depend on the context to find the UE and establish a connection in a short period of time. In the scenario that this document describes, IPv4 users access IPv4 Internet through IPv6 LTE network. A number of architectural solutions have been discussed in the IETF to make whole network migrate to IPv6 smoothly. Many A+P-like solutions, including Lightweight 4over6 [I-D.ietf-softwire-lw4over6], have been proposed. In this document, we extend Lightweight 4over6 in the LTE network environment to transition the whole LTE architecture to IPv6: Cui & Sun Expires August 17, 2014 [Page 2] Internet-Draft lw4over6 for LTE February 2014 allocating IPv4 address + port to eNodeB, using existing LTE GTP tunnel and completing the encapsulation and decapsulation in eNodeB and PGW. Because the LTE network is an All-IP network, eNodeB, SGW and PGW have IP network layer. So that we can extend those nodes to move the function of IPv4 address allocation to UE from the PGW to the eNodeB. The eNodeB assigns private IPv4 addresses to UEs. The PGW allocates public IPv4 address and port-set to the eNodeB. When a UE sends IPv4 packets to the Internet, the private IPv4 address will be translated to public IPv4 address at the eNodeB. The packets are then transported to the PGW after GTP tunnel encapsulation. We maintain the mapping between IPv4 address plus port-set and the IPv6 address of eNodeB on the PGW. IPv4 packets from the Internet can find the correct eNodeBs by looking up this mapping table, guaranteeing the bidirectional exchange between UEs and the Internet. 2. Requirements Language 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. Terminology This document makes use of the following terms: UE: A User Equipment is a host with the ability to obtain Internet connectivity via a 3GPP network. eNodeB: Evolved NodeB, base station name in LTE, features include: RRM function, IP header compression, user data stream encryption, MME choice in UE attach, etc. SGW: Serving Gateway is a gateway in the EPS, which terminates the interface towards the E-UTRAN. The SGW is the Mobility Anchor point for layer-2 mobility (inter-eNodeB handovers). For each UE connected to the EPS, at any given point in time, there is only one SGW. PGW: Packet Data Network Gateway is the SGi interface that terminates outside data network such as the Internet, IMS, etc. It is responsible for managing the data routing between 3GPP and non- 3GPP, and the mobility between 3GPP access and non-3GPP access (such as WLAN, WiMAX). It is Cui & Sun Expires August 17, 2014 [Page 3] Internet-Draft lw4over6 for LTE February 2014 also responsible for DHCP, strategy implementation, billing, etc. GTP: GPRS Tunnelling Protocol is a tunnelling protocol defined by 3GPP. It is a network-based mobility protocol and is similar to Proxy Mobile IPv6 (PMIPv6) [RFC5213]. GTP also provides functionality beyond mobility, such as in-band signaling related to Quality of Service (QoS) and charging, etc. 4. Architecture Overview In this LTE network architecture, eNodeB and UE communicate by air interface Uu, SGW communicates with eNodeB and PGW respectively through S1 interface and S5 / S8 interface. Wireless networks under SGW use P2P, the network between SGW and PGW uses IP, which is managed by operators. PGW, as a gateway, connects the IP networks of operators and the Internet. The architecture described here addresses a typical use case, where an eNodeB's uplink supports IPv6 only and a UE using IPv4 in this eNodeB wants to access IPv4 Internet. The network architecture is shown in Figure 1. In this scenario, the UE can only use the IPv6 network to access IPv4 services, so IPv4 services must be configured over IPv6. +--------+ | IP | S1-MME +-------+ S11 |Services| +----|----| MME |----|----+ +--------+ | | | | |SGi | +-------+ | S5/ | +----+ Uu +-------+ S1-U +-------+ S8 +-------+ | UE |----|---|eNodeB |---|-----------------| SGW |-----|-----|PDN-GW | | v4 | |v4 A+P |------v6 network-----| |v6 network | | +----+ |-------|=========GTP=========|-------|===GTP=====|-------| Figure 1: LTE Architecture 5. IP Address Configuration on eNodeB The IPv6 network is deployed between eNodeB and PGW. The eNodeB needs to get port-restricted public IPv4 addresses across IPv6 network. Currently, there are two ways to assign IPv4 addresses across IPv6 network, one is DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and the other is the Softwire DHCP Cui & Sun Expires August 17, 2014 [Page 4] Internet-Draft lw4over6 for LTE February 2014 option [I-D.ietf-softwire-map-dhcp]. DHCPv4 over DHCPv6 describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Softwire DHCP option defines DHCPv6 options to carry IPv4 address and port-set. After obtaining an IPv6 address, eNodeB can request public IPv4 address and port-set from the PGW through DHCPv4-over-DHCPv6. eNodeB, as DHCP 4o6 client, puts DHCPv4 message in a DHCPv6 option named DHCPv4 Message Option, and finds correct SGW to forward to PGW; PGW, as the DHCP 4o6 server, extracts the DHCPv4 message from the DHCPv4 Message Option and deals with the requests. After processing, PGW will forward DHCPv6 message that encapsulates a DHCPv4 message to eNodeB. Two new DHCPv6 messages carrying DHCPv4 messages between the client and the server is defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. DHCPv4-query is used by client to request IPv4 configuration parameters from the server, while DHCPv4-response is used to respond to the request of client. Figure 2 shows this address configuration procedure. +---------------+ +---------------+ | eNodeB | | PGW | |DHCP 4o6 Client| |DHCP 4o6 Server| +---------------+ +---------------+ | | |DHCPv4 discover | DHCPv4-QUERY | DHCPv4 discover | | |------------------>| | |DHCPv4 Advertise| DHCPv4-RESPONSE | DHCPv4 Advertise| | |<------------------| | |DHCPv4 Request | DHCPv4-QUERY | DHCPv4 Request | | |------------------>| | |DHCPv4 Reply | DHCPv4-RESPONSE | DHCPv4 Reply | | |<------------------| | Figure 2: eNodeB IPv4 configuration 6. The Modification of Nodes When new eNodeB supporting this feature enters the network, it can obtain IPv6 address by Stateless Address Auto Configuration(SLAAC), and then apply for public IPv4 address and port set. Now there exists a mapping between bearer and IP address on PGW, an IP address corresponds to a kind of bearer, and the bearer is identified by GTP Tunnel Endpoint ID (TEID). Each UE's IP packet needs to be transported by the corresponding bearer. Each eNodeB has only a port-restricted IPv4 address and an IPv6 address. When a package Cui & Sun Expires August 17, 2014 [Page 5] Internet-Draft lw4over6 for LTE February 2014 from the IPv4 Internet forwarded to UE wants to find the right eNodeB, it needs to identify IPv6 addresses of eNodeB and the bearer according to the IPv4 destination address and port. PGW needs to modify their original mapping table from between IPv4 address and bearer to among IPv4 address plus port-set, IPv6 address and the bearer to determine the correct transmission path. In this mechanism, the function of IPv4 address allocation to UE is moved from PGW to eNodeB. Once UE enters a LTE network, it will initiate attach procedure to request relational configuration. In EPS bearer establishment process, PGW will send a Create bearer response message to UE, which have a null IP segment. After receiving it, eNodeB allocates a private IPv4 address and fills it in the null IP segment to build full message and then sends to UE. When completing this process, UE gets IPv4 address and other configuration parameters. This procedure can be shown in Figure 3. The benefits of this mechanism are maintaining UE's original configuration process, enabling UE to have no sense of address configuration changes. +----+ Insert a IPv4 +-------+ Create bearer response msg +-------+ | | address in msg | | (have null IP segment) | | | UE |<---------------|eNodeB |<---------------------------|PDN-GW | | | | | | | +----+ |-------| +-------+ Figure 3: UE Address Configuration 7. The GTP Tunnel Usage Data transmission between PGW and eNodeB uses GTP tunnel, which is encapsulated with IPv6. When a UE initiates access to the Internet, eNodeB translates private IPv4 addresses to appropriate public IPv4 addresses and port-set, and transports packets through the GTP tunnel to PGW for forwarding to the Internet. When IP packets coming from the Internet send to a UE, PGW forwards packets via GTP tunnel to correct eNodeB by looking up the mapping table (IPv4 address, port set, IPv6 address, TEID). The eNodeB performs NAT function and sends IP packets to UE through the air interface Uu, which completes the two-way communications. This is quite similar to that in the Lightweight 4over6, which uses IPv4-in-IPv6 tunnel. The difference is the encapsulation structure is IP-GTP-IP. The mechanism this document describes is a combination of GTP encapsulation and Lightweight 4over6 (the IPv4 package is encapsulated with GTP and then is encapsulated with IPv6), conforming the need of IPv6 transition in LTE. Cui & Sun Expires August 17, 2014 [Page 6] Internet-Draft lw4over6 for LTE February 2014 8. Security Considerations Section 9 of Lightweight 4over6 [I-D.ietf-softwire-lw4over6] applies to this memo. 9. IANA Considerations This memo does not include an IANA request. 10. Contributors List Many thanks to Yuqi Wang and Yan Zhang for their great contributions to the draft. 11. References 11.1. Normative References [I-D.ietf-softwire-lw4over6] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS- Lite Architecture", draft-ietf-softwire-lw4over6-06 (work in progress), February 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 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. 11.2. Informative References [I-D.ietf-dhc-dhcpv4-over-dhcpv6] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- dhcpv4-over-dhcpv6-04 (work in progress), January 2014. [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., Dec, W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients", draft-ietf-softwire-map-dhcp-06 (work in progress), November 2013. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Cui & Sun Expires August 17, 2014 [Page 7] Internet-Draft lw4over6 for LTE February 2014 Authors' Addresses Yong Cui Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Qi Sun Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: sunqi@csnet1.cs.tsinghua.edu.cn Cui & Sun Expires August 17, 2014 [Page 8]