]> University of St Andrews, UK

saleem@st-andrews.ac.uk

Abertay University, UK

g.haywood@abertay.ac.uk

University of St Andrews, UK

ryo@htonl.net

Independent, USA

rgrimes@FreeBSD.org

Network Network Working Group Identifier Locator Network Protocol (ILNP) Identifier-Locator Vector (I-LV) Locator (L64) Node Identifier (NID) DNS The Identifier Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. ILNP uses a different architecture to IPv6 but is implemented to work with IPv6. This document describes how unmodified IPv6 applications running on an ILNP-capable node can make use of ILNP. This document updates RFC6740, RFC6741, RFC6748. About This Document Status information for this document may be found at . Discussion of this document takes place on the Network Network Working Group mailing list ().

Introduction ILNP is designed to be backwards compatible "on-the-wire" with IPv6, and to be incrementally deployable such that only nodes that need to use ILNP need to be modified, typically end-systems only. No modifications are required to switches or routers. Additionally, ILNP is designed to be backwards compatible with IPv6 applications. For many IPv6 applications, there should be no requirements for re-engineering or re-compilation of existing program binaries: existing IPv6 programs should be able to run on a node that has been updated with an ILNP-capable network stack. When an IPv6 application uses ILNP communication, it is important that such usage is:

• intentional: comes from explicit actions taken to use ILNP, e.g. there is a clear choice about the use of ILNP communication for IPv6 applications from systems configuration; and
• predictable: avoids surprises, as much as is possible, from the use of ILNP, e.g. that ILNP communication does not result in the IPv6 application entering unsupported states or undesirable modes of operation.

However, even with carefully planned and intentional usage, the wide diversity of applications means that it is possible that the behaviour of some applications is not predictable. ILNP is defined for use with IPv6 and for use with IPv4, but all references in this document to ILNP are for IPv6 only.

Purpose The purpose of this document is to describe how unmodified IPv6 applications can use ILNP-based communication:

1. The mechanisms by which ILNP communication is possible for unmodified IPv6 applications.
2. How unmodified IPv6 applications can run on an ILNP-capable node.
3. Which IPv6 applications should work with ILNP, and which are unlikely to work.

The mechanism by which an ILNP-capable node communicates with a non-ILNP capable node is to fall back to using IPv6, as described in , , , and . This document discusses only communication based on unicast addressing: multicast communication for ILNP is as for IPv6.

Rationale It is expected that new ILNP-aware applications will in the future make use of access to the new addressing data-types in ILNP to have more flexible connectivity and control of traffic flows. This will depend on the availability of suitable a API for access to ILNP-specific addressing information. In parallel, existing IPv6 applications should be able to make use of ILNP because it was designed to be backwards compatible with IPv6. Indeed, it would be beneficial if as many as possible of the benefits of ILNP could be used by unmodified IPv6 applications. So, this document describes how existing IPv6 applications can use ILNP without being modified.

Motivation Why should an IPv6 application use ILNP? A complete answer to this question, and any detailed discussion, is beyond the scope of this document. As a short answer to the question above, the different approach to addressing and connectivity in ILNP means that, for example, an existing, unmodified IPv6 application could gain in the following ways:

• Improved privacy and security at the packet level .
• Combined mobility-multihoming capability under end-system control .
• Provision of multipath connectivity for existing transport protocols .

This additional control for connectivity and communication for an application with ILNP is designed using an end-to-end approach, allowing all the functionality to work together harmoniously. Also, the end-to-end approach means the functionality can be implemented without requiring the use of proxies, tunnelling, or address translation mechanisms. Complete solutions for unmodified IPv6 applications to use ILNP in this way are being developed and tested at the time of writing. Meanwhile, the work cited above, using results from ILNP implementations in FreeBSD and Linux, with ongoing testing and experiments over international connectivity at IETF meetings and IETF Hackathon events, show that there are realistic possibilities for ILNP to operate across global IPv6 connectivity, and that many existing IPv6 applications could work unmodified over ILNP.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Definitions from other documents The following terms are defined in :

