ILNP addressing using Preference values
draft-bhatti-ilnp-preference-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Saleem Bhatti | ||
| Last updated | 2026-05-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bhatti-ilnp-preference-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/rfc/rfc3972>.
[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,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012,
<https://www.rfc-editor.org/rfc/rfc6740>.
[RFC6741] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Engineering Considerations", RFC 6741,
DOI 10.17487/RFC6741, November 2012,
<https://www.rfc-editor.org/rfc/rfc6741>.
[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,
<https://www.rfc-editor.org/rfc/rfc6742>.
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,
<https://www.rfc-editor.org/rfc/rfc6743>.
[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, <https://www.rfc-editor.org/rfc/rfc6744>.
[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, <https://www.rfc-editor.org/rfc/rfc6748>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
May 2013, <https://www.rfc-editor.org/rfc/rfc6939>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[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,
<https://www.rfc-editor.org/rfc/rfc8981>.
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,
<https://doi.org/10.1109/icnp52444.2021.9651909>.
[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,
<https://doi.org/10.3390/cryptography8020022>.
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,
<https://doi.org/10.3390/fi17050196>.
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]