[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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,
              <http://www.rfc-editor.org/info/rfc3493>.

   [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,
              <http://www.rfc-editor.org/info/rfc3596>.

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              DOI 10.17487/RFC4007, March 2005,
              <http://www.rfc-editor.org/info/rfc4007>.



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,
              <http://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472,
              DOI 10.17487/RFC4472, April 2006,
              <http://www.rfc-editor.org/info/rfc4472>.

   [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,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [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,
              <http://www.rfc-editor.org/info/rfc5517>.

   [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,
              <http://www.rfc-editor.org/info/rfc5942>.

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", RFC 6434, DOI 10.17487/RFC6434, December
              2011, <http://www.rfc-editor.org/info/rfc6434>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <http://www.rfc-editor.org/info/rfc6555>.

   [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,
              <http://www.rfc-editor.org/info/rfc6724>.






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,
              <http://www.rfc-editor.org/info/rfc6762>.

   [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,
              <http://www.rfc-editor.org/info/rfc7421>.

Author's Address

   Mark Smith
   PO BOX 521
   HEIDELBERG, VIC  3084
   AU

   Email: markzzzsmith@gmail.com

































Smith                    Expires April 21, 2016                 [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/