• Locator, L64
• Node Identifier, NID
• Identifier-Locator Vector, I-LV
• I-L Communications Cache, ILCC

The following term is defined in :

• ordered I-LV sequence, {A_a}

The notation for textual representations for I-LV values is defined in . The reference to the C sockets API extensions for IPv6 is in relation to , particularly the use of:

• the struct addrinfo data structure.
• the struct sockaddr_in6 data structure.
• the getaddrinfo(3) C library function call.

Examples used in this document In order to describe the interactions for communication, a client-server mode of operation is assumed in the explanations and descriptions. However, the approach is general: the ILNP client is a communication initiator, the ILNP server is a communication responder. The communication process is described in terms of:

1. An ILNP-capable node waiting to accept incoming communication requests from a remote ILNP-capable node, e.g. incoming TCP connections or UDP sessions. For the purposes of this document, such a node is called an ILNP server node.
2. An ILNP-capable node wishing to initiate communication to a remote ILNP-capable node. For the purposes of this document, such a node is called an ILNP client node.

So, for our purposes, an IPv6 server application is running on an ILNP server node, and an IPv6 client application is running on an ILNP client node.

Use of the sockets API This document makes use of the sockets API and related family of function calls, data structures, data-types, and value definitions in C (which are also defined as part of POSIX.1-2008 / POSIX.1-2017 / POSIX-1.2024). In the sockets API, address family definitions exist for use with the function calls and data structures to identify the type of addressing being used: AF_INET for IPv4, AF_INET6 for IPv6 . In the future, new addressing extensions for sockets might be defined for ILNP, just as extensions were defined for IPv6 in addition to IPv4. For now, this document describes how ILNP is used for backwards compatibility with IPv6 applications only, with any ILNP I-LV values presented to applications as type AF_INET6 so that I-LV values can be used as IPv6 addresses.

Practical addressing and naming for ILNP The key mechanisms by which unmodified IPv6 applications can make use of ILNP is through the syntactic compatibility in naming and addressing formats between ILNP and IPv6. For name resolution, ILNP uses the same sources as for IPv6, e.g. entries in /etc/hosts or responses from DNS. I-LV values are 128-bit values that are syntactically equivalent to an IPv6 address. So, for carrying addressing information across the network, an ILNP packet uses the address fields in the IPv6 packet header to carry I-LV values. As ILNP packets are "on-the-wire" identical to IPv6 packets, network components, such as routers and switches, can forward ILNP packets, and I-LV values can be handled like IPv6 addresses. However, ILNP operates end-to-end, so ILNP-aware nodes can act upon the semantics of L64 and NID values end-to-end to enable the various functionality that is possible for ILNP, as described in and .

Name resolution process It is possible for an ILNP-capable node to determine if a remote node is also ILNP-capable through name resolution using existing mechanisms, and so initiate ILNP communication. When a name, such as a fully-qualified domain name (FQDN), is passed by an application to a node, name resolution is performed using /etc/hosts or DNS. The resolution of a name to an address selects the type of communication -- IPv4 or IPv6 -- that is possible and could be initiated by an application. The type information is part of the name resolution, the most common examples being:

• the implicit type information in the textual representation of an address value in /etc/hosts:
  • decimal-dot notation for IPv4, such as "123.12.34.45".
  • hexadecimal-colon notation for IPv6, such as "2001:db8:12:34::abcd:1".
• the explicit type value of a DNS Resource Record (RR) returned in a DNS response:
  • type A for IPv4.
  • type AAAA for IPv6.

So, similarly, for ILNP we have type information included with addressing values:

• notations for the textual representations of L64, NID, and I-LV values for use in /etc/hosts as defined in , such as "2001-db8-12-34.0+0+abcd+1" for an I-LV.
• DNS RRs for L64 and NID values, with type values assigned by IANA, as documented in .

