idnits 2.17.1 draft-operators-softwire-stateless-4v6-motivation-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2011) is 4706 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-boucadair-intarea-nat-reveal-analysis-01 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft France Telecom 4 Intended status: Informational S. Matsushima 5 Expires: December 11, 2011 Softbank Telecom 6 Y. Lee 7 Comcast 8 O. Bonness 9 Deutsche Telekom 10 I. Borges 11 Portugal Telecom 12 G. Chen 13 China Mobile 14 June 9, 2011 16 Motivations for Stateless IPv4 over IPv6 Migration Solutions 17 draft-operators-softwire-stateless-4v6-motivation-02 19 Abstract 21 IPv4 service continuity is one of the most sensitive problems that 22 must be resolved by Service Providers during the IPv6 transition 23 period - especially after the exhaustion of the public IPv4 address 24 space. Current standardization effort that addresses IPv4 service 25 continuity focuses on stateful mechanisms. This document elaborates 26 on the motivations for the need to undertake a companion effort to 27 specify stateless IPv4 over IPv6 approaches. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 11, 2011. 46 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Why Stateless IPv4 over IPv6 Solutions are Needed? . . . . . . 5 65 3.1. Network Architecture Simplification . . . . . . . . . . . 5 66 3.1.1. Network Dimensioning . . . . . . . . . . . . . . . . . 5 67 3.1.2. No Intra-domain Constraint . . . . . . . . . . . . . . 5 68 3.1.3. Logging - No Need for Dynamic Binding Notifications . 5 69 3.1.4. No Additional Protocol for Port Control is Required . 6 70 3.1.5. Bandwidth Saving . . . . . . . . . . . . . . . . . . . 6 71 3.2. Operational Tasks and Network Maintenance Efficiency . . . 6 72 3.2.1. Preserve Current Practices . . . . . . . . . . . . . . 6 73 3.2.2. Planned Maintenance Operations . . . . . . . . . . . . 7 74 3.2.3. Reliability and Robustness . . . . . . . . . . . . . . 7 75 3.2.4. Support of Multi-Vendor Redundancy . . . . . . . . . . 7 76 3.2.5. Simplification of Qualification Procedures . . . . . . 7 77 3.3. Facilitating Service Evolution . . . . . . . . . . . . . . 8 78 3.3.1. Implicit Host Identification . . . . . . . . . . . . . 8 79 3.3.2. No Organizational Impact . . . . . . . . . . . . . . . 9 80 3.4. Cost Minimization Opportunities . . . . . . . . . . . . . 9 81 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 86 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 When the global IPv4 address space is exhausted, Service Providers 92 will be left with an address pool that cannot be increased anymore. 93 Many services and network scenarios will be impacted by the lack of 94 IPv4 public addresses. Providing access to the (still limited) IPv6 95 Internet only won't be sufficient to address the needs of customers, 96 as most of them will continue to access legacy IPv4-only services. 97 Service Providers must guarantee their customers that they can still 98 access IPv4 contents although they will not be provisioned with a 99 global IPv4 address anymore. Means to share IPv4 public addresses 100 are unavoidable [I-D.ietf-intarea-shared-addressing-issues]. 102 Identifying the most appropriate solution(s) to the IPv4 address 103 exhaustion as well as IPv4 service continuity problems and deploying 104 them in a real network with real customers is a very challenging and 105 complex process for all Service Providers. There is nothing like a 106 "One size fits all" solution or one target architecture that would 107 work for all situations. Each Service Provider has to take into 108 account its own context (e.g., service infrastructures), policies and 109 marketing strategy (a document that informs Service Providers about 110 the impact of the IPv4 address shortage, and provides some 111 recommendations and guidelines, is available at [EURESCOM]). 113 Current standardization effort that is meant to address this IPv4 114 service continuity issue focuses mainly on stateful mechanisms that 115 assume the sharing of any global IPv4 address that is left between 116 several customers, based upon the deployment of NAT (Network Address 117 Translation) capabilities in the network. Because of some caveats of 118 such stateful approaches the Service Provider community feels that a 119 companion effort is required to specify stateless IPv4 over IPv6 120 approaches. This document provides elaboration on such need. 122 Particularly, this document describes the motivations for stateless 123 solutions within the context of an IPv6-enabled network as described 124 in [RFC6180]. The following table shows the targeted space: 126 +---------------+---------------+ 127 | Crossing IPv4 | IPv6-enabled | 128 | networks | networks | 129 +-----------+---------------+---------------+ 130 | Stateful | RFC5571 | DS-Lite | 131 | solution | (L2TP) | | 132 +-----------+---------------+---------------+ 133 | Stateless | RFC5969 | *Target* | 134 | solution | (6rd) | *space * | 135 +-----------+---------------+---------------+ 137 It is explicitly acknowledged by the authors of this document that 138 both stateful and stateless solutions are required to meet Service 139 Providers needs and constraints. 141 More discussions about stateless vs. stateful can be found at 142 [RFC6144]. 144 2. Terminology 146 This document makes use of the following terms: 148 Stateful 4/6 solution (or stateful solution in short): denotes a 149 solution where the network maintains user-session 150 states relying on the activation of a NAT 151 function in the Service Providers' network 152 [I-D.ietf-behave-lsn-requirements]. The NAT 153 function is responsible for sharing the same IPv4 154 address among several subscribers and to maintain 155 user-session state. 157 Stateless 4/6 solution (or stateless solution in short): denotes a 158 solution which does not require any user-session 159 state (see Section 2.3 of [RFC1958]) to be 160 maintained by any IP address sharing function in 161 the Service Provider's network. This category of 162 solutions assumes a dependency between an IPv6 163 prefix and IPv4 address. In an IPv4 address 164 sharing context, dedicated functions are required 165 to be enabled in the CPE router to restrict the 166 source IPv4 port numbers. Within this document, 167 "port set" and "port range" terms are used 168 interchangeably. 170 3. Why Stateless IPv4 over IPv6 Solutions are Needed? 172 This section discusses motivations for preferring a deployment of 173 stateless 4/6 solutions. The technical and operational benefits of 174 the stateless solutions are possible because no per-user state 175 [RFC1958] is maintained in the Service Providers networks. 177 3.1. Network Architecture Simplification 179 The activation of this stateless function in the Service Provider's 180 network does not introduce any major constraint on the network 181 architecture and its engineering. The following sub-sections 182 elaborate on these aspects. 184 3.1.1. Network Dimensioning 186 Because no user-state [RFC1958] is required, a stateless solution 187 does not need to take into account the maximum number of simultaneous 188 user-sessions and the maximum number of new user-sessions per second 189 to dimension its networking equipment. Like current network 190 dimensioning practices, only considerations related to the customer 191 number, traffic trends and the bandwidth usage need be taken into 192 account for dimensioning purposes. 194 3.1.2. No Intra-domain Constraint 196 Stateless IPv4/IPv6 interconnection functions can be ideally located 197 at the boundaries of an Autonomous System (e.g., ASBR routers that 198 peer with external IPv4 domains); in such case: 200 Intra-domain paths are not altered: there is no need to force IP 201 packets to cross a given node for instance; intra-domain routing 202 processes are not tweaked to direct the traffic to dedicated 203 nodes. In particular, stateless solutions optimizes CPE-to-CPE 204 communication in that packets don't go through the interconnection 205 function since the address and port mapping has been realized 206 based on a well defined mapping schema that is known to all 207 involved devices. 209 3.1.3. Logging - No Need for Dynamic Binding Notifications 211 Network abuse reporting requires traceability 212 [I-D.ietf-intarea-shared-addressing-issues]. To provide such 213 traceability, prior to IPv4 address sharing, logging the IPv4 address 214 assigned to a user was sufficient and generates relatively small 215 logs. The advent of stateful IPv4 address allows dynamic port 216 assignment, which then requires port assignment logging. This 217 logging of port assignments can be considerable. 219 In contrast, static port assignments do not require such considerable 220 logging. The volume of the logging file may not be seen as an 221 important criterion for privileging a stateless approach because 222 stateful approaches can also be configured (or designed) to assign 223 port ranges and therefore lead to acceptable log volumes. 225 If a dynamic port assignment mode is used, dedicated interfaces and 226 protocols must be supported to forward binding data records towards 227 dedicated platforms. The activation of these dynamic notifications 228 may impact the performance of the dedicated device. For stateless 229 solutions, there is no need for dynamic procedures (e.g., using 230 SYSLOG) to notify a mediation platform about assigned bindings. 232 Some Service Providers have a requirement to use only existing 233 logging systems and to avoid introducing new ones (mainly because of 234 CAPEX considerations). This requirement is easily met with stateless 235 solutions. 237 3.1.4. No Additional Protocol for Port Control is Required 239 The deployment of stateless solution does not require the deployment 240 of new dynamic signaling protocols to the end-user CPE in addition to 241 those already used. In particular, existing protocols (e.g., UPnP 242 IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. 244 3.1.5. Bandwidth Saving 246 In same particular network scenarios (e.g., wireless network ), 247 spectrum is very valuable and scarce resource. Service providers 248 usually wish to eliminate unnecessary overhead to save bandwidth 249 consumption in such environment. Service providers need to consider 250 optimizing the form of packet processing when encapsulation is used. 251 Since existing header compression techniques are stateful, it is 252 expected that stateless solution minimize overhead introduced by the 253 solution. 255 3.2. Operational Tasks and Network Maintenance Efficiency 257 3.2.1. Preserve Current Practices 259 Service Providers require as much as possible to preserve the same 260 operations as for current IP networking environments. 262 If stateless solutions are deployed, common practices are preserved. 263 In particular, the maintenance and operation of the network do not 264 require any additional constraints such as: path optimization 265 practices, enforcing traffic engineering policies, issues related to 266 traffic oscillation between stateful devices, load-balancing the 267 traffic or load sharing the traffic among egress/ingress points can 268 be used, etc. In particular: 270 o anycast-based schemes can be used for load-balancing and 271 redundancy purposes. 273 o asymmetric routing to/from the IPv4 Internet is natively supported 274 and no path-pinning mechanisms have to be additionally 275 implemented. 277 3.2.2. Planned Maintenance Operations 279 Since no state is maintained by stateless IPv4/IPv6 interconnection 280 nodes, no additional constraint needs to be taken into account when 281 upgrading these nodes (e.g., adding a new service card, upgrading 282 hardware, periodic reboot of the devices, etc.). In particular, 283 current practices that are enforced to (gracefully) reboot or to 284 shutdown routers can be maintained. 286 3.2.3. Reliability and Robustness 288 Compared to current practices (i.e., without a CGN in place), no 289 additional capabilities are required to ensure reliability and 290 robustness in the context of stateless solutions. Since no state is 291 maintained in the Service Provider's network, state synchronization 292 procedures are not required. 294 High availability (including failure recovery) is ensured owing to 295 best current practices in the field. 297 3.2.4. Support of Multi-Vendor Redundancy 299 Deploying stateful techniques, especially when used in the Service 300 Providers networks, constrain severely deploying multi-vendor 301 redundancy since very often proprietary vendor-specific protocols are 302 used to synchronize state. This is not an issue for the stateless 303 case. Concretely, the activation of the stateless IPv4/IPv6 304 interconnection function does not prevent nor complicate deploying 305 devices from different vendors. 307 This criterion is very important for Service Providers having a 308 sourcing policy to avoid mono-vendor deployments and to operate 309 highly-available networks composed on multi-vendors equipment. 311 3.2.5. Simplification of Qualification Procedures 313 The introduction of new functions and nodes into operational networks 314 follows strict procedures elaborated by Service Providers. These 315 procedures include in-lab testing and field trials. Because of their 316 nature, stateless implementations optimize testing times and 317 procedures: 319 o The specification of test suites to be conducted should be 320 shorter; 322 o The required testing resources (in terms of manpower) are likely 323 to be less solicited that they are for stateful approaches. 325 One of the privileged approaches to integrate stateless IPv4/IPv6 326 interconnection function consists in embedding stateless capabilities 327 in existing operational nodes (e.g., IP router). In this case, any 328 software or hardware update would require to execute non-regression 329 testing activities. In the context of the stateless solutions, the 330 non-regression testing load due to an update of the stateless code is 331 expected to be minimal. 333 For the stateless case, testing effort and non-regression testing are 334 to be taken into account for the CPE side. This effort is likely to 335 be lightweight compared to the testing effort, including the non- 336 regression testing, of a stateful function which is co-located with 337 other routing functions for instance. 339 3.3. Facilitating Service Evolution 341 3.3.1. Implicit Host Identification 343 Service Providers do not offer only IP connectivity services but also 344 added value services (a.k.a., internal services). Upgrading these 345 services to be IPv6-enabled is not sufficient because of legacy 346 devices. In some deployments, the delivery of these added-value 347 services relies on implicit identification mechanism based on the 348 source IPv4 address. Due to address sharing, implicit identification 349 will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing 350 implicit identification with explicit authentication will be seen as 351 a non acceptable service regression by the end users (less Quality of 352 Experience (QoE)). 354 When a stateless solution is deployed, implicit identification for 355 internal services is likely to be easier to implement: the implicit 356 identification should be updated to take into account the port range 357 and the IPv4 address. Techniques as those analyzed in 358 [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the 359 delivery of these internal services if a stateless solution is 360 deployed. 362 3.3.2. No Organizational Impact 364 Stateless solutions rely on IP-related techniques to share and to 365 deliver IPv4 packets over an IPv6 network. In particular, IPv4 366 packets are delivered without any modification to their destination 367 CPE. As such there is a clear separation between the IP/transport 368 layers and the service layers; no service interference is to be 369 observed when a stateless solution is deployed. This clear 370 separation: 372 Facilitates service evolution: Since the payload of IPv4 packets is 373 not altered in the path, services can evolve without requiring any 374 specific function in the Service Provider's network; 376 Limits vendor dependency: The upgrade of value-added services does 377 not involve any particular action from vendors that provide 378 devices embedding the stateless IPv4/IPv6 interconnection 379 function. 381 No service-related skills are required for network operators who 382 manage devices that embed the IPv4/IPv6 interconnection function: IP 383 teams can be in charge of these devices; there is a priori no need 384 to create a dedicated team to manage and to operate devices 385 embedding the stateless IPv4/IPv6 interconnection function. The 386 introduction of stateless capabilities in the network are unlikely 387 to degrade management costs. 389 3.4. Cost Minimization Opportunities 391 To make decision for which solution is to be adopted, service 392 providers usually undertake comparative studies about viable 393 technical solutions. It is not only about technical aspects but also 394 economical optimization (both CAPEX and OPEX considerations). 396 From a Service Provider perspective, stateless solutions are more 397 attractive because they do less impact the current network operations 398 and maintenance model that is widely based on stateless approaches. 399 Table 1 shows the general correspondence between technical benefits 400 and potential economic reduction opportunities. 402 While not all Service Providers environments are the same, a detailed 403 case study from one Service Provider 404 [I-D.matsushima-v6ops-transition-experience] reports that stateless 405 transition solutions can be considerably less expensive than stateful 406 transition solutions. 408 +---------------+--------------------------------------+------------+ 409 | Section | Technical and Operation Benefit | Cost Area | 410 +---------------+--------------------------------------+------------+ 411 | Section 3.1.1 | Network dimensioning | Network | 412 +---------------+--------------------------------------+------------+ 413 | Section 3.1.2 | No Intra-domain constraint | Network | 414 +---------------+--------------------------------------+------------+ 415 | Section 3.1.3 | Logging | Network & | 416 | | | Ops | 417 +---------------+--------------------------------------+------------+ 418 | Section 3.1.4 | No additional control protocol | Network | 419 +---------------+--------------------------------------+------------+ 420 | Section 3.2.1 | Preserve current practices | Ops | 421 +---------------+--------------------------------------+------------+ 422 | Section 3.2.2 | Planned maintenance | Ops | 423 +---------------+--------------------------------------+------------+ 424 | Section 3.2.3 | Reliability and robustness | Network & | 425 | | | Ops | 426 +---------------+--------------------------------------+------------+ 427 | Section 3.2.4 | Multi-Vendor Redundancy | Network | 428 +---------------+--------------------------------------+------------+ 429 | Section 3.2.5 | Simple qualification | Ops | 430 +---------------+--------------------------------------+------------+ 431 | Section 3.3.1 | Implicit Host Identification for | Ops | 432 | | internal services | | 433 +---------------+--------------------------------------+------------+ 434 | Section 3.3.2 | Organizational Impact | Ops | 435 +---------------+--------------------------------------+------------+ 437 Table 1: Cost minimization considerations 439 4. Conclusion 441 As discussed in Section 3, stateless solutions provide several 442 interesting features. Trade-off between the positive vs. negative 443 aspects of stateless solutions is left to Service Providers. Each 444 Service Provider will have to select the appropriate solution 445 (stateless, stateful or even both) meeting its requirements. 447 This document recommends to undertake as soon as possible the 448 appropriate standardization effort to specify a stateless IPv4 over 449 IPv6 solution. 451 5. IANA Considerations 453 No action is required from IANA. 455 6. Security Considerations 457 Except for the less efficient port randomization of and routing loops 458 [I-D.ietf-v6ops-tunnel-loops], stateless 4/6 solutions are expected 459 to introduce no more security vulnerabilities than stateful ones. 460 Because of their stateless nature, they may in addition reduce denial 461 of service opportunities. 463 7. Contributors 465 The following individuals have contributed to this document: 467 Christian Jacquenet 468 France Telecom 470 Email: christian.jacquenet@orange-ftgroup.com 472 Pierre Levis 473 France Telecom 475 Email: pierre.levis@orange-ftgroup.com 477 Masato Yamanishi 478 SoftBank BB 480 Email: myamanis@bb.softbank.co.jp 482 Yuji Yamazaki 483 Softbank Mobile 485 Email: yuyamaza@bb.softbank.co.jp 487 Hui Deng 488 China Mobile 489 53A,Xibianmennei Ave. 490 Beijing 100053 491 P.R.China 493 Phone: +86-13910750201 494 Email: denghui02@gmail.com 496 8. Acknowledgments 498 Many thanks to the following individuals who provided valuable 499 comments: 501 +---------------+---------------+---------------+---------------+ 502 | X. Deng | W. Dec | D. Wing | A. Baudot | 503 | E. Burgey | L. Cittadini | R. Despres | J. Zorz | 504 | M. Townsley | L. Meillarec | R. Maglione | J. Queiroz | 505 | C. Xie | X. Li | O. Troan | J. Qin | 506 | B. Sarikaya | | | | 507 +---------------+---------------+---------------+---------------+ 509 9. Informative References 511 [EURESCOM] 512 Levis, P., Borges, I., Bonness, O. and L. Dillon L., "IPv4 513 address exhaustion: Issues and Solutions for Service 514 Providers", March 2010, . 518 [I-D.boucadair-intarea-nat-reveal-analysis] 519 Boucadair, M., Touch, J., and P. Levis, "Analysis of 520 Solution Candidates to Reveal the Origin IP Address in 521 Shared Address Deployments", 522 draft-boucadair-intarea-nat-reveal-analysis-01 (work in 523 progress), March 2011. 525 [I-D.ietf-behave-lsn-requirements] 526 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 527 and H. Ashida, "Common requirements for IP address sharing 528 schemes", draft-ietf-behave-lsn-requirements-01 (work in 529 progress), March 2011. 531 [I-D.ietf-intarea-shared-addressing-issues] 532 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 533 Roberts, "Issues with IP Address Sharing", 534 draft-ietf-intarea-shared-addressing-issues-05 (work in 535 progress), March 2011. 537 [I-D.ietf-v6ops-tunnel-loops] 538 Nakibly, G. and F. Templin, "Routing Loop Attack using 539 IPv6 Automatic Tunnels: Problem Statement and Proposed 540 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 541 progress), May 2011. 543 [I-D.matsushima-v6ops-transition-experience] 544 Matsushima, S., Yamazaki, Y., Sun, C., Yamanishi, M., and 545 J. Jiao, "Use case and consideration experiences of IPv4 546 to IPv6 transition", 547 draft-matsushima-v6ops-transition-experience-02 (work in 548 progress), March 2011. 550 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 551 RFC 1958, June 1996. 553 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 554 IPv4/IPv6 Translation", RFC 6144, April 2011. 556 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 557 Transition Mechanisms during IPv6 Deployment", RFC 6180, 558 May 2011. 560 [UPnP-IGD] 561 UPnP Forum, "Universal Plug and Play (UPnP) Internet 562 Gateway Device (IGD) V 2.0", December 2010, 563 . 565 Authors' Addresses 567 Mohamed Boucadair (editor) 568 France Telecom 569 Rennes, 35000 570 France 572 Email: mohamed.boucadair@orange-ftgroup.com 574 Satoru Matsushima 575 Softbank Telecom 576 Tokyo 577 Japan 579 Email: satoru.matsushima@tm.softbank.co.jp 581 Yiu Lee 582 Comcast 583 US 585 Email: Yiu_Lee@Cable.Comcast.com 586 Olaf Bonness 587 Deutsche Telekom 588 Germany 590 Email: Olaf.Bonness@telekom.de 592 Isabel Borges 593 Portugal Telecom 594 Portugal 596 Email: Isabel@ptinovacao.pt 598 Gang Chen 599 China Mobile 600 53A,Xibianmennei Ave. 601 Beijing, Xuanwu District 100053 602 China 604 Email: chengang@chinamobile.com