]> University of St Andrews, UK

saleem@st-andrews.ac.uk

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. This document clarifies how addressing in ILNP makes use of Preference values with Locator (L64) and Node Identifier (NID) values. This includes the way that Preference values are used for forming Identifier-Locator Vector (I-LV) values, and selecting I-LVs for use. This document updates RFC6740, RFC6741, RFC6742, RFC6748. Status information for this document may be found at . Discussion of this document takes place on the Network Network Working Group mailing list ().

Introduction The Identifier Locator Network Protocol (ILNP) redefines the IP addressing architecture by use of new addressing data-types . The ILNP addressing data-types considered in this document are: Locator (L64): A 64-bit value (8 bytes, in network / canonical byte order) that is a label for a network. Node Identifier (NID): A 64-bit value (8 bytes, in network / canonical byte order) that is a label for a node. Identifier-Locator Vector (I-LV): The 128-bit concatenation of a single L64 value and single NID value for use in the IPv6 packet header in the source address and destination address fields. L64 and NID values each have an associated Preference, a 16-bit value in the range 0-65535 (i.e. a 16-bit, unsigned integer), with lower values indicating higher preference. From an engineering perspective, for backwards compatibility, the data-types are realised and used within the context of IPv6 . An ILNP packet will use the address fields in an IPv6 packet header to carry I-LV values constructed from L64 and NID values based on the Preference values, even though the Preference values themselves are not sent in the packet. The relationships between addressing data-types for IPv6 and ILNP are summarised in the diagram of .

An ILNP packet is distinguished from an IPv6 packet by the presence of a Nonce Header, the name used for the IPv6 Destination Option Header specified in for use only with ILNP. Examining only the address fields in an IPv6 packet is not sufficient to determine whether the packet is an ILNP packet, the Nonce Header must be present . A more detailed description of the ILNP architecture and its relationship to IPv6 can be found in and . L64 and NID values also have corresponding DNS Resource Record (RR) definitions in , which also include a Preference value as part of each L64 or NID RR. L64 values with Preference values are also used in ILNP Locator Update (LU) messages as defined in .

Purpose This document clarifies the way that Preference values are used in ILNP in the following ways: The semantics of the Preference value as used with L64, NID, and I-LV values. How I-LV values are formed using Preference values when a node has multiple L64 and NID values. How Preference values impact the choice of I-LV at the transmitting node. ILNP is defined for use with IPv6 and for IPv4, but all references in this document to ILNP are for IPv6 only. It is possible to apply the methods described in this document to ILNP for IPv4 (with the use of the L32 data-type from in place of the L64 data-type), but that exercise is outside the scope of this document.

Rationale An ILNP node can use multiple L64 values and multiple NID values simultaneously, and separate Preference values are associated with each L64 and NID. A 128-bit I-LV is created from a single L64 concatenated with a single NID value. When L64 and NID values are used to create an I-LV for transmission, the Preference value affects the selection process for I-LV values at the transmitting node, subject to local policy . The use of Preference values in addressing in ILNP needs clarification, as it affects the use of L64 and NID values to form I-LVs. The use of local policy to determine how Preference values are to be used remains, and the definition of such local policy is beyond the scope of this document. However, in the absence of such local policy, for the ILNP addressing architecture in general, this document clarifies how Preference values are to be used. So, a clear description of the use of the Preference value is needed to understand how it should be used at the ILNP node. ILNP can also be used by unmodified IPv6 applications, and that usage is described in . Use of DHCPv6 specifically for ILNP is not yet defined, and is outside the scope of this document.

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 definitions are taken from : Locator, L64 Node Identifier, NID Identifier-Locator Vector, I-LV I-L Communications Cache, ILCC Source I-LV Destination I-LV

New definitions This document defines two terms:

L64 Preference

A Preference value for a L64 value. This MUST be used in place of the term Locator Preference Indicator (LPI) in .

NID Preference

A Preference value for a NID value. This was not explicitly defined or discussed in or , but it is clear from that NID values also have a Preference.

Updates to previous RFC documents RFC documents that are updated by this document are: RFC6740 "Identifier-Locator Network Protocol (ILNP) Architectural Description" . RFC6741 "Identifier-Locator Network Protocol (ILNP) Engineering Considerations" . RFC6742 "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)" . RFC6748 "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)" .

RFC6740 and RFC6741 discusses use of a Locator Preference Indicator (LPI) for L64 values, but does not discuss Preference values for NID values. does not discuss Preference values. However, neither document states how Preference values are to be used by a node.