Although it is expected that normal operation for name resolution will be using DNS, the use of /etc/hosts can be a convenient method in some cases, e.g. for experimentation and debugging, especially on a local testbed. Some guidance on the use of /etc/hosts is provided in and . Also, server systems especially might need application-specific addressing configuration, and that is out of scope for this document.

Name resolution for an application The socket(2) API uses the getaddrinfo(3) library function to resolve names and provide for IPv6 applications a list of 128-bit IPv6 address in an instance of a struct addrinfo list. getaddrinfo(3) has the function prototype: The typical code pattern for name resolution is:

1. The ai_family member of hints is set to AF_UNSPEC (or AF_INET6 for IPv6 only) before invoking getaddrinfo(3) with a value for nodename to resolve. (servname might also be used but is not relevant for this document.)
2. Upon successful return, res holds a struct addrinfo list with a sequence of IPv6 address values that could be used by the application.
3. A value from res is copied into a struct sockaddr_in6 instance for use in socket(2).

For an ILNP-capable node, to allow unmodified IPv6 applications to use ILNP, the behaviour of getaddrinfo(3) MUST be:

1. upon invocation:
   • if the nodename provided matches I-LV entries from /etc/hosts, then an ordered I-LV sequence, {A_a}, MUST be constructed from the matching entries;
   • otherwise nodename is used in DNS queries so that L64 and NID RRs can be retrieved (as well as AAAA and A RRs, if defined, for backwards compatibility), and the returned L64 and NID RRs MUST be used to construct an ordered I-LV sequence, {A_a}.
2. upon successful return for the API user, the list in res MUST contain at its start the list of the I-LV values from {A_a} with the struct addrinfo instances marked as AF_INET6 as if they are IPv6 addresses.
3. below the API, the ILCC and internal state for the ILNP node MUST record that the name resolution did include I-LV values, so that a subsequent socket(2) invocation with a struct addrinfo_in6 instance containing an I-LV value from res will return a descriptor to a socket that will be an ILNP communication end-point.

The ordered I-LV sequence, {A_a}, contains I-LV values in a preferred ordering for the remote node. The process for constructing {A_a} is described in , but that process is not visible to the user. So, the socket(2) family of calls using res will have the correct type information for an IPv6 application, and API calls will also result in an ILNP communication end-point. That is, the application will have a reference to an IPv6 communication end-point (the socket descriptor that is returned), but the type of the socket that will be created will be for ILNP communication. Hence, an unmodified IPv6 application will be able to engage in ILNP-based communication.

DNS queries for L64 and NID RRs A simple way to implement a DNS query to select L64, NID, AAAA, and A RRs that match the same nodename is to use DNS query type of ANY, i.e. QTYPE=ANY. While a DNS query with QTYPE=ANY is still possible for deployed DNS resolvers, its use is subject to variable and non-consistent behaviour in responses, as described in . This non-consistent response behaviour could be due to a number of reasons, e.g. to avoid traffic amplification attacks when using UDP for DNS queries, or due to local policy. Alternatively, parallel DNS queries with different QTYPE values could be made by an implementation of getaddrinfo(3), e.g. multiple queries with QTYPE set, in turn, to L64, NID, AAAA, and A. However, L64 and NID RRs might not be returned first -- one of the other parallel queries could be answered first and that could be enough for the call to getaddrinfo(3) to complete successfully. As the ordering, delay, and content of DNS responses to QTYPE=ANY or to multiple parallel queries are not well-defined, res might not contain I-LV values, even if L64 and NID RRs are defined for nodename in the DNS. This means that an I-LV might not always be selected after a call to getaddrinfo(3) when DNS is used. Even if I-LV values are included in res, with the added recommendation for "Happy Eyeballs" , an ILNP communication might not always be initiated between IPv6 applications running on ILNP-capable nodes. This is not an issue particular to ILNP: the same is true for IPv6 and IPv4, i.e. the combination of the non-consistent DNS responder behaviour and the "Happy Eyeballs" recommendation could mean that IPv4 is selected for communication between IPv6-capable applications both running on IPv6-capable nodes.

