idnits 2.17.1 draft-chen-pcp-mobile-deployment-04.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3933 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'I-D.cheshire-pcp-anycast' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'I-D.kiesel-pcp-ip-based-srv-disc' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'I-D.rpcw-pcp-pmipv6-serv-discovery' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 497, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-01 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-07 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-03 ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-cheshire-pcp-anycast-01 == Outdated reference: A later version (-01) exists of draft-kiesel-pcp-ip-based-srv-disc-00 == Outdated reference: A later version (-03) exists of draft-rpcw-pcp-pmipv6-serv-discovery-02 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 14 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 15, 2014 M. Boucadair 6 France Telecom 7 A. Vizdal 8 Deutsche Telekom AG 9 L. Thiebaut 10 Alcatel-Lucent 11 July 14, 2013 13 Analysis of Port Control Protocol in Mobile Network 14 draft-chen-pcp-mobile-deployment-04 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 analyzed. 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 15, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Benefits of Introducing PCP in Mobile Networks . . . . . . . 3 60 2.1. Restoring Internet Reachability . . . . . . . . . . . . . 3 61 2.2. Radio Resource Optimization . . . . . . . . . . . . . . . 3 62 2.3. Energy Saving . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Overviews of PCP Deployment in Mobile Network . . . . . . . . 4 64 4. PCP Server Discovery . . . . . . . . . . . . . . . . . . . . 5 65 5. MN and multi-homing . . . . . . . . . . . . . . . . . . . . . 6 66 6. Retransmission Consideration . . . . . . . . . . . . . . . . 6 67 7. Unsolicited Messages Delivery . . . . . . . . . . . . . . . . 7 68 8. SIPTO Architecture . . . . . . . . . . . . . . . . . . . . . 8 69 9. Authentication Consideration . . . . . . . . . . . . . . . . 9 70 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 14.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 14.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The Port Control Protocol[RFC6887] allows an IPv6 or IPv4 host to 82 control how incoming IPv6 or IPv4 packets are translated and 83 forwarded by a network address translator (NAT) or simple 84 firewall(FW), and also allows a host to optimize its outgoing NAT 85 keepalive messages. A 3rd Generation Partnership Project (3GPP) 86 network can benefit from the use of the PCP service. Traffic in a 87 mobile network is becoming a complex mix of various protocols, 88 different applications and user behaviors. Mobile networks are 89 currently facing several issues such as a frequent keepalive message, 90 terminal battery consumption and etc. In order to mitigate these 91 issues, PCP could be used to improve terminal behavior by managing 92 how incoming packets are forwarded by upstream devices such as NAT64, 93 NAT44 translators and firewall devices. 95 It should be noticed that mobile networks have particular 96 characteristics and therefore, there are several factors that should 97 be investigated before implementing PCP in a mobile context. Without 98 the particular considerations , PCP may not provide desirable 99 outcomes. Some default behaviors may even cause negative impacts or 100 system failures in a mobile environment. Considering very particular 101 environment of mobile networks , it's needed to have a document 102 describing specific concerns from mobile network side. That would 103 also encourage PCP support in mobile network as well. 105 This memo covers PCP-related considerations in mobile networks. The 106 intension of publishing this memo is to elaborate major issues during 107 the deployment and share the thoughts for potential usages in mobile 108 networks. Such considerations would provide a pointer to parties 109 interested (e.g. mobile operators) to be included in their UE profile 110 requirements. Some adaptation of PCP protocol might be derived from 111 this document. Such a work would be documented in separated memo(s). 113 2. Benefits of Introducing PCP in Mobile Networks 115 2.1. Restoring Internet Reachability 117 Many Mobile networks are making use of a Firewall to protect their 118 customers from an unwanted Internet originated traffic. The firewall 119 is usually configured to reject all unknown inbound connections and 120 only permit inbound traffic that belongs to a connection initiated 121 from the Firewall or NAT/PAT device. The behavior is described as 122 Category I in [I-D.ietf-opsawg-firewalls].There are applications that 123 can be running on the mobile device that require to be reachable from 124 the Internet or there could be services running behind the terminal 125 that require reachability from the Internet. For example, mobile 126 phones should be able to reachable for instant message or online 127 game. PCP enabled applications / devices could request a port from 128 the Firewall to ensure Internet reachability, and thus would lighten 129 the traffic flow of keep-alive by reducing the number of sending 130 packets. This would result in resource savings on the Firewall node 131 whilst still keeping the customer protected from the unwanted 132 traffic. 134 2.2. Radio Resource Optimization 136 3GPP network use different radio channels to transmit control 137 messages(e.g. signaling) and data packages(e.g. voice packages or 138 data flows). Always-on applications, e.g. IM(Instant Message), VoIP 139 or P2P based applications always generate a fair amount of keepalive 140 messages periodically. It's observed that a number of trivial 141 keepalive messages may occupy the data channel. For example, 16% of 142 traffic caused by instant signaling message would consume 50%~70% 143 radio resource in some area. It likely causes the air congestion 144 with voice calls and service data transmission. PCP could help to 145 reduce the frequency of periodic messages aimed at refreshing a NAT/ 146 FW binding by indicating to the mobile device the Life time of a 147 binding. 149 2.3. Energy Saving 151 Devices with low battery resources exist widely in mobile 152 environments, such as mobile terminals, advanced sensors, etc. mobile 153 terminals often go to "sleep" (IDLE) mode to extend battery life and 154 save air resources. Host initiated message needs to "wake-up" mobile 155 terminals by changing the state to CONNECTED. That would cause more 156 energy on such terminals. Testing reports show that energy 157 consumption is dramatically reduced with prolonged sending interval 158 of signaling messages [VTC2007_Energy_Consumption]. 160 3. Overviews of PCP Deployment in Mobile Network 162 The Figure 1 shows the architecture of a mobile network. Radio 163 access network would provide wireless connectivity to the MN. 164 Packets are transmitted through Packet Switch(PS) domain heading to 165 MGW. MGW bear the responsibilities of address allocation, routing 166 and transfer. The connection between MN and MGW normally is a point- 167 to- point link, on which MGW is the default router for MN. NAT/ 168 Firewall could either be integrated with MGW or deployed behind MGW 169 as standalone. The traffic is finally destined to application 170 servers, which manage subscriber service. 172 MN Internet 173 | +---------------+ +----------------+ 174 +-+ +-----+ | +--|--+ +-------+ | +----------+ | 175 | | /|/ | RAN |---| PS Network | MGW |---- |NAT/FW |----| |APP Server| | 176 +-+ +-----+ | +--|--+ +-------+ | +----------+ | 177 +---------------+ +----------------+ 178 MN: Mobile Nodes 179 RAN: Radio Access Network 180 PS: Packet Switch 181 MGW:Mobile GateWay 182 NAT/FW: Network Address Translator or Firewall 184 Figure 1: Mobile Networks Scenario 186 A PCP client could be located on MN to control the outbound and 187 inbound traffic on PCP servers. The PCP server is hosted by the NAT/ 188 FW respectively. Corresponding to the various behaviors of PCP 189 client, MN would perform PCP operation using MAP, PEER or ANNOUNCE 190 opcodes. A specific application programming interface may be 191 provided to applications. More discussions and recommendations are 192 presented in following sub-sections. 194 4. PCP Server Discovery 196 A straightforward solution seems that MN assume their default router 197 as the PCP Server. However, NAT/FW normally is deployed in a 198 different node than the MGW. Thus there is the need to ensure that 199 MN get information allowing them to discover a PCP server. 201 [I-D.ietf-pcp-dhcp] specified name options in DHCPv4 and DHCPv6 to 202 discover PCP server. It's expected the same mechanism could be used 203 in mobile network. 3GPP network allocates IP address and respective 204 parameter during the PDP (Packet Data Protocol)/PDN(Packet Data 205 Network) context activation phase (PDP and PDN represent terminology 206 in 3G and LTE network respectively ). On the UE, a PDP/PDN context 207 has same meaning which is equivalent to a network interface. 209 It should be noted that the Stateful DHCPv6-based address 210 configuration[RFC3315]is not supported by 3GPP specifications. 3GPP 211 adopts IPv6 Stateless Address Auto-configuration (SLAAC) [RFC4861]to 212 allocate IPv6 address. The UE uses stateless DHCPv6[RFC3736] for 213 additional parameter configuration. The MGW acts as the DHCPv6 214 server. PCP servers discovery could leverage current process to 215 perform the functionalities. The M-bit is set to zero and the O-bit 216 may be set to one in the Router Advertisement (RA) sent to the UE. 217 To carry out PCP sever discovery, a MN should thus send an 218 Information-request message that includes an Option Request Option 219 (ORO) requesting the DHCPv6 PCP Server Name option. 221 Regarding the IPv4 bearer, MN generally indicates that it prefers to 222 obtain an IPv4 address as part of the PDP context activation 223 procedure. In such a case, the MN relies on the network to provide 224 IPv4 parameters as part of the PDP context activation/ PDN connection 225 set-up procedure. The MN may nevertheless indicate that it prefers 226 to obtain the IPv4 address and configuration parameter after the PDP 227 Context activation by DHCPv4, but it is not available on a wide 228 scale[RFC6459]. MN usually receive those configurations in 229 PCO(Protocol Configuration Options) . PCP server name options in 230 DHCPv4 would not help the PCP servers discovery in that case. 232 A specific method in 3GPP is to extend PCO [TS24.008]information 233 element to transfer a request of PCP server name. However, 234 additional specification efforts are required in 3GPP to make that 235 happen. 237 [I-D.cheshire-pcp-anycast]and 238 [I-D.kiesel-pcp-ip-based-srv-disc]propose anycast-based solutions to 239 discover the closest PCP server on the data path. It may be worth to 240 consider the case when a subscriber roams to different areas, where 241 anycast configurations may be unavailable or operators use other 242 provisioning method, for example [I-D.ietf-pcp-dhcp]. Asymmetric 243 routing should also be considered in the anycast-based solution. 244 Otherwise, the traffic would likely loses the mapping information for 245 the inbound traffic. 247 5. MN and multi-homing 249 As a MN may activate multiple PDP context / PDN connection, it may be 250 multi-homed (the UE receives at least an IP address / an IPv6 prefix 251 per PDN connection). Different MGWs are likely to be associated with 252 each of these PDP context / PDN connection and may thus advertise 253 different PCP servers (using the mechanism described in the previous 254 section). In that case, a MN has to be able to manage multiple PCP 255 servers and to associate an IP flow with the PCP server corresponding 256 to the PDP context / PDN connection used to carry that IP flow. 258 6. Retransmission Consideration 260 Mobile devices are usually powered with limited battery . Users would 261 like to use such MN for several days without charging, even several 262 weeks in sensor case. Many applications do not send or receive 263 traffic constantly; instead, the network interface is idle most of 264 the time. That could help to save energy unless there is data 265 leading the link to be activated. Such state changes is based on 266 network-specific timer values corresponding to a number of Radio 267 Resource Control (RRC) states(see more at Section 8.2.2 268 3GPP[TS23.060]. In order to maximize battery life, it's desirable 269 that all activities on battery-powered devices needs to be 270 coordinated and synchronized. It's not specific to PCP. Whereas , 271 those concerns also can be applied to PCP retransmission behavior. 273 PCP designed retransmission mechanisms on the client for reliable 274 delivery of PCP request. If a PCP client fails to receive an 275 expected response from a server, the client must retransmit its 276 message. The retransmission method may cause unnecessary power 277 consumption when a subscriber roams to a network, in which PCP is not 278 deployed. Several timers are specified to control the retransmission 279 behavior. Therefore, an appropriate implementation and configuration 280 are desirable to help to alleviate the concern. For example, the 281 time transiting to idle is normally less than default Maximum 282 Retransmission Time (MRT), i.e. 1024 seconds. With "no maximum" 283 setting of Maximum Retransmission Duration (MRD), it would cause 284 devices activating their uplink radio in order to retransmit the 285 request messages. Furthermore, the state transition and the 286 transmission take some times, which causes significant power 287 consumption. The MRD should be configured with an optimal time which 288 in line with activated state duration on the device. 290 The power consumption problem is made complicated if several PCP 291 clients residing on a MN. Several clients are potentially sending 292 requests at random times and by so doing causing MN uplink radio into 293 a significantly power consuming state for unnecessarily often. It's 294 necessary to perform a synchronization process for tidy up several 295 PCP clients retransmission. A time-line observer maybe required to 296 control different PCP clients resending requests in an optimal 297 transmission window. If the uplink radio of MN is active at the time 298 of sending retransmission from several clients, a proper MRD 299 described as above should be set in a client. If the uplink radio of 300 MN is in idle mode, the time-line observer should hold Initial 301 Retransmission Time(IRT) for while to synchronize different 302 retransmitted PCP requests into same optimal transmission window. 304 7. Unsolicited Messages Delivery 306 When the states on NAT/FW have been changed like reboot or changed 307 configuration, PCP servers can send unsolicited messages (e.g. 308 ANNOUNCE messages or unicast PCP MAP or PEER responses ) to clients 309 informing them of the new state of their mappings. This aims at 310 achieving rapid detection of PCP failure, rapid PCP recovery or PCP 311 mapping update. When those messages are delivered in a mobile 312 environment, it should be noted multicast delivery may not be 313 available in 3GPP network. PCP servers would use unicast delivery. 314 More considerations are listed as the below. 316 o This requires PCP servers to retain knowledge of the IP 317 address(es) and port(s) of their clients, for example using 318 redundancy design based on hot-standby, even though they have 319 rebooted 321 o Care should be taken not to generate floods of unicast messages, 322 e.g. to multiple thousands of MN that were served by a PCP server 323 that has rebooted. Such flood may have impacts on Mobile Networks 324 as it may imply the simultaneous generation of Paging process(see 325 more at Section 8.2.4 3GPP[TS23.060]) for very big numbers of MN. 327 o Paging function is optionally supported at some particular nodes, 328 e.g. Traffic Offload Function (TOF) in Selected IP Traffic Offload 329 architecture (more discussions on this issues is described in 330 Section 7). The delivery of unsolicited messages would fail in 331 this case. 333 8. SIPTO Architecture 335 Since Release 10, 3GPP starts supporting of Selected IP Traffic 336 Offload (SIPTO) function defined in [TS23.060], [TS23.401].The SIPTO 337 function allows an operator to offload certain types of traffic at a 338 network node close to the UE's point of attachment to the access 339 network. It can be achieved by selecting a set of MGWs that is 340 geographically/topologically close to a UE's point of attachment. 341 Two variants of solutions has specified in 3GPP. 343 The mainstream standard deployment relies on selecting a MGW that is 344 geographically/ topologically close to a UE's point of attachment. 345 This deployment may apply to both 3G and LTE. The MN may sometimes 346 be requested to re-activate its PDP context / PDN connection, in 347 which case it is allocated a new MGW and thus a new IP address and a 348 new PCP server. In this case, host renumbering is inevitable. Some 349 considerations have been described as Address Change Events at 350 Section11.5 of [RFC6887]. The deletions of the mapping information 351 on the old MGW is necessary in order to avoid traffic sending to the 352 old IP address. In a mobile device context, PCP client may take the 353 NAS(Non-Access Stratum) layer message (e.g. "reactivation request" or 354 "detach request" message) as a notification to delete the old mapping 355 information before the subscriber moved to new MGW. Afterwards, PCP 356 clients install new mappings for its new IP address. 358 As an implementation option dedicated to 3G networks, it is also 359 possible to carry out Selected IP Traffic Offload in a TOF(Traffic 360 Offload Function) entity [TS23.060]located at the interface of the 361 Radio Access Network, i.e. in the path between the radio stations and 362 the Mobile Gateway. The TOF decides on which traffic to offload and 363 enforces NAT for that traffic. The deployment of a TOF is totally 364 transparent for user's equipments that even cannot know which traffic 365 is subject to TOF (NATed at the TOF) and which traffic is processed 366 by the MGW. The PCP server advertised by the MGW does not take into 367 account the NAT carried out by the TOF function. Therefore, PCP 368 client doesn't know which PCP servers should be selected to send the 369 request. [I-D.rpcw-pcp-pmipv6-serv-discovery]provides a solution in 370 the similar architecture, in which a PCP proxy with advanced 371 functions[I-D.ietf-pcp-proxy] is required on the offloading point to 372 dispatch requests to a right PCP server. Additional consideration 373 will be given for determining the each traffic flow, since TOF 374 inspects the NAS and RANAP(Radio Access Network Application Part) 375 messages to build the local UE context and local session context. 376 The traffic flow can't be identified with 5 tuples. The offloaded IP 377 flow is indicated with Radio Access Bearer Identifier (RAB-ID). PCP 378 proxy must understand RAB-ID and map the identifier with each IP 379 flow. 381 9. Authentication Consideration 383 The general authentication requirements have been analyzed in 384 [I-D.reddy-pcp-auth-req]. In mobile networks, it is desirable to 385 reuse the existing credentials on the UE for the pcp authentication 386 between involved entities. This way makes the deployment of 387 authentication easiler. 389 The [I-D.ietf-pcp-authentication] has provided solutions for PCP 390 authentication, in which an EAP option is included in the PCP 391 requests from the devices. In the EAP framework, the EAP 392 authentication server could be the co-located with the PCP server or 393 separated and located on a third-party entity. If the EAP 394 authentication server is placed on the AAA/Radius server, there is a 395 need of an interface between the PCP server and AAA. But per our 396 investigation of 3GPP networks, most exisiting NAT devices do not 397 have such an interface with AAA. So in practical deployment, this 398 could be taken into consideration. 400 10. Conclusion 402 PCP mechanism could be potentially adopted in different usage 403 contexts. The deployment in mobile network described applicability 404 analysis, which could give mobile operators a explicit recommendation 405 for PCP implementation. Operators would benefit from such particular 406 considerations. The memo would take the role to document such 407 considerations for PCP deployment in mobile network. 409 11. Security Considerations 411 TBD 413 12. IANA Considerations 415 This document makes no request of IANA. 417 13. Acknowledgements 419 The authors would like to thank Dan Wing, Stuart Cheshire, Ping Lin 420 and Tao Sun for their discussion and comments. 422 Many thanks to Reinaldo Penno and Tirumaleswar Reddy for their 423 detailed reviews. 425 14. References 427 14.1. Normative References 429 [I-D.ietf-pcp-authentication] 430 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 431 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 432 authentication-01 (work in progress), October 2012. 434 [I-D.ietf-pcp-dhcp] 435 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 436 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-07 437 (work in progress), March 2013. 439 [I-D.ietf-pcp-proxy] 440 Boucadair, M., Penno, R., and D. Wing, "Port Control 441 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-03 442 (work in progress), June 2013. 444 [I-D.reddy-pcp-auth-req] 445 Reddy, T., Patil, P., Wing, D., and R. Penno, "PCP 446 Authentication Requirements", draft-reddy-pcp-auth-req-04 447 (work in progress), July 2013. 449 [RFC1035] Mockapetris, P., "Domain names - implementation and 450 specification", STD 13, RFC 1035, November 1987. 452 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 453 Networks", BCP 84, RFC 3704, March 2004. 455 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 456 (DHCP) Service for IPv6", RFC 3736, April 2004. 458 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 459 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 460 September 2007. 462 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 463 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 464 2013. 466 [TS23.060] 467 , "General Packet Radio Service (GPRS); Service 468 description; Stage 2", June 2012. 470 [TS23.401] 471 , "General Packet Radio Service (GPRS) enhancements for 472 Evolved Universal Terrestrial Radio Access Network 473 (E-UTRAN) access", June 2012. 475 14.2. Informative References 477 [I-D.cheshire-pcp-anycast] 478 Cheshire, S., "PCP Anycast Address", draft-cheshire-pcp- 479 anycast-01 (work in progress), March 2013. 481 [I-D.ietf-opsawg-firewalls] 482 Baker, F. and P. Hoffman, "On Firewalls in Internet 483 Security", draft-ietf-opsawg-firewalls-01 (work in 484 progress), October 2012. 486 [I-D.kiesel-pcp-ip-based-srv-disc] 487 Kiesel, S. and R. Penno, "PCP Server Discovery based on 488 well-known IP Address", draft-kiesel-pcp-ip-based-srv- 489 disc-00 (work in progress), February 2013. 491 [I-D.rpcw-pcp-pmipv6-serv-discovery] 492 Reddy, T., Patil, P., Chandrasekaran, R., and D. Wing, 493 "PCP Server Discovery with IPv4 traffic offload for Proxy 494 Mobile IPv6", draft-rpcw-pcp-pmipv6-serv-discovery-02 495 (work in progress), February 2013. 497 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 498 and M. Carney, "Dynamic Host Configuration Protocol for 499 IPv6 (DHCPv6)", RFC 3315, July 2003. 501 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 502 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 503 Partnership Project (3GPP) Evolved Packet System (EPS)", 504 RFC 6459, January 2012. 506 [TS24.008] 507 , "Mobile radio interface Layer 3 specification; Core 508 network protocols; Stage 3", 9.11.0 3GPP TS 24.008, June 509 2012. 511 [TS33.220] 512 , "Generic Authentication Architecture (GAA); Generic 513 Bootstrapping Architecture (GBA)", 10.1.0 3GPP TS 33.220, 514 March 2012. 516 [VTC2007_Energy_Consumption] 517 , "Energy Consumption of Always-On Applications in WCDMA 518 Networks", 2007. 520 Authors' Addresses 522 Gang Chen 523 China Mobile 524 No.32 Xuanwumen West Street 525 Xicheng District 526 Beijing 100053 527 China 529 Email: phdgang@gmail.com 531 Zhen Cao 532 China Mobile 533 No.32 Xuanwumen West Street 534 Xicheng District 535 Beijing 100053 536 China 538 Email: caozhen@chinamobile.com 540 Mohamed Boucadair 541 France Telecom 542 No.32 Xuanwumen West Street 543 Rennes, 544 35000 545 France 547 Email: mohamed.boucadair@orange.com 549 Vizdal Ales 550 Deutsche Telekom AG 551 Tomickova 2144/1 552 Prague 4, 149 00 553 Czech Republic 555 Email: ales.vizdal@t-mobile.cz 557 Laurent Thiebaut 558 Alcatel-Lucent 560 Email: laurent.thiebaut@alcatel-lucent.com