idnits 2.17.1 draft-jjmb-v6ops-ietf-ipv6-only-incremental-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 30, 2017) is 2492 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Brzozowski 3 Internet-Draft Comcast Cable 4 Intended status: Best Current Practice D. Schinazi 5 Expires: January 1, 2018 S. Cheshire 6 Apple Inc. 7 L. Colitti 8 E. Kline 9 J. Linkova 10 Google 11 M. Keane 12 Microsoft 13 P. Saab 14 Facebook 15 June 30, 2017 17 Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings 18 draft-jjmb-v6ops-ietf-ipv6-only-incremental-00 20 Abstract 22 The purpose of this document is to provide a blueprint and guidance 23 for deploying IPv6-only Wi-Fi at IETF meetings. This document 24 outlines infrastructure and operational guidance that operators 25 should consider when deploying IPv6-only networks using NAT64 and 26 DNS64 to support communication to legacy IPv4-only services. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 1, 2018. 45 Copyright Notice 47 Copyright (c) 2017 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Network Infrastructure . . . . . . . . . . . . . . . . . 4 66 3. Network Services . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. User Equipment . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Host Address Assignment and Configuration . . . . . . . . 7 72 4.2. IPv4 support . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Network Management . . . . . . . . . . . . . . . . . . . . . 8 74 6. Telemetry and Monitoring . . . . . . . . . . . . . . . . . . 9 75 7. Support for User Applications and Services . . . . . . . . . 10 76 8. Support and Operations . . . . . . . . . . . . . . . . . . . 10 77 8.1. Reporting Issues (Ticketing) . . . . . . . . . . . . . . 10 78 8.2. Interactive Support . . . . . . . . . . . . . . . . . . . 11 79 9. Known Client-side Issues . . . . . . . . . . . . . . . . . . 11 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Security Considerations . . . . . . . . . . . . . . . . 12 82 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 12. Related Industry Efforts . . . . . . . . . . . . . . . . . . 12 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 13.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 The purpose of this document is to provide a blueprint and guidance 92 for deploying IPv6-only Wi-Fi at IETF meetings. This document 93 outlines infrastructure and operational guidance that operators 94 should consider when deploying IPv6-only networks using NAT64 and 95 DNS64 to support communication to legacy IPv4-only services. 97 One of the main strengths of the IETF has always been an insistence 98 on running code. As such, IETF meetings were one of the first 99 deployments of a dual-stack network to help test the first 100 implementations of IPv6. Many years later, as several networks are 101 shifting towards IPv6-only, it is the responsibility of the IETF to 102 lead the trend and make their main network IPv6-only. 104 This document outlines the requirements and design principles for an 105 IPv6-only network infrastructure that includes support for IPv4-only 106 content. It also discusses techniques and requirements for network 107 management, telemetry, and the operations and support for the 108 IPv6-only network. Recommendations and best practices for operations 109 and support will be provided, however, alternate approaches may be 110 utilized. Disabling or removal of IPv4 stacks is out of scope for 111 this document. This document focuses on the explicit provisioning of 112 IPv6-only using NAT64 [RFC6146] and DNS64 [RFC6147] to access 113 IPv4-only content and services. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 122 2. Design Principles 124 2.1. Network Infrastructure 126 The following are specific network design details that are minimally 127 required to support an IPv6-only network that utilize NAT64 and 128 DNS64. The following have been drawn from real deployment scenarios 129 for large scale uses of IPv6-only with NAT64 and DNS64. The 130 parameters specified here are specific to providing IPv6-only 131 connectivity. It is assumed that IPv6-only is provisioned and that 132 IPv4 stacks remain active on network and host interfaces. The 133 disabling or removal of IPv4 stacks from hosts or routers is out of 134 scope for this document. As such, it is important to note that link 135 local IPv4 [RFC3927] will likely remain active and will appear on 136 hosts and network infrastructure. 138 The following section outlines the requirement to provisioning 139 IPv6-only. We minimally assume that SLAAC will be utilized, however, 140 for completeness the parameters required for DHCPv6 [RFC3315] and 141 [RFC3736] are also provided: 143 o IPv6-only hosts are expected to be provisioned with IPv6-only 144 connectivity, however, link local IPv4 is likely to be present. 146 o RA interval is RECOMMENDED to be minimally set to 600 seconds per 147 the guidance outlined in [RFC7772]. 149 o Support for solicited unicast router advertisements are also 150 recommended per [RFC7772] 152 o At least one prefix information option (PIO) MUST be included in 153 router advertisements, the transmitted PIO MUST correspond to the 154 IPv6 prefix that is valid for a given IPv6 link. 156 o The use of SLAAC [RFC4862] MUST be signalled by the network, 157 specifically for each transmitted PIO the A bit MUST be set to 158 one. 160 o DHCPv6 support SHOULD be included to support legacy operating 161 systems that do not support DNS RA options but is not required. 162 Whether stateless or stateful DHCPv6 is used, both the DNS Server 163 IPv6 address and DNS Search List options [RFC8106] MUST minimally 164 be included. The DNS server IPv6 address(es) MUST be those used 165 for DNS64. It is RECOMMENDED that these values be identical to 166 those used in the IPv6 router advertisements that include the DNS 167 options [RFC8106]. If DHCPv6 support is deployed, stateless 168 DHCPv6 MUST minimally be available. 170 o IPv6 router advertisements MUST include the DNS options [RFC8106]. 171 Both the DNS Server IPv6 address(es) and DNS Search List are 172 REQUIRED. If DHCPv6 support is deployed the values sent here for 173 DNS RA options are RECOMMENDED to match those sent via DHCPv6. 175 To ensure seamless and to support an incremental deployment of 176 IPv6-only access to legacy dual stack infrastructure should remain 177 available. The following are recommended approaches that may be 178 considered to achieve the same. 180 The deployment of IPv6-only with NAT64 and DNS64 may very well help 181 to identify applications, services, or use cases that are not 182 entirely compatible with the same. It is therefore important to 183 ensure that users of IP networks, whether wired or wireless, have 184 access to legacy dual stack infrastructure as a fallback. For 185 wireless network it is recommend to have a secondary SSID labelled 186 accordingly, e.g. example-ssid-dual-stack or example-ssid-legacy. 187 For wired network connectivity having secondary ports that are dual 188 stack enabled is also recommended. Note that while it is recommended 189 to ensure the presence of a fallback network, the goal remains to 190 make the IPv6-only network the primary network. 192 This document assumes that dual stack connectivity is available by 193 default and that IPv4-only connectivity is no longer supported. As 194 such, it is out of scope for this document to outline fallback or 195 access to legacy connectivity that is IPv4-only. 197 3. Network Services 199 The following network services are required for an IPv6-only where 200 support for and access to IPv4 content, services, and applications 201 are required. 203 3.1. DNS64 205 The following recommendations apply to the use and deployment of 206 DNS64: 208 o Use of the well known DNS64 prefix per [RFC6052] 210 o It is also recommended that query logging be enabled for DNS64, 211 performance impacts of query logging must be noted but are largely 212 out of scope for this document. Query logging is essential to 213 determine the volume and make up of DNS queries and replies that 214 are are specific to DNS64 and IPv4-only content, services, and 215 applications. 217 3.2. NAT64 219 The following recommendations apply to the use and deployment of 220 NAT64: 222 o DNS64 is a critical aspect to direct requests from IPv6-only hosts 223 to a NAT64 service. 225 o NAT64 configurations vary widely, port allocation techniques are 226 largely out of scope for this document. One-to-one (1:1) mappings 227 can be used to allocate an IPv4 address per connected device or 228 alternatively blocks of IPv4 ports can also be assigned per 229 device, each has different properties. It is generally 230 recommended to allocate IPv4 ports per device in an effort to 231 maximize IPv4 utilization for NAT64. 233 3.3. DHCPv6 235 Support for DHCPv6 may be required in some deployments. If required, 236 parameters pertaining to IPv6 router discovery may require 237 adjustment. The following outlines the guidance specific to the use 238 of DHCPv6: 240 o Stateless DHCPv6 SHOULD be supported to facilitate the 241 transmission of DNS servers IPv6 address(es) and DNS search lists 242 to legacy hosts that do not support DNS RA options. 244 o Stateful DHCPv6 for address assignment MAY be supported, but is 245 not required. If stateful DHCPv6 is used the DNS parameters 246 mentioned above MUST be included. 248 o If, at some future date, support for IPv6 prefix delegation 249 becomes necessary, stateful DHCPv6 will likely be mandatory 250 (Future Work (Section 11)). The details of IPv6 prefix delegation 251 are out of scope for this document. 253 4. User Equipment 255 4.1. Host Address Assignment and Configuration 257 o Hosts MUST support SLAAC. 259 o Hosts SHOULD support DNS RA options [RFC8106] for the acquisition 260 of DNS server IPv6 addresses and a DNS Search List. 262 o Hosts MAY support DHCPv6 for address acquisition, the use of 263 DHCPv6 for address acquisition is not prohibited. 265 o DHCPv6 option to configure DNS server option 23 and domain search 266 list option 24 [RFC3646] address MUST be implemented if DHCPv6 is 267 to be utilized. 269 4.2. IPv4 support 271 The IPv4 stacks of hosts MAY remain enabled, which means that Link 272 Local IPv4 [RFC3927] (169.254/16) addresses MAY continue to be 273 present and in use. Disabling of the IPv4 stack of hosts is out of 274 scope for this document. 276 Host operating systems SHOULD provide a means for applications to 277 easily connect to IPv4-only servers by using the NAT64/DNS64. While 278 modern applications simply need to make AAAA queries and connect to 279 the resulting IPv6 address, operating systems SHOULD provide simple 280 ways for applications to do so or even connect to IPv4 literals in 281 the absence of host names. Possible solutions include 464XLAT 282 [RFC6877], "Bump-in-the-Host" [RFC6535] and Happy Eyeballs v2 [HEv2]. 284 Finally, it is RECOMMENDED that support for DHCPv4 be explicitly 285 suppressed in particular to prevent the inadvertent assignment of 286 IPv4 addresses on networks that do not have a valid IPv4 egress. 287 DHCPv4 servers, rogue or otherwise, could adversely impact the 288 experience of end users of the IPv6-only network. 290 5. Network Management 292 The focus of this document is user equipment and hosts. The network 293 and network service requirements are oriented around providing 294 IPv6-only connectivity that allows for the use of NAT64 and DNS64 to 295 maintain reachability to IPv4-only content, applications, and 296 services. Operations and management of the underlying network is 297 technically out of scope for this document, however, given the 298 relevance of the same to the focus of this draft some guidance is 299 being provided. 301 Strictly speaking the primary requirement for the underlying network 302 is that IPv6 is supported along with the services required to enable 303 the use of NAT64 and DNS64. This suggests that the underlying 304 network could in fact be dual stack for management and operations. 305 It is required that the provisioning of IPv4 for user equipment and 306 host connectivity not be supported. User equipment or host facing 307 interfaces MUST NOT acquire non-link-local IPv4 addresses or IPv4 DNS 308 server addresses. Additionally, the network MUST NOT respond to 309 DHCPv4 requests or DNS queries sent over IPv4. 311 Given the above, within a given VLAN it is possible and likely that 312 IPv4 may be observed, present, and possibly used. It is out of scope 313 for this document to prevent the use of IPv4 entirely. 315 Depending on the level of readiness IPv6-only network management may 316 or may not be possible. Network management and operations includes 317 but is not limited to the following: 319 o Remote access to network infrastructure via SSH or telnet 321 o Remote SNMP communications 323 o Remote NETCONF communications 325 o Remote Syslog communications 327 While it is strongly recommended that all network management and 328 operations be performed over IPv6-only it is not strictly required. 329 However, it is important to note that the presence and use of IPv4 330 for network management and operations must not impede or impact the 331 use of IPv6-only with NAT64 and DNS64. 333 6. Telemetry and Monitoring 335 At this point in time, IPv6-only networks with no IPv4 support at all 336 are still not widespread and may expose issues in host operating 337 systems or applications. It is therefore recommended that telemetry 338 summarizing how hosts are being provisioned and accessing the 339 Internet be collected and analyzed. In order to preserve the privacy 340 of users of the network, it is paramount that connectivity 341 information (e.g. DNS64 records) cannot be correlated with 342 individual client nodes. 344 We can measure how hosts: 346 o Configure IPv6 addresses (SLAAC, DHCPv6) and which ones they use 348 o Configure DNS server addresses (DNS RA options vs DHCPv6) 350 We can measure what percentage of the traffic: 352 o Uses native IPv6 354 o Uses NAT64 356 Recording the most common hostnames that require the DNS64 would also 357 allow operators to establish a list of the most prominent IPv4-only 358 services. 360 Observing the TCP/UDP ports used by applications that still leverage 361 IPv4 link-local on an IPv6-only network will also help prepare for 362 the time when routers stop supporting IPv4 communications altogether. 364 Given that some users may have devices running legacy IPv4-only 365 software, the network should provide a different fallback network 366 that is dual-stack. It is worth measuring the number of users that 367 switch to this network, and possibly use an anonymous survey asking 368 users what software failure caused them to switch. Additionally, the 369 fallback network SHOULD use different authentication credentials per 370 meeting (such as SSID) to make sure a failure causing a user to 371 switch does not mean they will stay on the fallback network forever. 373 7. Support for User Applications and Services 375 Following is a list of commonly used applications and services that 376 are expected to operate, without incident, when used in an IPv6-only 377 environment that utilizes NAT64 and DNS64. The list below is not 378 exhaustive. 380 o VPN 382 o Chat 384 o Email 386 o SSH/Telnet 388 o Git 390 o Voice 392 8. Support and Operations 394 Most every network has customers or end users of some sort, therefore 395 it essential to ensure that end users or consumers of the have means 396 to do the following while transitions are occurring in networks and 397 related infrastructure. One key item referenced earlier is the 398 availability of temporary fallback networks that support legacy 399 communications. 401 The following outline additional items that end users must have 402 available to communicate with network operators. All of the items 403 below must be available via dual stack connectivity. 405 8.1. Reporting Issues (Ticketing) 407 Tools and systems that can be used to report issues with 408 applications, services, or content must be available for end-users. 409 Network and systems operators are responsible for acknowledging and 410 classifying issues and ultimately ensuring that the same are properly 411 addressed. Specifically to this document "fixed" is meant to imply 412 that proper support for IPv6 is available. In some cases network and 413 system operators may need to implement temporary workarounds to 414 ensure that end users can access the desired content, application, or 415 service. 417 In order for users experiencing IPv6-specific issues to be able to 418 report them, the ticketing system MUST also be reachable over the 419 dual-stack fallback network. The existence of the fallback network 420 SHOULD also be made clear to users ahead of time. In order to help 421 narrow down issues, the ticketing system SHOULD ask the user whether 422 the issue is specific to IPv6-only and whether they have experienced 423 the issue or a different outcome on the fallback network. 425 8.2. Interactive Support 427 Interactive support is often desired in lieu or in conjunction with 428 traditional support models like trouble ticket creation. It is 429 recommended that interactive support be available via real time and 430 near real time mechanisms like Slack or electronic mail (e-mail). 432 9. Known Client-side Issues 434 Following are known client side issues that are specific to the 435 deployment of IPv6-only networks and/or the use of NAT64/DNS64: 437 o Use of literal IPv4 addresses - the use of literal IPv4 addresses 438 is a known issue given the approach that is documented in this 439 I-D. Addressing the use of literal IPv4 addresses is out of scope 440 for this document. 442 o Applications that explicitly require IPv4 by only performing AAAA 443 queries or restricting the type of underlying socket they use. 445 o Unreachable but valid AAAA RR in the DNS - in some cases a valid 446 AAAA RR is returns by the DNS, however, if the same is unreachable 447 or is not configured the presence of the same will prevent a DNS64 448 query which in turn prevents the use of the NAT64 to reach the 449 target host references by the address in the AAAA DNS RR. 451 10. IANA Considerations 453 This memo includes no request to IANA. 455 10.1. Security Considerations 457 The vastness of the IPv6 address space often makes it more difficult 458 to scan the same unlike legacy IPv4-only or dual stack IP networks. 459 It is conceivable that IPv6-only network represent a reduction in 460 attack surface area which in turn could be viewed a security 461 improvement compared to IPv4-only or dual stack IP networks. 463 Given the criticality of the DNS64 for reachability to the NAT64, 464 poisoning of one or both could represent a vector for the attack of 465 the DNS64 and NAT64 which could in turn impact the end user 466 experience. Worse poisoning of the DNS64 and/or NAT64 could result 467 in redirection of end use devices to malicious hosts. It is likely 468 that this vulnerability is no greater in IPv6-only networks utilizing 469 DNS64 and NAT64 compared to traditional IPv4-only or dual stack 470 networks. 472 11. Future Work 474 The following items are out of scope for this document, however, the 475 following are listed as future work items specific to incremental 476 IPv6-only deployments: 478 o Support for IPv6 prefix delegation 480 o Disabling IPv4 stacks at some point in the future 482 o Fully deprecating the fallback legacy IPv4 network 484 12. Related Industry Efforts 486 o Comcast new building and IPv6-only (John Jason Brzozowski 487 ) 489 o Microsoft corporate IT IPv6-only (Marcus Keane 490 ) 492 o Google (Jen Linkova ) 494 13. References 496 13.1. Normative References 498 [HEv2] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2", 499 Work in Progress, draft-ietf-v6ops-rfc6555bis, June 2017. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 507 C., and M. Carney, "Dynamic Host Configuration Protocol 508 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 509 2003, . 511 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 512 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 513 DOI 10.17487/RFC3646, December 2003, 514 . 516 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 517 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 518 April 2004, . 520 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 521 Address Autoconfiguration", RFC 4862, 522 DOI 10.17487/RFC4862, September 2007, 523 . 525 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 526 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 527 DOI 10.17487/RFC6052, October 2010, 528 . 530 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 531 NAT64: Network Address and Protocol Translation from IPv6 532 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 533 April 2011, . 535 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 536 Beijnum, "DNS64: DNS Extensions for Network Address 537 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 538 DOI 10.17487/RFC6147, April 2011, 539 . 541 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 542 Consumption of Router Advertisements", BCP 202, RFC 7772, 543 DOI 10.17487/RFC7772, February 2016, 544 . 546 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 547 "IPv6 Router Advertisement Options for DNS Configuration", 548 RFC 8106, DOI 10.17487/RFC8106, March 2017, 549 . 551 13.2. Informative References 553 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 554 Configuration of IPv4 Link-Local Addresses", RFC 3927, 555 DOI 10.17487/RFC3927, May 2005, 556 . 558 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 559 Using "Bump-in-the-Host" (BIH)", RFC 6535, 560 DOI 10.17487/RFC6535, February 2012, 561 . 563 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 564 Combination of Stateful and Stateless Translation", 565 RFC 6877, DOI 10.17487/RFC6877, April 2013, 566 . 568 Authors' Addresses 570 John Jason Brzozowski 571 Comcast Cable 572 1701 John F. Kennedy Blvd. 573 Philadelphia, PA 574 USA 576 Email: john_brzozowski@cable.comcast.com 578 David Schinazi 579 Apple Inc. 580 1 Infinite Loop 581 Cupertino, California 95014 582 US 584 Email: dschinazi@apple.com 585 Stuart Cheshire 586 Apple Inc. 587 1 Infinite Loop 588 Cupertino, California 95014 589 USA 591 Email: cheshire@apple.com 593 Lorenzo Colitti 594 Google 596 Email: lorenzo@google.com 598 Erik Kline 599 Google 601 Email: ek@google.com 603 Jen Linkova 604 Google 606 Email: furry@google.com 608 Marcus Keane 609 Microsoft 611 Email: marcus.keane@microsoft.com 613 Paul Saab 614 Facebook 616 Email: ps@fb.com