IPv6 server application using ILNP For an ILNP server node, the IPv6 server application needs to establish a communication end-point that can accept incoming ILNP communication requests. An ILNP server node, or individual IPv6 application, might be invoked via local or application-specific configuration, and be initialised with a communication end-point to accept incoming communication requests in the following ways:

• Case 0: Use of "wildcard" addressing, i.e. no ILNP-specific information is configured when the IPv6 server application is invoked.
• Case 1: Predefined I-LV values are used directly, e.g. the ILNP server node has defined for it one or more specific whole I-LV values (or names that resolve to whole I-LV values) in place of IPv6 addresses in the application-specific configuration.
• Case 2: Separate L64 and NID values, e.g. the ILNP server node is configured with multiple L64 and NID values and so can form I-LV values, which can then be used by the IPv6 application as if the I-LV values are IPv6 addresses.

 Case 0: "Wildcard" addressing It is NOT RECOMMENDED that IPv6 server applications make use of ILNP communication as described in this sub-section. The usage of ILNP will not be intentional and is unlikely to be predictable. An IPv6 server application code pattern might typically invoke bind(2) using IN6ADDR_ANY_INIT for IPv6, so that it can accept incoming connections for any and all IPv6 addresses that it currently has configured, IPv4 and / or IPv6. For an IPv6 server application running on an ILNP server node, it is RECOMMENDED that the server application is invoked using a locally defined I-LV (or name resolving to an I-LV) -- please see . This could be achieved through local configuration files or command-line arguments for invocation of the server application.

Case 1: Predefined I-LV values It is RECOMMENDED that an IPv6 server application running on an ILNP server node is configured and invoked as described in this sub-section. This usage is intentional and should result in predictable behaviour. For practical purposes, it is also the easiest and clearest method of enabling unmodified IPv6 server applications to make use of ILNP communication. The scenario described here is for the case when I-LV values are to be used directly in place of IPv6 addresses:

1. It is RECOMMENDED that predefined I-LV values, or names resolving to such I-LV values, should be configured for the ILNP server node.
2. It is RECOMMENDED that these predefined I-LV values, or names resolving to such I-LV values, should be used when starting an IPv6 application to explicitly make use of ILNP-based communication.

As an example, predefined I-LV values could be configured as described in . When a predefined I-LV, or a name resolution resulting in a predefined I-LV, is used in the invocation to bind(2), the ILNP server node:

1. SHOULD allow ILNP communication for that I-LV at the time of invocation.
2. SHOULD maintain ILNP communication for that I-LV value after invocation, consistent with the validity of the L64 value for the I-LV.

The "SHOULD" in points 1 and 2 above allows flexibility for application-specific behaviour or local policy. Also, it allows flexibility for whether or not such communication end-points are to be made discoverable to remote client applications for ILNP communication, e.g. by a Dynamic Secure DNS update that creates or updates L64 and NID RRs for that I-LV through some out-of-application mechanism. For point 2 above, it is possible that a L64 value becomes unavailable and then becomes available again, e.g. due to presence (or not) of IPv6 prefix values in IPv6 Routing Advertisements (RAs) coupled with the behaviour of ILNP dynamic multihoming and mobility capability . The "SHOULD" in point 2 gives flexibility for application-specific behaviour or local policy in this respect. If the behaviour is implemented and utilised, the IPv6 application gains connectivity capability it would never have had. If the behaviour is not implemented or utilised, nothing has been lost with respect to the normal expected operation of the IPv6 server application, but client applications would still gain from using ILNP communication -- please see . However, when the behaviour is implemented, and the I-LV lifetime expires, a previously bound socket becomes invalid, and the behaviour for such a situation is system-specific.

Case 2: Predefined L64 and NID values It is NOT RECOMMENDED that an IPv6 server application running on an ILNP server node is configured and invoked as described in this sub-section. Although the usage is intentional, it might result in behaviour that is not predictable. The scenario described here is a possibility. However, it is not expected that unmodified IPv6 server applications will be invoked in such a configuration. An ILNP server node might have defined for it multiple L64 and NID values from which it can form I-LV values as described in . These could be configured locally or learned dynamically from DNS. L64 and NID values from DNS RRs have a Time-To-Live (TTL) value, but it is possible that local mechanisms also allow L64 and NID values to have limited lifetimes much like the DNS TTL. If separate L64 and NID values are defined without specific lifetimes, then the behaviour will be as for predefined I-LV values as in . It is possible that, for example, predefined NID values are configured locally with no expiry time, while L64 values are discovered dynamically (typically as address prefix values from IPv6 RAs) and might have a limited lifetime. In this case I-LV values could be transient because of the L64 lifetime. If a NID value is defined without a specific lifetime, and the L64 value is learned dynamically (e.g. an address prefix from an IPv6 RA) but has a "long" lifetime (e.g. a day, or a week), this behaviour is similar to the use of SLAAC , and so, with care, the scenario of could still be employed for an ILNP server node. However, if the L64 and NID values each have limited lifetimes, then this impacts the overall lifetimes of the I-LVs that are formed from those L64 and NID values. The IPv6 application will, effectively, be using addresses that will "expire" to create sockets on which to accept incoming communication sessions. When the invocation of bind(2) is made with a specific I-LV formed from the separate L64 and NID values (as described in ), the ILNP server node:

1. SHOULD allow ILNP communication for that I-LV at the time of invocation; and
2. SHOULD maintain ILNP communication for that I-LV consistent with the validity of those L64 and NID values that constitute that I-LV.

The "SHOULD" in point 1 and 2 above allows flexibility for application-specific behaviour or local policy. Also, it allows flexibility for whether or not such communication end-points are to be made discoverable to remote client applications for ILNP communictaion, e.g. by a Dynamic Secure DNS update that creates or updates to L64 and NID RRs through some out-of-application mechanism. However, when the behaviour is implemented, and the I-LV lifetime expires, a previously bound socket becomes invalid, and the behaviour for such a situation is system-specific.

Server-side use of /etc/hosts A name could be defined for lookup of an I-LV before bind(2) is invoked. This could be in DNS, as a client application would also need that information to initiate communication. However, a name could (also) be a local name defined in /etc/hosts for an I-LV that the IPv6 server application is configured to use, the local name being provided via command-line arguments or application-specific configuration files. Care should be taken if I-LV entries are used in /etc/hosts with corresponding L64 and NID entries in DNS: the latter will be required for client applications under normal operation. Examples of names and I-LV entries in /etc/hosts are given in . This could be for two different servers on the same physical / virtual node, or some other arrangement, but that choice is left to the user.

Example entries in the `/etc/hosts` file for I-LV values for ILNP server nodes.

This does not preclude any application-specific configuration or local policy control for I-LV selection.

Server-side exceptions With use of ILNP communication for IPv6 applications, care is needed in choosing I-LV values for initial configuration and instantiation. There are situations where ILNP communication cannot be initiated transparently for an IPv6 server. In most cases, this is likely to be where the server application (or accompanying client application) uses IPv6 address values directly, e.g. within the code base or in configuration files. For example, if a server application expects to bind(2) to a "hard-coded" address, or to use a specific interface on a node, or if a server application manipulates address bits directly in user-space as part of its behaviour. This could be true especially for some control-plane and management-plane applications.

IPv6 client application using ILNP Typically, an IPv6 client application will invoke getaddrinfo(3) with a nodename for a remote node, then use a value from the res list, often the first value in the res list, to make a call to socket(2), and then start a communication session. Using the mechanism described in , the first value in res will be for an I-LV. There might also be other I-LVs in res, but it is not possible for the IPv6 application to know that. A subsequent call, e.g. to connect(2) with that first value from res will create an ILNP communication end-point.

