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


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

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 ( 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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

3. Benefits

There are a number of benefits to using Link-Local addresses in applications.

4. Limitations

There are also a number of limitations to using Link-Local addresses in applications.

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.

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 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", Internet-Draft draft-smith-6man-link-locals-off-link-00, 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.
[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., Draves, R., Matsumoto, A. and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013.
[RFC7421] Carpenter, B., 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: