idnits 2.17.1 draft-chen-pcp-mobile-deployment-01.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 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 362: '...hus a PCP server SHOULD take care to t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4861' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'I-D.rpcw-pcp-pmipv6-serv-discovery' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 530, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-00 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-03 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-00 ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-03) exists of draft-rpcw-pcp-pmipv6-serv-discovery-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft Z. Cao 4 Intended status: Informational China Mobile 5 Expires: January 17, 2013 M. Boucadair 6 France Telecom 7 A. Vizdal 8 Deutsche Telekom AG 9 L. Thiebaut 10 Alcatel-Lucent 11 July 16, 2012 13 Analysis of Port Control Protocol in Mobile Network 14 draft-chen-pcp-mobile-deployment-01 16 Abstract 18 This memo provides a motivation description for the Port Control 19 Protocol (PCP) deployment in a 3GPP mobile network environment. The 20 document focuses on a mobile network specific issues (e.g. cell phone 21 battery power consumption, keep-alive traffic reduction), PCP 22 applicability to these issues is further studied and analysed. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 17, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Benefits of Introducing PCP in Mobile Network . . . . . . . . 3 60 2.1. Restoring Internet Reachability . . . . . . . . . . . . . 3 61 2.2. Keepalive Message Optimization . . . . . . . . . . . . . . 4 62 2.3. Energy Saving . . . . . . . . . . . . . . . . . . . . . . 4 63 2.4. Balance Resource Assignment . . . . . . . . . . . . . . . 4 64 3. Overviews of PCP Deployment in Mobile Network . . . . . . . . 5 65 4. PCP Server Discovery . . . . . . . . . . . . . . . . . . . . . 5 66 5. MN and multi-homing . . . . . . . . . . . . . . . . . . . . . 7 67 6. Retransmission Consideration . . . . . . . . . . . . . . . . . 7 68 7. Unsolicited Messages Delivery . . . . . . . . . . . . . . . . 8 69 8. SIPTO Architecture . . . . . . . . . . . . . . . . . . . . . . 9 70 9. Authentication Consideration . . . . . . . . . . . . . . . . . 10 71 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 14.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 14.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 The Port Control Protocol[I-D.ietf-pcp-base] allows an IPv6 or IPv4 83 host to control how incoming IPv6 or IPv4 packets are translated and 84 forwarded by a network address translator (NAT) or simple 85 firewall(FW), and also allows a host to optimize its outgoing NAT 86 keepalive messages. A 3rd Generation Partnership Project (3GPP) 87 network can benefit from the use of the PCP service. Traffic in a 88 mobile network is becoming a complex mix of various protocols, 89 different applications and user behaviors. Mobile networks are 90 currently facing several issues such as a frequent keepalive message, 91 terminal battery consumption and etc. In order to mitigate these 92 issues, PCP could be used to improve terminal behaviour by managing 93 how incoming packets are forwarded by upstream devices such as NAT64, 94 NAT44 translators and firewall devices. 96 It should be noticed that mobile network have their particular 97 characteristics. There are several factors that should be 98 investigated before implementing PCP in a mobile context. Without 99 the particular considerations , PCP may not provide desirable 100 outcomes. Some default behaviours may even cause negative impacts or 101 system failures in a mobile environment. Considering very particular 102 environments of mobile networks , it's needed to have a document 103 describing specific concerns from mobile network side. That would 104 also encourage PCP support in mobile network as well. 106 This memo covers PCP-related considerations in a mobile networks. 107 The intension of publishing this memo is to elaborate major issues 108 during the deployment and share the thoughts for a potential usages 109 in mobile networks. Such considerations would provide a pointer to 110 parties interested (e.g. mobile operators) to be included in their UE 111 profile requirements. Some adaptation of PCP protocol might be 112 derived from this document. Such a work would be documented in 113 separated memo(s). 115 2. Benefits of Introducing PCP in Mobile Network 117 2.1. Restoring Internet Reachability 119 Many Mobile networks are making use of a Firewall to protect their 120 customers from an unwanted Internet originated traffic. The firewall 121 is usually configured to reject all unknown inbound connections and 122 only permit inbound traffic that belongs to a connection initiated 123 from the Firewall or NAT/PAT device. There are applications that can 124 be running on the terminal that require to be reachable from the 125 Internet or there could be services running behind the terminal that 126 require reachability from the Internet. PCP enabled applications / 127 devices could request a port or a port range from the Firewall to 128 ensure Internet reachability, and thus would not need to be using 129 keep- alive to keep the Firewall session open. This would result in 130 resource savings on the Firewall node whilst still keeping the 131 customer protected form the unwanted traffic. 133 2.2. Keepalive Message Optimization 135 Many always-on applications, e.g. instant message and p2p 136 applications, are usually keeping long-lived connections with their 137 network peers. To make sure that they can receive incoming traffic 138 from their network peers, they issue periodic keep-alive messages in 139 order to keep the NAT/FW bindings active. As the NAT/FW binding 140 timer may be short and unknown to the UE, the frequency of these 141 keep-alive may be high. These keep-alive generally do not contain 142 useful data and thus correspond to "useless" usage of the radio 143 spectrum and of network resources, e.g.: 145 o Allocation of radio resources to traffic that could be avoided or 146 limited 148 o For each of these keep-alive messages, the UE needs to be put in 149 CONNECTED state, i.e. an operation that consumes a fair amount of 150 signaling 152 PCP helps to reduce the frequency of periodic messages aimed at 153 refreshing a NAT/FW binding by indicating to the mobile the Life time 154 of a binding. PCP helps to avoid different periodic (keep-alive) 155 messages from different applications by allowing the aggregation of 156 binding refresh within one round-trip control message with the 157 NAT/FW. 159 2.3. Energy Saving 161 Devices with low battery resources exist widely in mobile 162 environments, such as mobile terminals, advanced sensors, etc. 163 Mobile terminals often go to "sleep" (IDLE) mode to extend battery 164 life and save air resources. . Host initiated message needs to 165 "wake-up" mobile terminals by changing the state to active. That 166 would cause more energy on such terminals. Testing reports show that 167 energy consumption is dramatically reduced with prolonged sending 168 interval of signalling messages [VTC2007_Energy_Consumption]. 170 2.4. Balance Resource Assignment 172 Network resources have been consumed due to heavy signaling process, 173 like frequent beacon message, retransmission control. Such various 174 usages are significantly increasing the resource consumption on a 175 control plan and decreasing the efficiency on data forwarding (user 176 plane). For example, 16% of traffic caused by instant signalling 177 message would consume 50%~70% radio resource in some area. Since 178 radio access is a resource constrained environment, imbalance of 179 resource assignment would decline Call Setup Success Rate(CSSR) and 180 operational profits. Reduction on control plan load would shift more 181 resources for data transmission, which could contribute the 182 optimization of resource arrangements. 184 3. Overviews of PCP Deployment in Mobile Network 186 The Figure 1 shows the architecture of a mobile network. Radio 187 access network would provide wireless connectivity to the MN. 188 Packets are transmitted through Packet Switch(PS) domain heading to 189 MGW. MGW bear the responsibilities of address allocation, routing 190 and transfer. The connection between MN and MGW normally is a 191 point-to- point link, on which MGW is the default router for MN. 192 NAT/Firewall could either be integrated with MGW or deployed behind 193 MGW as standalone. The traffic is finally destined to application 194 servers, which manage subscriber service. 196 MN Internet 197 | +---------------+ +----------------+ 198 +-+ +-----+ | +--|--+ +-------+ | +----------+ | 199 | | /|/ | RAN |---| PS Network | MGW |---- |NAT/FW |----| |APP Server| | 200 +-+ +-----+ | +--|--+ +-------+ | +----------+ | 201 +---------------+ +----------------+ 202 MN: Mobile Nodes 203 RAN: Radio Access Network 204 PS: Packet Switch 205 MGW:Mobile GateWay 206 NAT/FW: Network Address Translator or Firewall 208 Figure 1: Mobile Networks Scenario 210 A PCP client could be located on MN to control the outbound and 211 inbound traffic on PCP servers. The PCP server is hosted by the 212 NAT/FW respectively. Corresponding to the various behaviours of PCP 213 client, MN would perform PCP operation using MAP, PEER or ANNOUNCE 214 opcodes. A specific application programming interface may be 215 provided to applications. More discussions and recommendations are 216 presented in following sub-sections. 218 4. PCP Server Discovery 220 A straightforward solution seems that MN assume their default router 221 as the PCP Server. However, NAT/FW normally is deployed in a 222 different node than the MGW. Thus there is the need to ensure that 223 MN get information allowing them to discover a PCP server. 225 [I-D.ietf-pcp-dhcp] specified name options in DHCPv4 and DHCPv6 to 226 discover PCP server. It's expected the same mechanism could be used 227 in mobile network. 3GPP network allocates IP address and respective 228 parameter during the PDP (Packet Data Protocol)/PDN(Packet Data 229 Network) context activation phase (PDP and PDN represent terminology 230 in 3G and LTE network respectively ). On the UE, a PDP/PDN context 231 has same meaning which is equivalent to a network interface. 233 It should be noted that the Stateful DHCPv6-based address 234 configuration[RFC3315]is not supported by 3GPP specifications. 3GPP 235 adopts IPv6 Stateless Address Auto-configuration (SLAAC) [RFC4861]to 236 allocate IPv6 address. The UE uses stateless DHCPv6[RFC3736] for 237 additional parameter configuration. The MGW acts as the DHCPv6 238 server. PCP servers discovery could leverage current process to 239 perform the functionalities. The M-bit is set to zero and the O-bit 240 may be set to one in the Router Advertisement (RA) sent to the UE. 241 To carry out PCP sever discovery, a MN should thus send an 242 Information-request message that includes an Option Request Option 243 (ORO) requesting the DHCPv6 PCP Server Name option. 245 Regarding the IPv4 bearer, MN generally indicates that it prefers to 246 obtain an IPv4 address as part of the PDP context activation 247 procedure. In such a case, the MN relies on the network to provide 248 IPv4 parameters as part of the PDP context activation/ PDN connection 249 set-up procedure. The MN may nevertheless indicate that it prefers 250 to obtain the IPv4 address and configuration parameter after the PDP 251 Context activation by DHCPv4, but it is not available on a wide 252 scale[RFC6459]. PCP server name options in DHCPv4 would not help the 253 PCP servers discovery in that case. Alternative ways could be 254 considered to support PCP server discovery by a MN: 256 o Protocol Configuration Options(PCO) based[TS24.008] 258 o DNS based 260 A specific method in 3GPP is to extend PCO information element to 261 transfer a request of PCP server name. However, additional 262 specification efforts are required in 3GPP to make that happen. 264 Another alternative solution is to directly perform an inverse name 265 query in IN-ADDR.ARPA domain[RFC1035]. Normally, MN and NAT/FW would 266 locate in same IPv4 subnet. The MN could easily determine the number 267 of labels associating with IN-ADDR.ARPA to identify a particular 268 zone. For example, 269 UE with IPv4 10.1.0.0/16 could resolve the 1.10.IN-ADDR.ARPA locating 270 PCP servers, the domain database would contain: 272 1.10.IN-ADDR.ARPA. PTR PCP.server.3gppnetwork.org. 274 When it receives a RRs in response, like PCP.server.3gppnetwork.org. 275 The UE could then originate QTYPE=A, QCLASS=IN queries for 276 PCP.server.3gppnetwork.org. to discover the addresses. 278 5. MN and multi-homing 280 As a MN may activate multiple PDP context / PDN connection, it may be 281 multi-homed (the UE receives at least an IP address / an IPv6 prefix 282 per PDN connection). Different MGW are likely to be associated with 283 each of these PDP context / PDN connection and may thus advertise 284 different PCP servers (using the mechanism described in the previous 285 section). In that case, a MN has to be able to manage multiple PCP 286 servers and to associate an IP flow with the PCP server corresponding 287 to the PDP context / PDN connection used to carry that IP flow. 289 6. Retransmission Consideration 291 PCP designed retransmission mechanisms on the client for reliable 292 delivery of PCP request. The client must retransmit request message 293 until successfully receiving response or determining failure. 294 Several timers were specified to control the retransmission behavior. 295 Configurable timers of Maximum Retransmission Duration(MRD) gives an 296 opportunity to optimize the behavior fitting into different 297 environments. 299 A class of devices in mobile networks are usually powered with 300 limited battery . Users would like to use such MN for several days 301 without charging, even several weeks in sensor case. Many 302 applications do not send or receive traffic constantly; instead, the 303 network interface is idle most of the time. That could help to save 304 energy unless there is data leading the link to be activated. Such 305 state changes is based on network-specific timer values corresponding 306 to a number of Radio Resource Control (RRC) states(see more at 307 Section 8.2.2 3GPP[TS23.060]. The time transiting to idle is 308 normally less than default Maximum Retransmission Time (MRT), i.e. 309 1024 seconds. With "no maximum" of MRD, would cause devices 310 activating their uplink radio in order to retransmit the request 311 messages. Furthermore, the state transition and the transmission 312 take some time, which causes significant power consumption. The MRD 313 should be configured with an optimal time which in line with 314 activated state duration on the device. That could help to avoid 315 frequent wake-up the device and consume the battery. 317 The power consumption problem is made complicated if several PCP 318 clients residing on a MN. Several clients are potentially sending 319 requests at random times and by so doing causing MN uplink radio into 320 a significantly power consuming state for unnecessarily often. It's 321 necessary to perform a synchronization process for tidy up several 322 PCP clients retransmission. A time-line observer is required to 323 control different PCP clients resending requests in an optimal 324 transmission window. If the uplink radio of MN is active at the time 325 of sending retransmission from several clients, a proper MRD 326 described as above should be set for the clients. If the uplink 327 radio of MN is in idle mode, the time-line observer should hold 328 Initial Retransmission Time(IRT) for while to synchronize different 329 retransmitted PCP requests into same optimal transmission window. 330 Such duration of optimal transmission window should equal with RRC 331 state timer on the MN. The holding timer in idle mode may be set as 332 100 seconds as recommended in 333 [I-D.savolainen-6man-optimal-transmission-window]. Several PCP 334 clients should wait a random amount of time between 0 and 100 335 milliseconds to prevent synchronization of all PCP clients. 337 7. Unsolicited Messages Delivery 339 When the states on NAT/FW have been changed like reboot or changed 340 configuration, PCP servers can send unsolicited messages (e.g. 341 ANNOUNCE Operation )to clients informing them of the new state of 342 their mappings. This aims at achieving rapid detection of PCP 343 failure and rapid PCP recovery. However, it may induce difficulties 344 in mobile environments. 346 Multicast delivery may not be available in 3GPP network, because it 347 optionally supports IP Multicast routing of packets. When multicast 348 delivery is not possible, PCP servers may use unicast delivery of 349 ANNOUNCE noting that 351 o This requires PCP servers to retain knowledge of the IP 352 address(es) and port(s) of their clients even though they have 353 rebooted 355 o Care should be taken not to generate floods of unicast ANNOUNCE 356 messages, e.g. to multiple thousands of MN that were served by a 357 PCP server that has rebooted. Such flood may have a detrimental 358 impact on Mobile Networks as it may imply the simultaneous 359 generation of Paging process(see more at Section 8.2.4 360 3GPP[TS23.060]) for very big numbers of MN. 362 Thus a PCP server SHOULD take care to throttle unicast ANNOUNCE 363 messages it sends towards a collection of MN. 365 Furthermore, such paging function is optionally supported at some 366 particular nodes, e.g. Traffic Offload Function (TOF) in Selected IP 367 Traffic Offload architecture (more discussions on this issues is 368 described in Section 7). The delivery of unsolicited messages would 369 fail in this case. 371 8. SIPTO Architecture 373 Since Release 10, 3GPP starts supporting of Selected IP Traffic 374 Offload (SIPTO) function defined in [TS23.060], [TS23.401].The SIPTO 375 function allows an operator to offload certain types of traffic at a 376 network node close to the UE's point of attachment to the access 377 network. It can be achieved by selecting a set of MGWs that is 378 geographically/topologically close to a UE's point of attachment. 379 Two variants of solutions has specified in 3GPP. 381 The mainstream standard deployment relies on selecting a MGW that is 382 / are geographically/ topologically close to a UE's point of 383 attachment. This deployment may apply to both 3G and LTE. The MN 384 may sometimes be requested to re-activate its PDP context / PDN 385 connection, in which case it is allocated a new MGW and thus a new IP 386 address and a new PCP server. In this case SIPTO has no detrimental 387 impact on PCP as SIPTO resolves to a change of MGW and of PCP server. 389 As an implementation option dedicated to 3G networks, it is also 390 possible to carry out Selected IP Traffic Offload in a TOF entity 391 located at the interface of the Radio Access Network i.e. in the path 392 between the Radio stations and the Mobile Gateway. The TOF decides 393 on which traffic to offload and enforces NAT for that traffic. The 394 point is that the deployment of a TOF is totally transparent for the 395 UE that even cannot know which traffic is subject to TOF (NATed at 396 the TOF) and which traffic is processed by the MGW (and the FW/NAT 397 controlled by the PCP server whose address has been determined per 398 mechanisms described in section 5 of this document). In case of TOF 399 deployment, the PCP server advertised by the MGW does not take into 400 account the NAT carried out by the TOF function. 402 Therefore, PCP client doesn't know which PCP servers should be 403 selected to send the request. 404 [I-D.rpcw-pcp-pmipv6-serv-discovery]provides a solution in similar 405 architecture, in which a smart PCP proxy[I-D.ietf-pcp-proxy] is 406 required on the offloading point to dispatch requests to a right PCP 407 server. However, TOF in 3GPP stores radio network layer 408 information(e.g. RAB ID) to build the local offload context. That 409 can't directly be used to identify a IP flow with 5 tuples. 410 Additional functionalities is required to map identifier of IP flow 411 to RAB ID. PCP proxy may need to include such radio link information 412 in its local context. 414 9. Authentication Consideration 416 The authentication issue in PCP is important to any operating 417 networks, because operators do not want unauthenticated requests to 418 control their NAT/FW ports and addresses. In mobile networks, this 419 issue becomes especially important due to the fact that the mis- 420 function of Carrier Grade NAT will severely destroy user experience 421 and network operating. 423 The problem of PCP authentication comes from the fact that the PCP 424 client (device) and PCP server (FW) usually do not have trust pre- 425 established relationship with each other. To ensure client 426 authentication, we can either use in-band or out-of-band solutions. 427 In-band means that the authentication service is provided within the 428 PCP exchange (e.g., by defining extended options), while out-of-band 429 solutions handle the problem by establishing new trust relationships 430 or reuse existing trust without extending the PCP base protocol. 432 As an in-band solution, [I-D.ietf-pcp-authentication] has provided 433 solutions for PCP authentication, in which an EAP option is included 434 in the PCP requests from the devices. In mobile network, 435 provisioning of new credentials to mobile devices is a difficult 436 task. Taking this into consideration, using EAP-SIM/EAP-AKA/ EAP- 437 AKA' authentication is recommended as in-band solution for 3GPP 438 network. 440 One possible out-band solution is the use of open authentication 441 capability such as 3GPP GAA (Generic Authentication Architecture) 442 defined in 3GPP[TS33.220]. So that, the PCP client can invoke the 443 authentication ability provided by the operator. The other way is to 444 reuse the trust relationship between UE and the MGW. Because the UE 445 has been authenticated to the MGW during context setup, if the MGW 446 delegates its trust to the NAT/FW device (PCP server), the NAT/FW 447 device can trust the PCP requests from those users. 449 10. Conclusion 451 PCP mechanism could be potentially adopted in different usage 452 contexts. The deployment in mobile network described applicability 453 analysis, which could give mobile operators a explicit recommendation 454 for PCP implementation. Operators would benefit from such particular 455 considerations. The memo would take the role to document such 456 considerations for PCP deployment in mobile network. 458 11. Security Considerations 460 TBD 462 12. IANA Considerations 464 This document makes no request of IANA. 466 13. Acknowledgements 468 The authors would like to thank Ping Lin an Tao Sun for their 469 discussion and comments. 471 14. References 473 14.1. Normative References 475 [I-D.ietf-pcp-authentication] 476 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 477 Protocol (PCP) Authentication Mechanism", 478 draft-ietf-pcp-authentication-00 (work in progress), 479 June 2012. 481 [I-D.ietf-pcp-base] 482 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 483 Selkirk, "Port Control Protocol (PCP)", 484 draft-ietf-pcp-base-26 (work in progress), June 2012. 486 [I-D.ietf-pcp-dhcp] 487 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 488 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-03 489 (work in progress), May 2012. 491 [I-D.ietf-pcp-proxy] 492 Boucadair, M., Dupont, F., Penno, R., and D. Wing, "Port 493 Control Protocol (PCP) Proxy Function", 494 draft-ietf-pcp-proxy-00 (work in progress), April 2012. 496 [RFC1035] Mockapetris, P., "Domain names - implementation and 497 specification", STD 13, RFC 1035, November 1987. 499 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 500 (DHCP) Service for IPv6", RFC 3736, April 2004. 502 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 503 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 504 September 2007. 506 [TS23.060] 507 "General Packet Radio Service (GPRS); Service description; 508 Stage 2", June 2012. 510 [TS23.401] 511 "General Packet Radio Service (GPRS) enhancements for 512 Evolved Universal Terrestrial Radio Access Network 513 (E-UTRAN) access", June 2012. 515 14.2. Informative References 517 [I-D.rpcw-pcp-pmipv6-serv-discovery] 518 Reddy, T., Patil, P., Chandrasekaran, R., and D. Wing, 519 "PCP Server Discovery with IPv4 traffic offload for Proxy 520 Mobile IPv6", draft-rpcw-pcp-pmipv6-serv-discovery-00 521 (work in progress), February 2012. 523 [I-D.savolainen-6man-optimal-transmission-window] 524 Savolainen, T. and J. Nieminen, "Optimal Transmission 525 Window Configuration Option for ICMPv6 Router 526 Advertisement", 527 draft-savolainen-6man-optimal-transmission-window-00 (work 528 in progress), June 2012. 530 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 531 and M. Carney, "Dynamic Host Configuration Protocol for 532 IPv6 (DHCPv6)", RFC 3315, July 2003. 534 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 535 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 536 Partnership Project (3GPP) Evolved Packet System (EPS)", 537 RFC 6459, January 2012. 539 [TS24.008] 540 "Mobile radio interface Layer 3 specification; Core 541 network protocols; Stage 3", 9.11.0 3GPP TS 24.008, 542 June 2012. 544 [TS33.220] 545 "Generic Authentication Architecture (GAA); Generic 546 Bootstrapping Architecture (GBA)", 10.1.0 3GPP TS 33.220, 547 March 2012. 549 [VTC2007_Energy_Consumption] 550 "Energy Consumption of Always-On Applications in WCDMA 551 Networks", 2007. 553 Authors' Addresses 555 Gang Chen 556 China Mobile 557 No.32 Xuanwumen West Street 558 Xicheng District 559 Beijing 100053 560 China 562 Email: phdgang@gmail.com 564 Zhen Cao 565 China Mobile 566 No.32 Xuanwumen West Street 567 Xicheng District 568 Beijing 100053 569 China 571 Email: caozhen@chinamobile.com 573 Mohamed Boucadair 574 France Telecom 575 No.32 Xuanwumen West Street 576 Rennes, 577 35000 578 France 580 Email: mohamed.boucadair@orange.com 581 Vizdal Ales 582 Deutsche Telekom AG 583 Tomickova 2144/1 584 Prague 4,, 149 00 585 Czech Republic 587 Phone: 588 Fax: 589 Email: ales.vizdal@t-mobile.cz 590 URI: 592 Laurent Thiebaut 593 Alcatel-Lucent 595 Phone: 596 Fax: 597 Email: laurent.thiebaut@alcatel-lucent.com 598 URI: