idnits 2.17.1 draft-cui-v6ops-lte-lw4over6-00.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 9 instances of too long lines in the document, the longest one being 5 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 13, 2014) is 3724 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) == Unused Reference: 'RFC3315' is defined on line 315, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-06 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-04 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group Y. Cui 3 Internet-Draft Q. Sun 4 Intended status: Standards Track Tsinghua University 5 Expires: August 17, 2014 February 13, 2014 7 Lightweight 4over6 for LTE Networks 8 draft-cui-v6ops-lte-lw4over6-00 10 Abstract 12 Operators of Long Term Evolution (LTE) networks have been suffering 13 from IPv4 address shortages and are forced to migrate to IPv6. Many 14 operators prefer to build new LTE networks based on IPv6. However, 15 at present there are still a lot of IPv4-only mobile terminals. A 16 large number of high-quality applications are also in the IPv4-only 17 Internet. There exist needs from IPv4 users to access IPv4 Internet 18 across an IPv6-only LTE network. This document describes a tunneling 19 mechanism that enables the IPv4 users to connect to the IPv4 Internet 20 through an IPv6-only LTE network. Port-restricted public IPv4 21 addresses are assigned to eNodeBs to remove the NAT functionality on 22 the PGW, which helps to offload the processing burden of PGW. The 23 eNodeB is extended to allocate private IPv4 addresses to UEs, as well 24 as the private- public IPv4 address translation. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 17, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 64 5. IP Address Configuration on eNodeB . . . . . . . . . . . . . 4 65 6. The Modification of Nodes . . . . . . . . . . . . . . . . . . 5 66 7. The GTP Tunnel Usage . . . . . . . . . . . . . . . . . . . . 6 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Contributors List . . . . . . . . . . . . . . . . . . . . . . 7 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 11.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Long Term Evolution (LTE) is a standard for wireless communication 78 based on 3GPP technologies, providing high-speed data transmission 79 for mobile terminals. LTE's long-term goal is to simplify and 80 redesign network architecture, making it an IP network, which helps 81 reduce the potential adverse factors in the transformation of 3G. 82 "Always online" is one of the goals of LTE system. The so-called 83 "always online" does not mean that each section of connection or 84 bearer between UE and the Evolved Packet Core (EPC) network exists at 85 any time. When a UE registers to the network, the network will save 86 the user's UE context. When we initiate the connection to the UE at 87 any time, the network can depend on the context to find the UE and 88 establish a connection in a short period of time. 90 In the scenario that this document describes, IPv4 users access IPv4 91 Internet through IPv6 LTE network. A number of architectural 92 solutions have been discussed in the IETF to make whole network 93 migrate to IPv6 smoothly. Many A+P-like solutions, including 94 Lightweight 4over6 [I-D.ietf-softwire-lw4over6], have been proposed. 95 In this document, we extend Lightweight 4over6 in the LTE network 96 environment to transition the whole LTE architecture to IPv6: 98 allocating IPv4 address + port to eNodeB, using existing LTE GTP 99 tunnel and completing the encapsulation and decapsulation in eNodeB 100 and PGW. 102 Because the LTE network is an All-IP network, eNodeB, SGW and PGW 103 have IP network layer. So that we can extend those nodes to move the 104 function of IPv4 address allocation to UE from the PGW to the eNodeB. 105 The eNodeB assigns private IPv4 addresses to UEs. The PGW allocates 106 public IPv4 address and port-set to the eNodeB. When a UE sends IPv4 107 packets to the Internet, the private IPv4 address will be translated 108 to public IPv4 address at the eNodeB. The packets are then 109 transported to the PGW after GTP tunnel encapsulation. We maintain 110 the mapping between IPv4 address plus port-set and the IPv6 address 111 of eNodeB on the PGW. IPv4 packets from the Internet can find the 112 correct eNodeBs by looking up this mapping table, guaranteeing the 113 bidirectional exchange between UEs and the Internet. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Terminology 123 This document makes use of the following terms: 125 UE: A User Equipment is a host with the ability to 126 obtain Internet connectivity via a 3GPP network. 128 eNodeB: Evolved NodeB, base station name in LTE, features 129 include: RRM function, IP header compression, 130 user data stream encryption, MME choice in UE 131 attach, etc. 133 SGW: Serving Gateway is a gateway in the EPS, which 134 terminates the interface towards the E-UTRAN. 135 The SGW is the Mobility Anchor point for layer-2 136 mobility (inter-eNodeB handovers). For each UE 137 connected to the EPS, at any given point in time, 138 there is only one SGW. 140 PGW: Packet Data Network Gateway is the SGi interface 141 that terminates outside data network such as the 142 Internet, IMS, etc. It is responsible for 143 managing the data routing between 3GPP and non- 144 3GPP, and the mobility between 3GPP access and 145 non-3GPP access (such as WLAN, WiMAX). It is 146 also responsible for DHCP, strategy 147 implementation, billing, etc. 149 GTP: GPRS Tunnelling Protocol is a tunnelling protocol 150 defined by 3GPP. It is a network-based mobility 151 protocol and is similar to Proxy Mobile IPv6 152 (PMIPv6) [RFC5213]. GTP also provides 153 functionality beyond mobility, such as in-band 154 signaling related to Quality of Service (QoS) and 155 charging, etc. 157 4. Architecture Overview 159 In this LTE network architecture, eNodeB and UE communicate by air 160 interface Uu, SGW communicates with eNodeB and PGW respectively 161 through S1 interface and S5 / S8 interface. Wireless networks under 162 SGW use P2P, the network between SGW and PGW uses IP, which is 163 managed by operators. PGW, as a gateway, connects the IP networks of 164 operators and the Internet. 166 The architecture described here addresses a typical use case, where 167 an eNodeB's uplink supports IPv6 only and a UE using IPv4 in this 168 eNodeB wants to access IPv4 Internet. The network architecture is 169 shown in Figure 1. In this scenario, the UE can only use the IPv6 170 network to access IPv4 services, so IPv4 services must be configured 171 over IPv6. 173 +--------+ 174 | IP | 175 S1-MME +-------+ S11 |Services| 176 +----|----| MME |----|----+ +--------+ 177 | | | | |SGi 178 | +-------+ | S5/ | 179 +----+ Uu +-------+ S1-U +-------+ S8 +-------+ 180 | UE |----|---|eNodeB |---|-----------------| SGW |-----|-----|PDN-GW | 181 | v4 | |v4 A+P |------v6 network-----| |v6 network | | 182 +----+ |-------|=========GTP=========|-------|===GTP=====|-------| 184 Figure 1: LTE Architecture 186 5. IP Address Configuration on eNodeB 188 The IPv6 network is deployed between eNodeB and PGW. The eNodeB 189 needs to get port-restricted public IPv4 addresses across IPv6 190 network. Currently, there are two ways to assign IPv4 addresses 191 across IPv6 network, one is DHCPv4 over DHCPv6 192 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and the other is the Softwire DHCP 193 option [I-D.ietf-softwire-map-dhcp]. DHCPv4 over DHCPv6 describes a 194 mechanism for obtaining IPv4 configuration information dynamically in 195 IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. 196 Softwire DHCP option defines DHCPv6 options to carry IPv4 address and 197 port-set. 199 After obtaining an IPv6 address, eNodeB can request public IPv4 200 address and port-set from the PGW through DHCPv4-over-DHCPv6. eNodeB, 201 as DHCP 4o6 client, puts DHCPv4 message in a DHCPv6 option named 202 DHCPv4 Message Option, and finds correct SGW to forward to PGW; PGW, 203 as the DHCP 4o6 server, extracts the DHCPv4 message from the DHCPv4 204 Message Option and deals with the requests. After processing, PGW 205 will forward DHCPv6 message that encapsulates a DHCPv4 message to 206 eNodeB. Two new DHCPv6 messages carrying DHCPv4 messages between the 207 client and the server is defined in 208 [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. DHCPv4-query is used by client to 209 request IPv4 configuration parameters from the server, while 210 DHCPv4-response is used to respond to the request of client. 211 Figure 2 shows this address configuration procedure. 213 +---------------+ +---------------+ 214 | eNodeB | | PGW | 215 |DHCP 4o6 Client| |DHCP 4o6 Server| 216 +---------------+ +---------------+ 217 | 218 | 219 |DHCPv4 discover | DHCPv4-QUERY | DHCPv4 discover | 220 | |------------------>| | 221 |DHCPv4 Advertise| DHCPv4-RESPONSE | DHCPv4 Advertise| 222 | |<------------------| | 223 |DHCPv4 Request | DHCPv4-QUERY | DHCPv4 Request | 224 | |------------------>| | 225 |DHCPv4 Reply | DHCPv4-RESPONSE | DHCPv4 Reply | 226 | |<------------------| | 228 Figure 2: eNodeB IPv4 configuration 230 6. The Modification of Nodes 232 When new eNodeB supporting this feature enters the network, it can 233 obtain IPv6 address by Stateless Address Auto Configuration(SLAAC), 234 and then apply for public IPv4 address and port set. Now there 235 exists a mapping between bearer and IP address on PGW, an IP address 236 corresponds to a kind of bearer, and the bearer is identified by GTP 237 Tunnel Endpoint ID (TEID). Each UE's IP packet needs to be 238 transported by the corresponding bearer. Each eNodeB has only a 239 port-restricted IPv4 address and an IPv6 address. When a package 240 from the IPv4 Internet forwarded to UE wants to find the right 241 eNodeB, it needs to identify IPv6 addresses of eNodeB and the bearer 242 according to the IPv4 destination address and port. PGW needs to 243 modify their original mapping table from between IPv4 address and 244 bearer to among IPv4 address plus port-set, IPv6 address and the 245 bearer to determine the correct transmission path. 247 In this mechanism, the function of IPv4 address allocation to UE is 248 moved from PGW to eNodeB. Once UE enters a LTE network, it will 249 initiate attach procedure to request relational configuration. In 250 EPS bearer establishment process, PGW will send a Create bearer 251 response message to UE, which have a null IP segment. After 252 receiving it, eNodeB allocates a private IPv4 address and fills it in 253 the null IP segment to build full message and then sends to UE. When 254 completing this process, UE gets IPv4 address and other configuration 255 parameters. This procedure can be shown in Figure 3. The benefits 256 of this mechanism are maintaining UE's original configuration 257 process, enabling UE to have no sense of address configuration 258 changes. 260 +----+ Insert a IPv4 +-------+ Create bearer response msg +-------+ 261 | | address in msg | | (have null IP segment) | | 262 | UE |<---------------|eNodeB |<---------------------------|PDN-GW | 263 | | | | | | 264 +----+ |-------| +-------+ 266 Figure 3: UE Address Configuration 268 7. The GTP Tunnel Usage 270 Data transmission between PGW and eNodeB uses GTP tunnel, which is 271 encapsulated with IPv6. When a UE initiates access to the Internet, 272 eNodeB translates private IPv4 addresses to appropriate public IPv4 273 addresses and port-set, and transports packets through the GTP tunnel 274 to PGW for forwarding to the Internet. When IP packets coming from 275 the Internet send to a UE, PGW forwards packets via GTP tunnel to 276 correct eNodeB by looking up the mapping table (IPv4 address, port 277 set, IPv6 address, TEID). The eNodeB performs NAT function and sends 278 IP packets to UE through the air interface Uu, which completes the 279 two-way communications. 281 This is quite similar to that in the Lightweight 4over6, which uses 282 IPv4-in-IPv6 tunnel. The difference is the encapsulation structure 283 is IP-GTP-IP. The mechanism this document describes is a combination 284 of GTP encapsulation and Lightweight 4over6 (the IPv4 package is 285 encapsulated with GTP and then is encapsulated with IPv6), conforming 286 the need of IPv6 transition in LTE. 288 8. Security Considerations 290 Section 9 of Lightweight 4over6 [I-D.ietf-softwire-lw4over6] applies 291 to this memo. 293 9. IANA Considerations 295 This memo does not include an IANA request. 297 10. Contributors List 299 Many thanks to Yuqi Wang and Yan Zhang for their great contributions 300 to the draft. 302 11. References 304 11.1. Normative References 306 [I-D.ietf-softwire-lw4over6] 307 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 308 I. Farrer, "Lightweight 4over6: An Extension to the DS- 309 Lite Architecture", draft-ietf-softwire-lw4over6-06 (work 310 in progress), February 2014. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 316 and M. Carney, "Dynamic Host Configuration Protocol for 317 IPv6 (DHCPv6)", RFC 3315, July 2003. 319 11.2. Informative References 321 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 322 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 323 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 324 dhcpv4-over-dhcpv6-04 (work in progress), January 2014. 326 [I-D.ietf-softwire-map-dhcp] 327 Mrugalski, T., Troan, O., Dec, W., Bao, C., 328 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 329 for configuration of Softwire Address and Port Mapped 330 Clients", draft-ietf-softwire-map-dhcp-06 (work in 331 progress), November 2013. 333 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 334 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 336 Authors' Addresses 338 Yong Cui 339 Tsinghua University 340 Beijing 100084 341 P.R.China 343 Phone: +86-10-6260-3059 344 Email: yong@csnet1.cs.tsinghua.edu.cn 346 Qi Sun 347 Tsinghua University 348 Beijing 100084 349 P.R.China 351 Phone: +86-10-6278-5822 352 Email: sunqi@csnet1.cs.tsinghua.edu.cn