RFC6742 defines Preference values for use in L64 and NID Resource Records (RRs) for DNS. However, it does not state how Preference values are to be used by a node.

RFC6748 mentions the use of the LPI. That document also mentions the use of local policy to determine how Preference values would be used. However, it does not give any more detail.

Purpose of the Preference value As ILNP nodes might make use of multiple L64 and NID values, Preference values SHOULD be given with each L64 or NID value so that a node can make a selection of which L64 and NID values to use.

 Presence of Preference values The Preference value is included for ILNP nodes as follows, and its presence can be summarised in the following three rules: A Preference value SHOULD be given for every L64 (L64 Preference) value or NID (NID Preference) value in use by a node. A Preference value SHOULD be given for every L64 (L64 Preference) value or NID (NID Preference) value when they are used for configuration purposes, e.g. for local end-system configurations, or for application-specific configurations. When a L64 Preference value or NID Preference value is not known or given it MUST be considered to be zero. From the rules above, the "MUST" in rule 3 allows flexibility for a Preference value not to be given explicitly (hence the "SHOULD" in rules 1 and 2). Preference values are not carried in the IPv6 header, and are not present in an ILNP packet apart from the case of the LU message. The LU message carries a L64 Preference value for each L64 in the payload as defined in , but not as part of the IPv6 header. There might be local policy or application-specific usage that impacts the use of the Preference values, and the definition of such usage is out of scope for this document. Preference values can be used on an ILNP node for unmodified IPv6 applications (applications that are not ILNP-aware) to gain some of the benefits of ILNP, and such usage is described in .

Discovery of Preference values Preference values can be learned from DNS or from local configuration files. When learned from DNS, they are included in ILNP DNS Resource Records (RRs), i.e. L64 or NID RRs as define din . When learned from local configuration files, Preference values SHOULD be given with the respective definitions of values for L64s, NIDs, or I-LVs.

Use of Preference values in constructing I-LV values I-LV values must be constructed so that they can be used in place of IPv6 address values in the IPv6 packet header. When a node has multiple L64 values and NID values defined for it to use, it must construct I-LV values for use as a Source I-LV, to be carried as the Source Address in the IPv6 header. When a node discovers multiple L64 and NID values defined for use for a remote node, it must construct I-LV values to use as a Destination I-LV, to be carried as the Destination Address in the IPv6 header. In both cases, the Preference value is used by the transmitting node to create an I-LV value. An ILNP node MAY construct I-LV values directly from the available L64 and NID values based on application-specific requirements or based on local policy -- please see . Otherwise, this document (specifically ) describes how Source I-LV values and Destination I-LV values MUST be constructed from L64 and NID values using their respective Preference values.

General method for generating I-LV values from L64 and NID values

I-LV construction The general method for generating I-LV values from L64 and NID values uses the definitions below and the simple algorithm defined in . This method can be used for generating Source I-LV values and Destination I-LV values. Let {L_l} be a sequence of l L64 values each with a L64 Preference value, l >= 1. {L_l} MUST be ordered with increasing L64 Preference; and {L_l} MUST NOT have duplicates for the 64-bit L64 values. Let {N_n} be a sequence of n NID values each with a NID Preference value, n >= 1. {N_n} MUST be ordered with increasing NID Preference; and {N_n} MUST NOT have duplicates for the 64-bit NID values. The relative ordering of elements in each list {L_l} or {N_n} which have the same Preference value is considered to be either subject to local policy or to be application-specific. Let {A_a} be a sequence of a I-LV values, initially a = 0, i.e. the sequence is empty. Let l64 be a single L64 64-bit value (8 bytes, network / canonical byte order). Let nid be a single NID 64-bit value (8 bytes, network / canonical byte order). Let x::y be the concatenation of x and y. Then the algorithm for generating {A_a} is given in :

The sequence {A_a} is now the ordered I-LV sequence, and contains a list of 128-bit I-LV values, each of which can be used as an IPv6 address, with the most preferred I-LV values at the start of the list. The lists {L_l} and {N}_n are both maintained by the operating system in an ILNP node through the function of the ILCC. When the lists {L_l} and {N_n} are complete, or if either list changes, the mechanism described in this section can be invoked to (re-)generate the ordered I-LV sequence, {A_a}. Please see for more details. The precise details of how an ILNP-aware application can make use of {L_l} and {N_n} directly is likely to be application-specific or subject to local policy, so is outside the scope of this document, but please see . For IPv6 applications running on an ILNP node, the use of {A_a} is described in .