Client-side use of /etc/hosts If DNS is not configured or if the use of /etc/hosts is desired, examples of names and I-LVs for ILNP server nodes that could be used by the IPv6 client application are given in . Care should be taken if I-LV entries are used in /etc/hosts with corresponding L64 and NID entries in DNS: it is RECOMMENDED that client systems use DNS under normal operation.

Example entries in the `/etc/hosts` for use by a client to lookup I-LV values for a remote ILNP server node.

This does not preclude any application-specific configuration or local policy control for I-LV selection.

Client-side exceptions In most cases, client applications initiate communication after a name resolution is performed to find addressing information and initiate a communication end-point, as described in . Then, the client application typically only uses a reference to the communication end-point (a socket descriptor), and is usually not concerned with the exact values in the addressing information. So, it is expected that most IPv6 client applications will be able to make use of ILNP-based communication. However, after using getaddrinfo(3), if the client application chooses a value from the res list that is not an I-LV, then ILNP communication will not be initiated. Also, as is true for the server-side, as described in , if the client application (or accompanying server application) uses IPv6 address values directly, e.g. within the code base or in configuration files, ILNP communication might not work correctly. Again, this could be true especially for some control-plane and management-plane applications. Additionally, as already discussed in , the effects of the DNS responder behaviour coupled with the "Happy Eyeballs" recommendations might result in ILNP not being initiated by a client application even though it is possible.

Communication session management Once a communication session is successfully initiated (e.g. a TCP connection), the handling of addressing for each end-point can be summarised as:

1. There is a Source I-LV and a Destination I-LV, consisting, respectively of L64_s and NID_s, and L64_d and NID_d.
2. NID_s and NID_d values MUST remain constant for the duration of the session.
3. The Source node or Destination node MAY signal changes, respectively, to their L64_s or L64_d values by the use of Locator Update (LU) message .

Please note that this is a summary only, full details of the state management process for L64 and NID values are given in . However, the user-level control of the session via the sockets API is unchanged for the IPv6 application.

Security Considerations There are no new security considerations. The existing security mechanisms already defined for ILNP remain unchanged (please see , ). The use of the ILNP Nonce Header would offer extra lightweight protection for communication flows at the IP packet level, compared to that which is available for IPv6 without the use of IPsec.

Privacy Considerations There are no new privacy considerations. The existing identity privacy and location privacy properties already defined for ILNP remain unchanged (please see , , ). NID values can also be generated using privacy mechanisms such as . ILNP can also use enhanced identity privacy and location privacy mechanisms which remain backwards compatible with IPv6, such as described in .

IANA Considerations This document has no IANA actions.

References Normative References This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK] The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community. This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community. Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons. The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance. This document updates RFCs 1034 and 1035. This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941. University of St Andrews, UK A related draft that is being produced in parallel. University of St Andrews, UK Abertay University, UK University of St Andrews, UK Independent, USA A related draft that is being produced in parallel. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IEEE School of Computer Science, University of St Andrews, St Andrews KY16 9SX, UK School of Computer Science, University of St Andrews, St Andrews KY16 9SX, UK MDPI AG Department of Cybersecurity and Computing, Abertay University, Dundee DD1 1HG, UK School of Computer Science, University of St Andrews, St Andrews KY16 9AJ, UK MDPI AG University of St Andrews, St Andrews, UK University of St Andrews, St Andrews, UK ACM School of Computing Science, College of Science and Engineering, University of Glasgow, Glasgow G12 8RZ, UK School of Computer Science, University of St Andrews, St Andrews KY16 9SX, UK MDPI AG

Acknowledgements The authors are grateful to the many members of the IETF community for their feedback on ILNP during IETF meetings, and to the IETF NOC Team who made possible testing and experiments for ILNP during those meetings and the IETF Hackathon events. Alistair Woodman and NetDEF supported G.T. Haywood in an internship for initiating a FreeBSD implementation of ILNP for his PhD studies. Time Warner Cable partly supported R. Yanagida for a Linux implementation of ILNP during his PhD studies. This work was partly supported by the ICANN Grant Program.