idnits 2.17.1 draft-gont-6man-address-usage-recommendations-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2598 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) == Missing Reference: 'TBD' is mentioned on line 467, but not defined ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ula-usage-considerations-02 == Outdated reference: A later version (-04) exists of draft-gont-6man-non-stable-iids-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Best Current Practice G. Gont 5 Expires: September 14, 2017 SI6 Networks 6 M. Garcia Corbo 7 SITRANS 8 C. Huitema 9 Private Octopus Inc. 10 March 13, 2017 12 IPv6 Address Usage Recommendations 13 draft-gont-6man-address-usage-recommendations-02 15 Abstract 17 This document analyzes the security and privacy implications of IPv6 18 addresses based on a number of properties such as address scope, 19 stability, and usage type. It analyzes what properties are desirable 20 for some popular scenarios, and provides advice regarding the 21 configuration and usage of such addresses. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 14, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Testing for the Presence of Node in the Network . . . . . 4 61 3.2. Unexpected Address Discovery . . . . . . . . . . . . . . 4 62 3.3. Availability Outside the Expected Scope . . . . . . . . . 4 63 3.4. Limited Address Selection API . . . . . . . . . . . . . . 5 64 4. Predictability Considerations . . . . . . . . . . . . . . . . 5 65 5. Address Scope Considerations . . . . . . . . . . . . . . . . 6 66 6. Address Stability Considerations . . . . . . . . . . . . . . 6 67 7. Usage Type Considerations . . . . . . . . . . . . . . . . . . 8 68 8. Advice on IPv6 Address Configuration . . . . . . . . . . . . 9 69 9. Advice on IPv6 Address Usage . . . . . . . . . . . . . . . . 9 70 10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 14.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 IPv6 hosts typically configure a number of IPv6 addresses, which may 82 differ in multiple aspects, such as address scope and stability (e.g. 83 stable addresses vs. temporary addresses). For example, a host may 84 configure one stable and one temporary address per each 85 autoconfiguration prefix advertised on the local network. The 86 addresses to be configured typically depend on local system policy 87 configuration, with the aforementioned policy being static and 88 irrespective of the network the host attaches to. 90 There are three parameters that affect the security and privacy 91 properties of an address: 93 o Scope 95 o Stability 96 o Usage type (client-like "outgoing connections" vs. server-like 97 "incoming connections") 99 Section 4, Section 5, Section 6, and Section 7 discuss the security 100 and privacy implications (and associated tradeoffs) of the scope, 101 stability and usage type properties of IPv6 addresses, respectively. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Problem Statement 111 Applications use system API's to select the IPv6 addresses that will 112 be used for incoming and outgoing connections. This choices have 113 consequences in terms of privacy, security, stability and 114 performance. 116 Default Address Selection for IPv6 is specified in [RFC6724]. The 117 selection starts with a set of potential destination addresses, such 118 as returned by getaddrinfo(), and the set of potential source 119 addresses currently configured for the selected interfaces. For each 120 potential destination address, the algorithm will select the source 121 address that provides the best route to the destination, while 122 choosing the appropriate scope and preferring temporary addresses. 123 The algorithm will then select the destination address, while giving 124 a preference to reachable addresses with the smallest scope. The 125 selection may be affected by system settings. 127 We note that [RFC6724] only applies for outgoing connections, such as 128 those made by clients trying to contact services. When devices 129 provide a service, the common pattern is to just wait for connections 130 over all addresses configured on the device. For example, 131 applications using the Sockets API will commonly bind() the listening 132 socket to undefined address. This long-established behavior is 133 appropriate for devices providing public services, but may have 134 unexpected results for devices providing semi-private services, such 135 as various forms of peer-to-peer or local-only applications. 137 This behavior leads to three problems: device tracking, discussed in 138 Section 3.1; unexpected address discovery, discussed in Section 3.2; 139 and availability outside the expected scope, discussed in 140 Section 3.3. These problems are caused in part by the limitations of 141 available address selection API, presented in Section 3.4. 143 3.1. Testing for the Presence of Node in the Network 145 The stable addresses recommended in [RFC8064] use stable IID defined 146 in [RFC7217]. One key part of that algorithm is that if a device 147 connects to a given network at different times, it will always 148 configure the same IPv6 addresses on that network. If the device 149 hosts a service ready to accept connections on that stable address, 150 adversaries can test the presence of the device on the network by 151 attempting connections to that stable address. Stable addresses used 152 by listening services will thus enable testing whether a specific 153 device is returning to a particular network, which in many cases will 154 be considered a privacy issue. 156 3.2. Unexpected Address Discovery 158 Systems like DNS-Based Service Discovery [RFC6763] allows clients to 159 discover services within a limited scope, that can be defined by a 160 domain name. These services are not advertised outside of that 161 scope, and thus do not expect to be discovered by random parties on 162 the Internet. Yet it appears that such services are easily 163 discoverable if they listen for connections to IPv6 addresses that a 164 client process also uses as source address when connecting to remote 165 servers. 167 An example of such unexpected discovery is described in [Hein]. A 168 network manager observed scanning traffic directed at the 169 temporary addresses of local devices. Analysis shows that the 170 scanners learned the addresses by observing the device contact an 171 NTP service ([RFC5905]). The remote scanning was possible because 172 the local devices were also accepting connections directed to the 173 temporary addresses. 175 It is obvious from the example that the "attack surface" of the 176 services is increased because it listens to the same IPv6 addresses 177 that are also used by clients for outgoing communications with remote 178 systems. But the overlap between "client" and "server" addresses is 179 only one part of the problem. Suppose that a devices hosts both a 180 video game and a home automation application. The video game users 181 will be able to discover the IPv6 address of the game server. If the 182 home automation server listens to the same IPv6 addresses, it is now 183 exposed to connection attempts by all these users. That, too, 184 increases the attack surface of the home automation server. 186 3.3. Availability Outside the Expected Scope 188 The IPv6 addressing architecture [RFC4291] defines multiple address 189 scopes. In practice, devices are often configured with globally 190 reachable unicast addresses, link local addresses, and Unique Local 191 IPv6 Unicast Addresses (ULA) [RFC4193]. Availability outside the 192 expected scope happens when a service is expected to be only 193 available in some local scope, but inadvertently becomes available to 194 remote parties. That could happen for example if a service is meant 195 to be available only on a given link, but becomes reachable through 196 ULA or through globally reachable addresses, or if a service is meant 197 to be available only inside some organization's perimeter and becomes 198 reachable through globally reachable addresses. It will happen in 199 particular if a service intended for some local scope is programmed 200 to bind to "unspecified" addresses, which in practice means every 201 address configured for the device. 203 3.4. Limited Address Selection API 205 Application developers using the Sockets API can "bind" a listening 206 socket to a specific address, and ensure that the application is only 207 reachable through that address. In theory, careful selection of the 208 binding address could mitigate the three problems mentioned above. 209 Binding services to temporary address could mitigate device tracking. 210 Binding different services to different addresses could mitigate 211 unexpected discovery. Binding services to link local addresses or 212 ULA could mitigate availability outside the expected scope. However, 213 explicitly managing addresses adds significant complexity to the 214 application development. It requires that application developers 215 master addressing architectures subtleties, and implement logic that 216 reacts adequately to connectivity events and address changes. 217 Experience shows that application developers would probably prefer 218 some much simpler solution. 220 In addition, we should note that many application developers use high 221 level APIs that listen to TLS, HTTP, or some other application 222 protocol. These high level APIs seldom provide detailed access to 223 specific IP addresses, and typically default to listening to all 224 available addresses. 226 4. Predictability Considerations 228 Predictable IPv6 addresses result in a number of security and privacy 229 implications. For example, [Barnes2012] discusses how patterns in 230 network prefixes can be leveraged for IPv6 address scanning. On the 231 other hand, [RFC7707], [RFC7721] and [RFC7217] discuss the security 232 and privacy implications of predictable IPv6 Interface Identifiers 233 (IIDs). 235 Given the aforementioned previous work in this area, and the formal 236 specification update produced by [RFC8064], we expect (and assume in 237 the rest of this document) that implementations have replaced any 238 schemes that produce predictable addresses with alternative schemes 239 that avoid such patterns (e.g., RFC7217 in replacement of the 240 traditional SLAAC addresses that embed link-layer addresses). 242 5. Address Scope Considerations 244 The IPv6 address scope can, in some scenarios, limit the attack 245 exposure of a node as a result of the implicit isolation provided by 246 a non-global address scope. For example, a node that only employs 247 link-local addresses may, in principle, only be exposed to attack 248 from other nodes in the local link. Hosts employing only Unique 249 Local Addresses (ULAs) may be more isolated from attack than those 250 employing Global Unicast Addresses (GUAs), assuming that proper 251 packet filtering is enforced at the network edge. 253 The potential protection provided by a non-global addresses should 254 not be regarded as a complete security strategy, but rather as a form 255 of "prophylactic" security (see 256 [I-D.gont-opsawg-firewalls-analysis]). 258 We note that the use of non-global addresses is usually limited to a 259 reduced type of applications/protocols that e.g. are only meant to 260 operate on a reduced scope, and hence their applicability may be 261 limited. 263 A discussion of ULA usage considerations can be found in 264 [I-D.ietf-v6ops-ula-usage-considerations]. 266 6. Address Stability Considerations 268 The stability of an address has two associated security/privacy 269 implications: 271 o Ability of an attacker to correlate network activity 273 o Exposure to attack 275 For obvious reasons, an address that is employed for multiple 276 communication instances allows the aforementioned network activities 277 to be correlated. The longer an address is employed (i.e., the more 278 stable it is), the longer such correlation will be possible. In the 279 worst-case scenario, a stable address that is employed for multiple 280 communication instances over time will allow all such activities to 281 be correlated. On the other hand, if a host were to generate (and 282 eventually "throw away") one new address for each communication 283 instance (e.g., TCP connection), network activity correlation would 284 be mitigated. 286 NOTE: the use of constant IIDs (as in traditional SLAAC) result in 287 addresses that, while not constant as a whole (since the prefix 288 changes), contain a globally-unique value that leaks out the node 289 "identity". Such addresses result in the worst possible security 290 and privacy implications, and their use has been deprecated by 291 [RFC8064]. 293 Typically, when it comes to attack exposure, the longer an address is 294 employed the longer an attacker is exposed to attacks (e.g. an 295 attacker has more time to find the address in the first place 296 [RFC7707]). While such exposure is traditionally associated with the 297 stability of the address, the usage type of the address (see 298 Section 7) may also have an impact on attack exposure. 300 A popular approach to mitigate network activity correlation is the 301 use of "temporary addresses" [RFC4941]. Temporary addresses are 302 typically configured and employed along with stable addresses, with 303 the temporary addresses employed for outgoing communications, and the 304 stable addresses employed for incoming communications. 306 NOTE: Ongoing work [I-D.gont-6man-non-stable-iids] aims at 307 updating [RFC4941] such that temporary addresses can be employed 308 without the need to configure stable addresses. 310 We note that the extent to which temporary addresses provide improved 311 mitigation of network activity correlation and/or reduced attack 312 exposure may be questionable and/or limited in some scenarios. For 313 example, a temporary address that is reachable for, say, a few hours 314 has a questionable "reduced exposure" (particularly when automated 315 attack tools do not typically require such a long period of time to 316 complete their task). Similarly, if network activity can be 317 correlated for the life of such address (e.g., on the order of 318 several hours), such period of time might be long enough for the 319 attacker to correlate all the network activity he is meaning to 320 correlate. 322 In order to better mitigate network activity correlation and/or 323 possibly reduce host exposure, an implementation might want to either 324 reduce the preferred lifetime of a temporary address, or even better, 325 generate one new temporary address for each new transport protocol 326 instance. However, the associated lifetime/stability of an address 327 may have a negative impact on the network. For example, if a node 328 were to employ "throw away" IPv6 addresses, or employ temporary 329 addresses [RFC4941] with a short preferred lifetime, local nodes 330 might need to maintain too many entries in their Neighbor Cache, and 331 a number of devices (possibly enforcing security policies) might also 332 need to keep such additional state. 334 Additionally, enforcing a maximum lifetime on IPv6 addresses may 335 cause long-lived TCP connections to fail. For example, an address 336 becoming "Invalid" (after transitioning through the "Preferred" and 337 "Deprecated" states) would cause the TCP connections employing them 338 to break. This, in turn, would cause e.g. long-lived SSH sessions to 339 break/fail. 341 In some scenarios, attack exposure may be reduced by limiting the 342 usage of temporary addresses to outbound connections, and prevent 343 such addresses from being used for inbound connections (please see 344 Section 7). 346 7. Usage Type Considerations 348 A node that employs one of its addresses to communicate with an 349 external server (i.e., to perform an "outgoing connection") may cause 350 such address to become exposed to attack. For example, once the 351 external server receives an incoming connection, the corresponding 352 server might launch an attack against the aforementioned address. A 353 real-world instance of this type of scenario has been documented in 354 [Hein]. 356 However, we note that employing an IPv6 address for an outgoing 357 communications need not increase the exposure of local services to 358 other parties. For example, nodes could employ temporary addresses 359 only for outgoing connections, but not for incoming connections. 360 Thus, external nodes that learn about client's addresses could not 361 really leverage such addresses for actively contacting the clients. 363 There are multiple ways in which this could possibly be achieved, 364 with different implications. Namely: 366 o Run a host-based or network-based firewall 368 o Bind services to specific (explicit) addresses 370 o Bind services only to stable addresses 372 A client could simply run a host-based firewall that only allows 373 incoming connections on the stable addresses. This is clearly more 374 of an operational way of achieving the desired functionality, and may 375 require good firewall/host integration (e.g., the firewall should be 376 able to tell stable vs. temporary addresses), may require the client 377 to run additional firewall software for this specific purpose, etc. 378 In other scenarios, a network-based firewall could be configured to 379 allow outgoing communications from all internal addresses, but only 380 allow incoming communications to stable addresses. For obvious 381 reasons, this is generally only applicable to networks where incoming 382 communications are allowed to a limited number of hosts/servers. 384 Services could be bound to specific (explicit) addresses, rather than 385 to all locally-configured addresses. However, there are a number of 386 short-comings associated with this approach. Firstly, an application 387 would need to be able to learn all of its addresses and associated 388 stability properties, something that tends to be non-trivial and non- 389 portable, and that also makes applications protocol-dependent, 390 unnecessarily. Secondly, the Sockets API does not really allow a 391 socket to be bound to a subset of the node's addresses. That is, 392 sockets can be bound to a single address or to all available 393 addresses (wildcard), but not to a subset of all the configured 394 addresses. 396 Binding services only to stable addresses provides a clean separation 397 between addresses employed for client-like outgoing connections and 398 server-like incoming connections. However, we currently lack an 399 appropriate API for nodes to be able to specify that a socket should 400 only be bound to stable addresses. Development of such an API should 401 be considered for future work. 403 8. Advice on IPv6 Address Configuration 405 [TBD] 407 TODO: This section is expected to provide advice regarding the 408 configuration of different addresses for different typical scenarios. 409 e.g., when nodes may want to configure stable-only, temporary-only, 410 or stable+temporary. In the most simple analysis, one might expect 411 nodes in a typical enterprise network to employ only stable 412 addresses. General-purpose nodes in a home or "trusted" network may 413 want to employ both stable and temporary addresses. Finally, mobile 414 nodes (e.g. when roaming across non-trusted networks) may want to 415 employ only temporary addresses). 417 9. Advice on IPv6 Address Usage 419 [TBD] 421 TODO: This section is expected to provide recommendations regarding 422 the usage of IPv6 addresses. Among others, it is expected to provide 423 recommendations regarding the usage of IPv6 addresses when providing 424 network services. In the mos simple form, one argue that nodes may 425 want to employ only the smallest-scope applicable addresses (if 426 available) and, if stable addresses are available, nodes may want to 427 accept incoming connections on such addresses but *not* on temporary 428 addresses. 430 10. Future Work 432 Some of the discussion in this document suggest that in order to 433 fully benefit from the IPv6 addresses (in terms of e.g. increased 434 availability of addresses and address types) additional work may be 435 required in this areas: 437 o Sockets API: The API may need to be extended such that a node may 438 bind() only a subset of the available addresses, possibly by 439 specifying a criteria (e.g. "only stable addresses", "only 440 global", "only local", etc.). 442 The aforementioned work may be carried out in this document, or as a 443 result of spin off documents. 445 11. IANA Considerations 447 There are no IANA registries within this document. The RFC-Editor 448 can remove this section before publication of this document as an 449 RFC. 451 12. Security Considerations 453 The security and privacy implications associated with the 454 predictability and lifetime of IPv6 addresses has been analyzed in 455 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 456 extends the aforementioned analysis by considering other IPv6 457 properties such as the address scope and address usage type. 459 This document also analyzes what properties are desirable for some 460 popular scenarios, and provides advice regarding the configuration 461 and usage of such addresses. Finally, it describes possible future 462 standards-track work to allow for greater flexibility in IPv6 address 463 usage. 465 13. Acknowledgements 467 The authors would like to thank [TBD] for providing valuable comments 468 on earlier versions of this document. 470 14. References 472 14.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 480 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 481 . 483 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 484 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 485 2006, . 487 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 488 Extensions for Stateless Address Autoconfiguration in 489 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 490 . 492 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 493 "Network Time Protocol Version 4: Protocol and Algorithms 494 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 495 . 497 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 498 "Default Address Selection for Internet Protocol Version 6 499 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 500 . 502 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 503 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 504 . 506 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 507 Interface Identifiers with IPv6 Stateless Address 508 Autoconfiguration (SLAAC)", RFC 7217, 509 DOI 10.17487/RFC7217, April 2014, 510 . 512 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 513 "Recommendation on Stable IPv6 Interface Identifiers", 514 RFC 8064, DOI 10.17487/RFC8064, February 2017, 515 . 517 14.2. Informative References 519 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 520 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 521 . 523 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 524 Considerations for IPv6 Address Generation Mechanisms", 525 RFC 7721, DOI 10.17487/RFC7721, March 2016, 526 . 528 [I-D.ietf-v6ops-ula-usage-considerations] 529 Liu, B. and S. Jiang, "Considerations For Using Unique 530 Local Addresses", draft-ietf-v6ops-ula-usage- 531 considerations-02 (work in progress), March 2017. 533 [I-D.gont-6man-non-stable-iids] 534 Gont, F., Huitema, C., Gont, G., and M. Corbo, 535 "Recommendation on Temporary IPv6 Interface Identifiers", 536 draft-gont-6man-non-stable-iids-01 (work in progress), 537 March 2017. 539 [I-D.gont-opsawg-firewalls-analysis] 540 Gont, F. and F. Baker, "On Firewalls in Network Security", 541 draft-gont-opsawg-firewalls-analysis-02 (work in 542 progress), February 2016. 544 [Barnes2012] 545 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 546 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 547 Workshop on Active Internet Measurements, February 2012, 548 . 551 [Hein] Hein, B., "The Rising Sophistication of Network Scanning", 552 January 2016, . 555 Authors' Addresses 557 Fernando Gont 558 SI6 Networks / UTN-FRH 559 Evaristo Carriego 2644 560 Haedo, Provincia de Buenos Aires 1706 561 Argentina 563 Phone: +54 11 4650 8472 564 Email: fgont@si6networks.com 565 URI: http://www.si6networks.com 566 Guillermo Gont 567 SI6 Networks 568 Evaristo Carriego 2644 569 Haedo, Provincia de Buenos Aires 1706 570 Argentina 572 Phone: +54 11 4650 8472 573 Email: ggont@si6networks.com 574 URI: https://www.si6networks.com 576 Madeleine Garcia Corbo 577 Servicios de Informacion del Transporte 578 Neptuno 358 579 Havana City 10400 580 Cuba 582 Email: madelen.garcia16@gmail.com 584 Christian Huitema 585 Private Octopus Inc. 586 Friday Harbor, WA 98250 587 U.S.A. 589 Email: huitema@huitema.net 590 URI: http://privateoctopus.com