idnits 2.17.1 draft-liu-sunset4-gapanalysis-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 11) being 79 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Liu 3 Internet-Draft W. Xu 4 Intended status: Informational C. Zhou 5 Expires: April 21, 2019 Huawei Technologies 6 T. Tsou 7 Philips Lighting 8 S. Perreault 9 Jive Communications 10 P. Fan 11 R. Gu 12 China Mobile 13 C. Li 14 China Telecom 15 October 22, 2018 17 Gap Analysis for IPv4 Sunset 18 draft-liu-sunset4-gapanalysis-00 20 Abstract 22 Sunsetting IPv4 refers to the process of turning off IPv4 23 definitively. It can be seen as the final phase of the transition to 24 IPv6. This memo enumerates difficulties arising when sunsetting 25 IPv4, and identifies the gaps requiring additional work. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 21, 2019 . 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 4 64 3.1. Indicating that IPv4 connectivity is unavailable . . . . 4 65 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 4 66 4. Client Connection Establishment Behavior . . . . . . . . . . 5 67 5. Disabling IPv4 in Operating System and Applications . . . . . 5 68 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 6 69 7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 6 70 8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 7 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 12. Informative References . . . . . . . . . . . . . . . . . . . 7 75 Annex A. Solution Ideas . . . . . . . . . . . . . . . . . . . . 9 76 A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 9 77 A.1.1. Indicating that IPv4 connectivity is unavailable . . 9 78 A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 9 79 A.2. Client Connection Establishment Behavior . . . . . . . . 10 80 A.3. Disabling IPv4 in Operating System and Applications . . . 10 81 A.4. On-Demand Provisioning of IPv4 Address. . . . . . . . . . 10 82 A.5. Managing Router Identifiers . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 The final phase of the transition to IPv6 is the sunset of IPv4, that 88 is turning off IPv4 definitively on the attached networks and on the 89 upstream networks. 91 Some current implementation behavior makes it hard to sunset IPv4. 92 Additionally, some new features could be added to IPv4 to make its 93 sunsetting easier. This document analyzes the current situation and 94 proposes new work in this area. 96 The decision about when to turn off IPv4 is out of scope. This 97 document merely attempts to enumerate the issues one might encounter 98 if that decision is made. 100 2. Related Work 102 [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794], 103 [RFC3795] and [RFC3796] contain surveys of IETF protocols with their 104 IPv4 dependencies. 106 Additionally, although reviews in RFCs 3789-3796 ensured that IETF 107 standards then in use could support IPv6, no IETF-wide effort has 108 been undertaken to ensure that the issues identified in those drafts 109 are all addressed, nor to ensure that standards written after RFC3100 110 (where the previous review efforts stopped) function properly on 111 IPv6-only networks. 113 The IETF needs to ensure that existing standards and protocols have 114 been actively reviewed, and any parity gaps either identified so that 115 they can be fixed, or documented as unnecessary to address because it 116 is unused or superseded by other features. 118 First, the IETF must review RFCs 3789-3796 to ensure that any gaps in 119 specifications identified in these documents and still in active use 120 have been updated as necessary to enable operation in IPv6-only 121 environments (or if no longer in use, are declared historic). 123 Second, the IETF must review documents written after the existing 124 review stopped (according to RFC 3790, this review stopped with 125 approximately RFC 3100) to identify specifications where IPv6-only 126 operation is not possible, and update them as necessary and 127 appropriate, or document why an identified gap is not an issue i.e. 128 not necessary for functional parity with IPv4. 130 This document does not recommend excluding Informational and BCP RFCs 131 as the previous effort did, due to changes in the way that these 132 documents are used and their relative importance in the RFC Series. 133 Instead, any documents that are still active (i.e. not declared 134 historic or obsolete) and the product of IETF consensus (i.e. not a 135 product of the ISE Series) should be included. In addition, the 136 reviews undertaken by RFCs 3789-3796 were looking for "IPv4 137 dependency" or "usage of IPv4 addresses in standards". This document 138 recommends a slightly more specific set of criteria for review. 139 Reviews should include: 141 o Consideration of whether the specification can operate in an 142 environment without IPv4. 144 o Guidance on the use of 32-bit identifiers that are commonly 145 populated by IPv4 addresses. 147 o Consideration of protocols on which specifications depend or 148 interact, to identify indirect dependencies on IPv4. 150 o Consideration of how to transit from an IPv4 environment to an 151 IPv6 environment. 153 3. Remotely Disabling IPv4 155 3.1. Indicating that IPv4 connectivity is unavailable 157 PROBLEM 1: When an IPv4 node boots and requests an IPv4 address 158 (e.g., using DHCP), it typically interprets the absence 159 of a response as a failure condition even when it is not. 161 PROBLEM 2: Home router devices often identify themselves as default 162 routers in DHCP responses that they send to requests 163 coming from the LAN, even in the absence of IPv4 164 connectivity on the WAN. 166 3.2. Disabling IPv4 in the LAN 168 PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- 169 configure IPv4 addresses [RFC3927] and enable various 170 protocols over IPv4 such as mDNS [RFC6762] and LLMNR 171 [RFC4795]. This can be undesirable for operational or 172 security reasons, since in the absence of IPv4, no 173 monitoring or logging of IPv4 will be in place. 175 PROBLEM 4: IPv4 can be completely disabled on a link by filtering it 176 on the L2 switching device. However, this may not be 177 possible in all cases or may be too complex to deploy. 178 For example, an ISP is often not able to control the L2 179 switching device in the subscriber home network. 181 PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for 182 everything", as described in Section 2.6.2 of [RFC3927]. 183 Applications running on such a host connected to an 184 IPv6-only network will believe that IPv4 connectivity is 185 available, resulting in various bad or sub-optimal 186 behavior patterns. See 187 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further 188 analysis. 190 Some of these problems were described in [RFC2563], which 191 standardized a DHCP option to disable IPv4 address auto- 192 configuration. However, using this option requires running an IPv4 193 DHCP server, which is contrary to the goal of IPv4 sunsetting. 195 4. Client Connection Establishment Behavior 197 PROBLEM 6: Happy Eyeballs [RFC6555] refers to multiple approaches to 198 dual-stack client implementations that try to reduce 199 connection setup delays by trying both IPv4 and IPv6 200 paths simultaneously. Some implementations introduce 201 delays which provide an advantage to IPv6, while others 202 do not [Huston2012]. The latter will pick the fastest 203 path, no matter whether it is over IPv4 or IPv6, 204 directing more traffic over IPv4 than the other kind of 205 implementations. This can prove problematic in the 206 context of IPv4 sunsetting, especially for Carrier-Grade 207 NAT phasing out because CGN does not add significant 208 latency that would make the IPv6 path more preferable. 209 Traffic will therefore continue using the CGN path unless 210 other network conditions change. 212 PROBLEM 7: getaddrinfo() [RFC3493] sends DNS queries for both A and 213 AAAA records regardless of the state of IPv4 or IPv6 214 availability. The AI_ADDRCONFIG flag can be used to 215 change this behavior, but it relies on programmers using 216 the getaddrinfo() function to always pass this flag to 217 the function. The current situation is that in an 218 IPv6-only environment, many useless A queries are made. 220 5. Disabling IPv4 in Operating System and Applications 222 It is possible to completely remove IPv4 support from an operating 223 system as has been shown by the work of Bjoern Zeeb on FreeBSD. 224 [Zeeb] Removing IPv4 support in the kernel revealed many IPv4 225 dependencies in libraries and applications. 227 PROBLEM 8: Completely disabling IPv4 at runtime often reveals 228 implementation bugs. Hard-coded dependencies on IPv4 229 abound, such as on the 127.0.0.1 address assigned to the 230 loopback interface, and legacy IPv4-only APIs are widely 231 used by applications. It is hard for the administrators 232 and users to know what applications running on the 233 operating system have implementation problems of IPv4 234 dependency. It is therefore often operationally 235 impossible to completely disable IPv4 on individual 236 nodes. 238 PROBLEM 9: In an IPv6-only world, legacy IPv4 code in operating 239 systems and applications incurs a maintenance overhead 240 and can present security risks. 242 6. On-Demand Provisioning of IPv4 Addresses 244 As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers 245 will become smaller. This could be exploited by an ISP to save IPv4 246 addresses by provisioning them on-demand to subscribers and 247 reclaiming them when they are no longer used. This idea is described 248 in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the 249 context of PPP sessions. In these scenarios, the home router is 250 responsible for requesting and releasing IPv4 addresses, based on 251 snooping the traffic generated by the hosts in the LAN, which are 252 still dual-stack and unaware that their traffic is being snooped. 254 As described in TR-092 and TR-187, NAS(e.g., BRAS, BNG) stores pools of 255 IPv4 and IPv6 addresses, which are used for DHCP distribution to the 256 hosts in home network. IPv4 and IPv6 addresses of hosts can be dynamic 257 assignment from a pool of IPv4 and IPv6 prefixes in NAS. 259 As the IPv4 sunsets, the number of IPv4 hosts is reduced, therefore the 260 IPv4 address resource in NAS needs to be reduced too. These reduced 261 IPv4 addresses will be reclaimed by the address management system 262 (NMS, controller, IPAM, etc.). At the same time, as the number of IPv6 263 hosts increases, NAS need incrementally increase the number of IPv6 264 address resource. The increased IPv6 address resource can be assigned 265 by the address management system, which makes the transition more 266 smoothly by dynamically adding / releasing IP address resources in NAS. 267 In modern network systems, protocols such as NETCONF / RESTCONF / RADIUS 268 can be used for this process. With NETCONF, NAS acts as NETCONF server 269 mode with the opening port to listen for the client connection, while 270 the address management system as a netconf client that connects and 271 processes IP address request from NAS. 273 PROBLEM 10: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] 274 will generate both IPv4 and IPv6 traffic even if the 275 algorithm end up chooosing IPv6. This means that an IPv4 276 address will always be requested by the home router, 277 which defeats the purpose of on-demand provisioning. 279 PROBLEM 11: Many operating systems periodically perform some kind of 280 network connectivity check as long as an interface is up. 281 Similarly, applications often send keep-alive traffic 282 continuously. This permanent "background noise" will 283 prevent an IPv4 address from being released by the home 284 router. 286 PROBLEM 12: Hosts in the LAN have no knowledge that IPv4 is available 287 to them on-demand only. If they had explicit knowledge 288 of this fact, they could tune their behaviour so as to be 289 more conservative in their use of IPv4. 291 PROBLEM 13: This mechanism is only being proposed for PPP even though 292 it could apply to other provisioning protocols (e.g., 293 DHCP). 295 PROBLEM 14: When the number of IPv4 hosts connected to NAS is reduced, 296 the NAS releases the IPv4 address resource and the NAS 297 requests more IPv6 address resource for it to serve hosts 298 transitting from IPv4 to IPv6. 300 7. IPv4 Address Literals 302 IPv4 addresses are often used as resource locators. For example, it 303 is common to encounter URLs containing IPv4 address literals on web 304 sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address 305 literals may be published on media other than web sites, and may 306 appear in various forms other than URLs. For the operating systems 307 which exhibit the behavior described in 308 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an 309 increase in the broadcast ARP traffic, which may be undesirable. 311 PROBLEM 14: IPv6-only hosts are unable to access resources identified 312 by IPv4 address literals. 314 8. Managing Router Identifiers 316 IPv4 addresses are often conventionally chosen to number a router ID, 317 which is used to identify a system running a specific protocol. The 318 common practice of tying an ID to an IPv4 address gives much 319 operational convenience. A human-readable ID is easy for network 320 operators to deal with, and it can be auto-configured, saving the 321 work of planning and assignment. It is also helpful to quickly 322 perform diagnosis and troubleshooting, and easy to identify the 323 availability and location of the identified router. 325 PROBLEM 15: In an IPv6 only network, there is no IP address that can 326 be directly used to number a router ID. IDs have to be 327 planned individually to meet the uniqueness requirement. 328 Tying the ID directly to an IP address which yields 329 human-friendly, auto-configured ID that helps with 330 troubleshooting is not possible. 332 9. IANA Considerations 334 None. 336 10. Security Considerations 338 It is believed that none of the problems identified in this draft are 339 security issues. 341 11. Acknowledgements 343 Thanks in particular to Andrew Yourtchenko, Jordi Palet Martinez, 344 Lee Howard, Nejc Skoberne, and Wes George for their thorough reviews 345 and comments. 347 Special thanks to Marc Blanchet who was the driving force behind this 348 work and to Jean-Philippe Dionne who helped with the initial version 349 of this document. 351 12. Informative References 353 [BBF.TR242] 354 Broadband Forum, "TR-242: IPv6 Transition Mechanisms for 355 Broadband Networks", August 2012. 357 [Huston2012] 358 Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual 359 Stack Behaviour and IPv6 Quality", April 2012. 361 [I-D.fleischhauer-ipv4-addr-saving] 362 Fleischhauer, K. and O. Bonness, "On demand IPv4 address 363 provisioning in Dual-Stack PPP deployment scenarios", 364 draft-fleischhauer-ipv4-addr-saving-05 (work in progress), 365 September 2013. 367 [I-D.wing-behave-http-ip-address-literals] 368 Wing, D., "Coping with IP Address Literals in HTTP URIs 369 with IPv6/IPv4 Translators", draft-wing-behave-http-ip- 370 address-literals-02 (work in progress), March 2010. 372 [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] 373 Yourtchenko, A. and O. Owen, "Disable "Proxy ARP for 374 Everything" on IPv4 link-local in the presence of IPv6 375 global address", draft-yourtchenko-ipv6-disable- 376 ipv4-proxyarp-00 (work in progress), May 2013. 378 [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- 379 Configuration in IPv4 Clients", RFC 2563, May 1999. 381 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 382 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 383 3493, February 2003. 385 [RFC3789] Nesser, P. and A. Bergstrom, "Introduction to the Survey 386 of IPv4 Addresses in Currently Deployed IETF Standards 387 Track and Experimental Documents", RFC 3789, June 2004. 389 [RFC3790] Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in 390 Currently Deployed IETF Internet Area Standards Track and 391 Experimental Documents", RFC 3790, June 2004. 393 [RFC3791] Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in 394 Currently Deployed IETF Routing Area Standards Track and 395 Experimental Documents", RFC 3791, June 2004. 397 [RFC3792] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 398 Currently Deployed IETF Security Area Standards Track and 399 Experimental Documents", RFC 3792, June 2004. 401 [RFC3793] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 402 Currently Deployed IETF Sub-IP Area Standards Track and 403 Experimental Documents", RFC 3793, June 2004. 405 [RFC3794] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 406 Currently Deployed IETF Transport Area Standards Track and 407 Experimental Documents", RFC 3794, June 2004. 409 [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in 410 Currently Deployed IETF Application Area Standards Track 411 and Experimental Documents", RFC 3795, June 2004. 413 [RFC3796] Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in 414 Currently Deployed IETF Operations & Management Area 415 Standards Track and Experimental Documents", RFC 3796, 416 June 2004. 418 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 419 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 420 2005. 422 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 423 Multicast Name Resolution (LLMNR)", RFC 4795, January 424 2007. 426 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 427 Dual-Stack Hosts", RFC 6555, April 2012. 429 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 430 February 2013. 432 [Zeeb] "FreeBSD Snapshots without IPv4 support", 433 . 435 Annex A. Solution Ideas 437 A.1. Remotely Disabling IPv4 439 A.1.1. Indicating that IPv4 connectivity is unavailable 441 One way to address these issues is to send a signal to a dual-stack 442 node that IPv4 connectivity is unavailable. Given that IPv4 shall be 443 off, the message must be delivered through IPv6. 445 A.1.2. Disabling IPv4 in the LAN 447 One way to address these issues is to send a signal to a dual-stack 448 node that auto-configuration of IPv4 addresses is undesirable, or 449 that direct IPv4 communication between nodes on the same link should 450 not take place. 452 A signalling protocol equivalent to the one from [RFC2563] but over 453 IPv6 is necessary, using either Router Advertisements or DHCPv6. 455 Furthermore, it could be useful to have L2 switches snoop this 456 signalling and automatically start filtering IPv4 traffic as a 457 consequence. 459 Finally, it could be useful to publish guidelines on how to safely 460 block IPv4 on an L2 switch. 462 A.2. Client Connection Establishment Behavior 464 Recommendations on client connection establishment behavior that 465 would facilitate IPv4 sunsetting would be appropriate. 467 A.3. Disabling IPv4 in Operating System and Applications 469 It would be useful for the IETF to provide guidelines to programmers 470 on how to avoid creating dependencies on IPv4, how to discover 471 existing dependencies, and how to eliminate them. It would be useful 472 if operating systems provide functions for users to see what 473 applications uses legacy IPv4-only APIs, so they can know it better 474 whether they can turn off IPv4 completely. Having programs and 475 operating systems that behave well in an IPv6-only environment is a 476 prerequisite for IPv4 sunsetting. 478 A.4. On-Demand Provisioning of IPv4 Address 480 As the sunset of IPv4 in NAS, parts of hosts no longer need IPv4 481 address. IPv4 address resources in NAS appears surplus, NAS 482 should obtain the unoccupied IPv4 address, generate a request 483 and send it to the address management system to release those IPv4 484 address resource. Meanwhile, NAS needs more IPv6 address resources for 485 the host transiting from IPv4 to IPv6. NAS judges whether the usage 486 status of the IPv6 address pool satisfies certain condition. If the 487 IPv6 address utilization is too high, the NAS generates 488 a resource request containing the IPv6 address information that needs 489 to be applied and sends it to the address management system. When the 490 address management system receives the IPv6 address resource request, 491 it allocates IPv6 address from its assignable IPv6 address resource 492 according the information of request, then sends a response message 493 with IPv6 address pools allocated for this NAS back to the NAS. Then 494 the NAS receives the response and get the information of allocated IPv6 495 address resource. 497 A.5. Managing Router Identifiers 499 Router IDs can be manually planned, possibly with some hierarchy or 500 design rule, or can be created automatically. A simple way of 501 automatic creation is to generate pseudo-random numbers, and one can 502 use another source of data such as the clock time at boot or 503 configuration time to provide additional entropy during the 504 generation of unique IDs. Another way is to hash an IPv6 address 505 down to a value as ID. The hash algorithm is supposed to be known 506 and the same across the domain. Since typically the number of 507 routers in a domain is far smaller than the value range of IDs, the 508 hashed IDs are hardly likely to conflict with each other, as long as 509 the hash algorithm is not designed too badly. It is necessary to be 510 able to override the automatically created value, and desirable if 511 the mechanism is provided by the system implementation. 513 If the ID is created from IPv6 address, e.g. by hashing from an IPv6 514 address, then naturally it has relationship with the address. If the 515 ID is created regardless of IP address, one way to build association 516 with IPv6 address is to embed the ID into an IPv6 address that is to 517 be configured on the router, e.g. use a /96 IPv6 prefix and append it 518 with a 32-bit long ID. One can also use some record keeping 519 mechanisms, e.g. text file, DNS or other provisioning system like 520 network management system to manage the IDs and mapping relations 522 with IPv6 addresses, though extra record keeping does introduce 523 additional work. 525 Authors' Addresses 527 Will(Shucheng) Liu 528 Huawei Technologies 529 Bantian, Longgang District 530 Shenzhen 518129 531 China 533 Email: liushucheng@huawei.com 535 Weiping Xu 536 Huawei Technologies 537 Bantian, Longgang District 538 Shenzhen 518129 539 China 541 Email: xuweiping@huawei.com 543 Cathy Zhou 544 Huawei Technologies 545 Bantian, Longgang District 546 Shenzhen 518129 547 China 549 Email: cathy.zhou@huawei.com 551 Tina Tsou 552 Philips Lighting 553 United States of America 555 Email: tina.tsou@philips.com 557 Simon Perreault 558 Jive Communications 559 Quebec, QC 560 Canada 562 Email: sperreault@jive.com 564 Peng Fan 565 Beijing 566 China 568 Email: fanp08@gmail.com 570 Rong Gu 571 China Mobile 572 32 Xuanwumen West Ave, Xicheng District 573 Beijing 100053 574 China 576 Email: gurong_cmcc@outlook.com 578 Chen Li 579 China Telecom 580 No.118 Xizhimennei street, Xicheng District 581 Beijing 100035 582 China 584 Email: lichen.bri@chinatelecom.cn