Internet Engineering Task Force M. Smith Internet-Draft October 19, 2015 Intended status: Informational Expires: April 21, 2016 How to use IPv6 Link-Local Addresses in Applications draft-smith-ipv6-link-locals-apps-00 Abstract IPv6 Link-Local addresses can be used by applications. Doing so when possible will provide robustness and security benefits to the application. This memo describes the properties of Link-Local addresses and the benefits and limitations of using them in applications. It then describes how to use them in applications that use the Sockets API. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Smith Expires April 21, 2016 [Page 1] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Link-Local Prefix and Address Attributes . . . . . . . . . . 2 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Using Link-Locals with the Sockets API . . . . . . . . . . . 5 5.1. sin6_scope_id . . . . . . . . . . . . . . . . . . . . . . 5 5.2. getaddrinfo() . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Change Log [RFC Editor please remove] . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction IPv6 Link-Local addresses can be used by applications. Doing so when possible will provide robustness and security benefits to the application. This memo describes the properties of Link-Local addresses and the benefits and limitations of using them in applications. It then describes how to use them in applications that use the Sockets API. 2. Link-Local Prefix and Address Attributes o The Link-Local unicast prefix is fe80::/10 [RFC4291]. o All IPv6 interfaces are required to have at least one Link-Local unicast address [RFC4291]. o Link-Local addresses have link-local scope, uniquely identifying interfaces only within a single link [RFC4007]. o Across multiple links attached to the same node there may be duplicate Link-Local addresses. These duplicate Link-Local addresses are disambiguated using scope zone information, or more simply, zone information, which describes on which specific link the chosen Link-Local address exists [RFC4007]. o Link-Local addresses have infinite preferred and valid lifetimes, meaning they never expire or age out [RFC4862]. o A specific Link-Local address is constantly present on an interface (due to its infinite preferred and valid lifetime) Smith Expires April 21, 2016 [Page 2] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 unless actively replaced by an event such as the interface being reinitialised or the interace being attached to a different link (e.g., attached to a different wireless network access point) [RFC4862]. o The Link-Local prefix is therefore present on all IPv6 enabled links [RFC4291], regardless of the presence of a router and router advertisements. o By default, a host treats the Link-Local prefix as on-link [RFC5942]. o Hosts use IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] to form a Link-Local address when an interface is enabled [RFC6434]. o Routers must be able to use IPv6 SLAAC [RFC4862] to form a Link- Local address when an interface is enabled [RFC6434]. o A Link-Local unicast address is formed by combining fe80::/10 with a link-specific format interface identifier (IID), positioned in the lower part of the IPv6 address [RFC4862]. o As most IIDs are 64 bits in length [RFC4291][RFC7421], the Link- Local prefix on a link is most commonly fe80::/64. o Link-Local packets can be forwarded by routers, but only back onto the same link they came from [RFC4007][RFC4291]. o By default, during default address selection, Link-Local addresses are preferred as IPv6 source and/or destination addresses over all other address types, with exception to the loopback address [RFC6724]. o The Link-Local prefix is not advertised in IPv6 Router Advertisement Prefix Information Options [RFC4861]. o 3. Benefits There are a number of benefits to using Link-Local addresses in applications. o As all interfaces are required to have Link-Local addresses and therefore the Link-Local prefix is always present on a link, application connectivity is independent of the presence of a router. This means that connectivity can be established without Smith Expires April 21, 2016 [Page 3] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 the presence of a router, or will not be impacted by the failure of a router, unless the router is part of the forwarding path between the Link-Local address application end-points. o As Link-Local addresses have infinite preferred and valid lifetimes, and presist on an interface unless actively replaced, including across transient link failures, application connections will persist for as long as the application needs them to unless a period of packet loss occurs which the application's transport protocol cannot tolerate. This is in contrast to the use of Unique Local Addresses (ULA) [RFC4193] or Globally Unique Addresses (GUA) [RFC4291] for application end-points, whose lifetimes may expire if not refreshed, causing the application's connection end-points to become invalid and therefore unavailable, despite the link continuing to provide connectivity between the involved hosts. o Assuming an application only uses Link-Local addresses, due to Link-Local traffic being limited to a single link, the potential set of application attackers is limited to the set of nodes attached to the same link. This set of link-attached nodes will likely be significanlty smaller than sets of nodes with either ULA or GUA addresses that could reach the application from off-link locations. The likely close geographic proximity of nodes attached to the same link would also provide a disincentive to attack applications that are only using Link-Local addresses. 4. Limitations There are also a number of limitations to using Link-Local addresses in applications. o Link-Local addresses cannot be used for application connections that span multiple links. o On some types of links, such as "Private VLANs" [RFC5517], a host may not be able to reach another host's Link-Local address. This is due to the hub-and-spoke forwarding constraints imposed by the link on some nodes, and the default on-link assumption for the Link-Local prefix [RFC5942]. An application could try to overcome this limitation by attempting to connect to the target host's ULA or GUA addresses if known, as full reachability might be available for these address types over these types of networks. [I-D.smith-6man-link-locals-off-link] proposes a method which would restore Link-Local address reachability over these types of links, while retaining hub-and-spoke forwarding constraints at the link-layer. Smith Expires April 21, 2016 [Page 4] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 o A Link-Local address is ambiguous, as by itself it does not inherently identify the link it is a member of, unlike ULA or GUA addresses. Consequently, applications have to be prepared to handle Link-Local zone information, which specifies on which link a Link-Local address is present. This may include providing user interface elements to allow an application user to specify per Link-Local address zone information. o When providing a Link-Local address to an application peer for use as a referral, it is best to ensure that the application peer is a member of the same link. This should then ensure that the application peer receives both the Link-Local address and correct zone information, implicit from the ingress interface the application peer received the referral over. For example, Multicast DNS achieves this by using link-local scope multicast destination addresses [RFC6762]. A Link-Local address should not be supplied to an off-link application peer for use as a referral unless the application knows the peer will have the correct zone information for the address, or can cope successfully with Link- Local address connection failure or securely with successful connection to an incorrect node (e.g., via some form of secure node or application level authentication). 5. Using Link-Locals with the Sockets API 5.1. sin6_scope_id The 'sockaddr_in6' structure is used by the Sockets API [RFC3493] to hold IPv6 socket address data. Within the 'sockaddr_in6' structure, the unsigned 32 bit 'sin6_scope_id' integer field identifies the scope or zone for the IPv6 address carried in the 'sin6_addr' sub-structure. In the case of Link-Local addresses, the 'sin6_scope_id' field identifies the interface where the Link-Local address is located. In the Sockets API, interfaces are identfied using an unsigned integer, known as an 'interface index'. The if_nametoindex() and if_indextoname() functions [RFC3493] are used to convert from an interface name to an interface index and vice-versa. When using Link-Local addresses in a 'sockaddr_in6' structure, the 'sin6_scope_id' field is set to or carries the interface index for the Link-Local address. Smith Expires April 21, 2016 [Page 5] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 5.2. getaddrinfo() When a node and service are successfully looked up using the getaddrinfo() call [RFC3493], a set of one or more 'addrinfo' structures is returned. Two of the fields within the returned 'addrinfo' structure(s) are the 'ai_addr' pointer, pointing to a 'sockaddr' structure, and the corresponding 'ai_addrlen' field, describing the size of the 'sockaddr' structure. These two fields are used to describe the 'sockaddr' structure holding one of the Internet addresses that corresponds to the node and service looked up using the getaddrinfo() call. In the case of an IPv6 Internet address, the 'ai_addr' pointer will point to a 'sockaddr_in6' structure, which will include the 'sin6_scope_id' field, described previously. Although traditional unicast DNS AAAA resource records are not prohibited from holding Link-Local addresses [RFC3596], AAAA resource records can only hold a 128 bit IPv6 address; the IPv6 scope information for the address is not stored. In this case, a AAAA resource record holding a Link-Local address is going to be ambiguous by itself; the 'sin6_scope_id' field value will likely be zero, indicating the "default" zone [RFC4007]. It will be necessary to supply scope information separately from getaddrinfo() to successfully use a Link-Local address stored in a unicast DNS AAAA resource record. Note that [RFC4472] recommends against storing Link-Local addresses in unicast DNS AAAA resource records. However, multicast DNS [RFC6762] queries for hosts within the ".local" top-level domain can implicitly provide the scope for a Link-Local address received in an AAAA resource record, as multicast DNS queries for the ".local" top-level domain uses a Link-Local scope multicast address (ff02::fb). This means that both the multicast DNS client and responder must be attached to the same link. As a multicast DNS responder is required to advertise all of its valid addresses, including its Link-Local address(es), a Link-Local address received in a multicast DNS response will be present on the link over which the response was received. Consequently, a multicast DNS client module operating behind the getaddrinfo() call can supply an unambiguous Link-Local address scope value in the 'sin6_scope_id' field of a 'sockaddr_in6' structure. Other Sockets API calls that use the 'sockaddr_in6' structure should then work successfully with Link-Local addresses that have been supplied via multicast DNS. Note that if getaddrinfo() returns multiple 'addrinfo' structures, they will be sorted as destination addresses in accordance with [RFC6724]. By default, Link-Local 'addrinfo' structures will appear before all other IPv6 address types, with exception to the IPv6 Smith Expires April 21, 2016 [Page 6] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 loopback address (::1). As applications are normally advised to step through the list in order, making successive connection attempts until one is successful, the earlier appearance of Link-Local addresses should ensure the attempted use of Link-Local addresses for application connections occurs before connections to larger scope ULA and GUA addresses are attempted. The "Happy Eyeballs" technique [RFC6555] will instead cause IPv4 to be quickly used if available, if a connection to a Link-Local address fails. 6. Security Considerations Using Link-Local addresses, when possible, increases application security by limiting the set of possible attackers to those located on the same link as a possible victim. In many cases, these possible same link attackers will be located geographically close to a possible victim, which may further discourage attempted attacks. 7. Acknowledgements Review and comments were provided by YOUR NAME HERE! This memo was prepared using the xml2rfc tool. 8. Change Log [RFC Editor please remove] draft-smith-ipv6-link-locals-apps-00, initial version, 2015-10-19 9. Informative References [I-D.smith-6man-link-locals-off-link] Smith, M., "Indicating Link-Local Unicast Destinations are Off-Link", draft-smith-6man-link-locals-off-link-00 (work in progress), August 2015. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, . Smith Expires April 21, 2016 [Page 7] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", RFC 5517, DOI 10.17487/RFC5517, February 2010, . [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, . [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2011, . [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . Smith Expires April 21, 2016 [Page 8] Internet-Draft Using IPv6 Link-Locals in Applications October 2015 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, . Author's Address Mark Smith PO BOX 521 HEIDELBERG, VIC 3084 AU Email: markzzzsmith@gmail.com Smith Expires April 21, 2016 [Page 9]