Network Working Group S. N. Bhatti Internet-Draft University of St Andrews, UK Updates: 6740, 6741, 6742, 6748 (if approved) 8 May 2026 Intended status: Experimental Expires: 9 November 2026 ILNP addressing using Preference values draft-bhatti-ilnp-preference-00 Abstract 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. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bhatti-ilnp-preference/. Discussion of this document takes place on the Network Network Working Group mailing list (mailto:saleem@st-andrews.ac.uk). 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 https://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 9 November 2026. Bhatti Expires 9 November 2026 [Page 1] Internet-Draft ILNP Preferences May 2026 Copyright Notice Copyright (c) 2026 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 2.1. Definitions from other documents . . . . . . . . . . . . 5 2.2. New definitions . . . . . . . . . . . . . . . . . . . . . 5 3. Updates to previous RFC documents . . . . . . . . . . . . . . 6 3.1. RFC6740 and RFC6741 . . . . . . . . . . . . . . . . . . . 6 3.2. RFC6742 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. RFC6748 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Purpose of the Preference value . . . . . . . . . . . . . . . 6 4.1. Presence of Preference values . . . . . . . . . . . . . 7 4.2. Discovery of Preference values . . . . . . . . . . . . . 7 4.3. Use of Preference values in constructing I-LV values . . 7 5. General method for generating I-LV values from L64 and NID values . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. I-LV construction . . . . . . . . . . . . . . . . . . . . 8 5.2. Source I-LV construction . . . . . . . . . . . . . . . . 9 5.3. Destination I-LV construction . . . . . . . . . . . . . . 10 5.4. Selection of I-LV values . . . . . . . . . . . . . . . . 10 5.5. Changes to the lists of L64 and NID values . . . . . . . 11 5.6. Locally-defined I-LV values . . . . . . . . . . . . . . . 12 5.7. Preference values for locally-defined L64, NID, or I-LV values . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Bhatti Expires 9 November 2026 [Page 2] Internet-Draft ILNP Preferences May 2026 1. Introduction The Identifier Locator Network Protocol (ILNP) redefines the IP addressing architecture by use of new addressing data-types [RFC6740] [RFC6741]. 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 [RFC6741]. An ILNP packet will use the address fields in an IPv6 packet header [RFC8200] 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 Figure 1. IPv6 (RFC8200 / STD86) – general IPv6 global address format: | 3 | 45 bits | 16 bits | 64 bits | +---+---------------------+---------+----------------------------------+ |001|global routing prefix|subnet ID| Interface Identifier (IID) | +---+---------------------+---------+----------------------------------+ ILNP (RFC6741) – Identifier Locator Vector (I-LV): | 64 bits | 64 bits | +---+---------------------+---------+----------------------------------+ | Locator (L64) | Node Identifier (NID) | +---+---------------------+---------+----------------------------------+ Figure 1: An IPv6 address (RFC8200 / STD86) and an ILNP Identifier-Locator Vector (RFC6741), as used in the address fields of the IPv6 packet header. Bhatti Expires 9 November 2026 [Page 3] Internet-Draft ILNP Preferences May 2026 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 [RFC6744] 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 [draft-bhatti-ilnp-nonce]. A more detailed description of the ILNP architecture and its relationship to IPv6 can be found in [RFC6740] and [RFC6741]. L64 and NID values also have corresponding DNS Resource Record (RR) definitions in [RFC6742], 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 [RFC6743]. 1.1. Purpose This document clarifies the way that Preference values are used in ILNP in the following ways: 1. The semantics of the Preference value as used with L64, NID, and I-LV values. 2. How I-LV values are formed using Preference values when a node has multiple L64 and NID values. 3. 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 [RFC6740] [RFC6742] in place of the L64 data- type), but that exercise is outside the scope of this document. 1.2. 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 [RFC6740] [RFC6741]. Bhatti Expires 9 November 2026 [Page 4] Internet-Draft ILNP Preferences May 2026 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 [draft-bhatti-ilnp-ip6-apps]. Use of DHCPv6 [RFC6939] specifically for ILNP is not yet defined, and is outside the scope of this document. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Definitions from other documents The following definitions are taken from [RFC6740]: * Locator, L64 * Node Identifier, NID * Identifier-Locator Vector, I-LV * I-L Communications Cache, ILCC * Source I-LV * Destination I-LV 2.2. 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 [RFC6740] [RFC6741] [RFC6748]. Bhatti Expires 9 November 2026 [Page 5] Internet-Draft ILNP Preferences May 2026 _NID Preference_ A Preference value for a NID value. This was not explicitly defined or discussed in [RFC6740] or [RFC6741], but it is clear from [RFC6742] that NID values also have a Preference. 3. Updates to previous RFC documents RFC documents that are updated by this document are: * RFC6740 "Identifier-Locator Network Protocol (ILNP) Architectural Description" [RFC6740]. * RFC6741 "Identifier-Locator Network Protocol (ILNP) Engineering Considerations" [RFC6741]. * RFC6742 "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)" [RFC6742]. * RFC6748 "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)" [RFC6748]. 3.1. RFC6740 and RFC6741 [RFC6740] discusses use of a Locator Preference Indicator (LPI) for L64 values, but does not discuss Preference values for NID values. [RFC6741] does not discuss Preference values. However, neither document states how Preference values are to be used by a node. 3.2. RFC6742 [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. 3.3. RFC6748 [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. 4. 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. Bhatti Expires 9 November 2026 [Page 6] Internet-Draft ILNP Preferences May 2026 4.1. 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: 1. A Preference value SHOULD be given for every L64 (L64 Preference) value or NID (NID Preference) value in use by a node. 2. 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. 3. 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 [RFC6743], 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 [draft-bhatti-ilnp-ip6-apps]. 4.2. Discovery of Preference values Preference values can be learned from DNS [RFC6742] 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 [RFC6742]. When learned from local configuration files, Preference values SHOULD be given with the respective definitions of values for L64s, NIDs, or I-LVs. 4.3. 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. Bhatti Expires 9 November 2026 [Page 7] Internet-Draft ILNP Preferences May 2026 1. 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. 2. 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 Section 5.6. Otherwise, this document (specifically Section 5) describes how Source I-LV values and Destination I-LV values MUST be constructed from L64 and NID values using their respective Preference values. 5. General method for generating I-LV values from L64 and NID values 5.1. 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 Figure 2. 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. Bhatti Expires 9 November 2026 [Page 8] Internet-Draft ILNP Preferences May 2026 * 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 Figure 2: foreach nid in {N_n}: foreach l64 in {L_l}: A_a.append(l64::nid) Figure 2: General algorithm for generating a list of I-LV, the ordered I-LV sequence, {A_a}, from a list of L64 values, {L_l}, and a list of NID values, {N_n}. The lists {L_l} and {N_n} each MUST be ordered with increasing Preference value for their elements and MUST NOT contain, respectively, duplicate L64 or NID values. 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 Section 5.5 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 Section 5.4. For IPv6 applications running on an ILNP node, the use of {A_a} is described in [draft-bhatti-ilnp-ip6-apps]. 5.2. Source I-LV construction For Source I-LV values, L64 and NID values could be learned from a number of sources. Bhatti Expires 9 November 2026 [Page 9] Internet-Draft ILNP Preferences May 2026 As L64 values are IPv6 address prefixes, ILNP allows L64 values to be discovered via an IPv6 Router Advertisement (RA) [RFC4861]. ILNP NID values can be generated dynamically using any of the mechanisms defined for IPv6, e.g. for privacy by using [RFC8981] or [HB2025], or for verifiable addresses as in [RFC3972]. 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 Section 5.6 and Section 5.7. 5.3. 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 [draft-bhatti-ilnp-textual-representations]). L64 and NID RRs have Preference values [RFC6742]. 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 Section 5.6 and Section 5.7. 5.4. 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. Bhatti Expires 9 November 2026 [Page 10] Internet-Draft ILNP Preferences May 2026 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 [draft-bhatti-ilnp-ip6-apps]). 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. 5.5. 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: 1. L64 and NID values were discovered from DNS, and the Time-to-Live (TTL) for the respective DNS RR expires. 2. NID values were generated using privacy mechanisms and so have a limited lifetime based on the privacy mechanism used. 3. Routing changes mean that a L64 value discovered from an IPv6 RA expires and so cannot be used any longer. 4. An IPv6 RA appears that shows a new address prefix is available to use as a L64 value. 5. 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. 6. 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 Section 5.1, the ILCC maintains {L_l} and {N_n}, so {A_a} can be (re-)generated as needed. Bhatti Expires 9 November 2026 [Page 11] Internet-Draft ILNP Preferences May 2026 5.6. Locally-defined I-LV values It is possible to define complete, fixed I-LV values locally, e.g. in /etc/hosts (please see [draft-bhatti-ilnp-textual-representations]). 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. 5.7. 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. 6. Security Considerations There are no new security considerations. The existing security mechanisms already defined for ILNP remain unchanged (please see Section 9 of [RFC6740], Section 11 of [RFC6741]). 7. Privacy Considerations There are no new privacy considerations. The existing identity privacy and location privacy properties already defined for ILNP remain unchanged (please see Section 10 of [RFC6740], Section 12 of [RFC6741], Section 7 of [RFC6748]). NID values can also be generated using privacy mechanisms such as [RFC8981]. ILNP can also use enhanced identity privacy and location privacy mechanisms which remain backwards compatible with IPv6, such as described in [BHY2021], [HB2024], and [HB2025]. 8. IANA Considerations This document has no IANA actions. Bhatti Expires 9 November 2026 [Page 12] Internet-Draft ILNP Preferences May 2026 9. References 9.1. Normative References [draft-bhatti-ilnp-ip6-apps] Bhatti, S. N., Haywood, G. T., Yanagida, R., and R. W. Grimes, "ILNP usage by IPv6 applications", 8 May 2026. A related draft that is being produced in parallel. [draft-bhatti-ilnp-nonce] Bhatti, S. N., "Use of the ILNP Nonce Destination Option Header", 8 May 2026. A related draft that is being produced in parallel. [draft-bhatti-ilnp-textual-representations] Bhatti, S. N., Haywood, G. T., Yanagida, R., and R. W. Grimes, "ILNP textual representations", 8 May 2026. A related draft that is being produced in parallel. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [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, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6741] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, DOI 10.17487/RFC6741, November 2012, . [RFC6742] Atkinson, RJ., Bhatti, SN., and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, DOI 10.17487/RFC6742, November 2012, . Bhatti Expires 9 November 2026 [Page 13] Internet-Draft ILNP Preferences May 2026 [RFC6743] Atkinson, RJ. and SN. Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6743, DOI 10.17487/RFC6743, November 2012, . [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 2012, . [RFC6748] Atkinson, RJ. and SN. Bhatti, "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC 6748, DOI 10.17487/RFC6748, November 2012, . [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, May 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . 9.2. Informative References [BHY2021] Bhatti, S., Haywood, G., and R. Yanagida, "End-to-End Privacy for Identity & Location with IP", IEEE, 2021 IEEE 29th International Conference on Network Protocols (ICNP) pp. 1-6, DOI 10.1109/icnp52444.2021.9651909, November 2021, . [HB2024] Haywood, G. and S. Bhatti, "Defence against Side-Channel Attacks for Encrypted Network Communication Using Multiple Paths", MDPI AG, Cryptography vol. 8, no. 2, pp. 22, DOI 10.3390/cryptography8020022, May 2024, . Bhatti Expires 9 November 2026 [Page 14] Internet-Draft ILNP Preferences May 2026 [HB2025] Haywood, G. and S. Bhatti, "Ephemeral Node Identifiers for Enhanced Flow Privacy", MDPI AG, Future Internet vol. 17, no. 5, pp. 196, DOI 10.3390/fi17050196, April 2025, . 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_. Author's Address Saleem N. Bhatti University of St Andrews, UK Email: saleem@st-andrews.ac.uk Bhatti Expires 9 November 2026 [Page 15]