Source I-LV construction For Source I-LV values, L64 and NID values could be learned from a number of sources. As L64 values are IPv6 address prefixes, ILNP allows L64 values to be discovered via an IPv6 Router Advertisement (RA) . ILNP NID values can be generated dynamically using any of the mechanisms defined for IPv6, e.g. for privacy by using or , or for verifiable addresses as in . In such cases, Preference values will be zero for L64 and NID values unless local policy defines otherwise. Such automatic configuration could be used for default / bootstrap configurations, and allows backwards compatibility with IPv6. If only a L64 value is specified locally, the NID can still take a generated NID value using any mechanism already defined for generating IPv6 IID values. If only a NID value is specified locally, the L64 can still take a value of an IPv6 address prefix learned from an IPv6 RA. For example, if a node has a single L64, L_1, learned from an IPv6 RA, and a single NID, N_1, defined locally, then it will have a single source I-LV, L_1::N_1. If Preference values are not specified, they should be considered to have the value of zero. However, it is possible for a node to have a fixed I-LV defined for it through local configuration, just as it is possible for a node to have a fixed IPv6 address. Please see also and .

Destination I-LV construction For remote nodes, L64 and NID values for constructing Destination I-LV values will typically be learned from the DNS, e.g. from DNS L64 and NID RRs (please see ). L64 and NID RRs have Preference values . However, it is also possible for L64 and NID values to be configured through some locally-defined mechanism, e.g. operating system files, or application-specific configuration. Please see also and .

Selection of I-LV values The ordering mechanism means that the first I-LV, A_1, in {A_a} is always the one that has the combination of first the lowest NID Preference and then the lowest L64 Preference, i.e. the most preferred NID value and most preferred L64 value. If {A_a} contains more than one value, the process of selecting which value to use is out of scope for this document. The choice could be subject to local policy, or could be an application-specific choice. In the case of it being application-specific, it will depend on the API available, and if the application is ILNP-aware or not (please see ). If {L_l} and {N_n} are directly accessible on an ILNP node, then an ILNP-aware application can: construct I-LV values directly if it has access to {L_l} and {N_n}; or choose the I-LV to use directly from {A_a}; and use Preference values in making such selections as required.

Changes to the lists of L64 and NID values The L64 list, {L_l}, and NID list, {N_n}, could change as new L64 and NID values become available or existing L64 or NID values can no longer be used. A (non-exhaustive) list of reasons the lists could change is: L64 and NID values were discovered from DNS, and the Time-to-Live (TTL) for the respective DNS RR expires. NID values were generated using privacy mechanisms and so have a limited lifetime based on the privacy mechanism used. Routing changes mean that a L64 value discovered from an IPv6 RA expires and so cannot be used any longer. An IPv6 RA appears that shows a new address prefix is available to use as a L64 value. A LU message is received from a remote node with one or more new L64 values for that remote node, and previous L64 values for that node are not present in the LU message so are no longer available for use for that remote node. A local policy makes changes to the available L64 or NID values for the node or for a remote node. Overall, if {L_l} or {N_n} change, the ordered I-LV sequence, {A_a}, could change. However, as explained in , the ILCC maintains {L_l} and {N_n}, so {A_a} can be (re-)generated as needed.

Locally-defined I-LV values It is possible to define complete, fixed I-LV values locally, e.g. in /etc/hosts (please see ). If such local I-LV definitions exist, whether Source I-LV (for this node) or Destination I-LV (for a remote node), they MUST NOT be decomposed to separate L64 and NID values for the formation of other I-LV values for inclusion in the ordered I-LV sequence, {A_a}. I-LV values MUST be ordered according to the NID Preference value and L64 Preference value for that I-LV only for inclusion in {A_a}. This allows for a default local configuration if required, and also allows backwards compatibility with IPv6.

Preference values for locally-defined L64, NID, or I-LV values Overall, locally-defined values of L64s, NIDs, or I-LVs are subject to local policy. Where no such local policy exists, locally-defined L64, NID, or I-LV values SHOULD have explicit Preference values defined also, and those Preference values SHOULD be non-zero so that other dynamically generated or learned values with lower Preference values can be used as required. However, the "SHOULD" in the above text is specifically included so as not to constrain local policy or application-specific configuration.

Security Considerations There are no new security considerations. The existing security mechanisms already defined for ILNP remain unchanged (please see , ).

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 , , and .

IANA Considerations This document has no IANA actions.

This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] 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. This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. 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. 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. 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 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

Acknowledgements The author is 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. Gregor Haywood, Ryo Yanagida, and Rodney Grimes provided feedback on the original text for this document which helped to improve clarity. This work was partly supported by the ICANN Grant Program.