ILNP textual representations
draft-bhatti-ilnp-textual-representations-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) | |
|---|---|---|---|
| Authors | Saleem N. Bhatti , Gregor Haywood , Ryo Yanagida , Rodney Grimes | ||
| 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-textual-representations-00
Network Working Group S. N. Bhatti
Internet-Draft University of St Andrews, UK
Updates: 6740, 6741, 6742 (if approved) G. T. Haywood
Intended status: Experimental Abertay University, UK
Expires: 9 November 2026 R. Yanagida
University of St Andrews, UK
R. W. Grimes
Independent, USA
8 May 2026
ILNP textual representations
draft-bhatti-ilnp-textual-representations-00
Abstract
The Identifier Locator Network Protocol (ILNP) for IPv6 is described
in Experimental RFCs 6740-6744. This document describes how values
for ILNP data-types SHOULD be represented in textual form. These
data-types are: the Locator (L64), the Node Identifier (NID), and the
Identifier-Locator Vector (I-LV). The notation for the textual
representation is defined formally. Use-cases are provided as
examples of real world usage. This document updates RFC6740,
RFC6741, RFC6742.
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-textual-
representations/.
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/.
Bhatti, et al. Expires 9 November 2026 [Page 1]
Internet-Draft ILNP text May 2026
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
2.1. Definitions from other documents . . . . . . . . . . . . 4
3. Updates to previous RFC documents . . . . . . . . . . . . . . 5
3.1. RFC6740 and RFC6741 . . . . . . . . . . . . . . . . . . . 5
3.2. RFC6742 . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Textual representations of ILNP data-types . . . . . . . . . 5
4.1. ABNF definitions . . . . . . . . . . . . . . . . . . . . 5
4.2. Preference values . . . . . . . . . . . . . . . . . . . . 6
4.3. L64 values . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. NID values . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. I-LV values . . . . . . . . . . . . . . . . . . . . . . . 8
5. Common use case scenarios . . . . . . . . . . . . . . . . . . 8
5.1. Use case 1: Displaying packets from a traffic trace . . . 8
5.2. Use case 2: DNS server configuration files, such as zone
files . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Use case 3: /etc/hosts . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A : ABNF definitions . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Bhatti, et al. Expires 9 November 2026 [Page 2]
Internet-Draft ILNP text 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.
These data-types are realised and used within the context of IPv6
[RFC6741]: an ILNP packet will use the address fields in an IPv6
packet [RFC8200] to carry I-LV values constructed from L64 and NID
values.
An ILNP node can use multiple L64 values and multiple NID values
simultaneously, with separate Preference values associated with each
L64 value and each NID value. Lower Preference is preferred. Using
Preference values, I-LV values can be formed from individual L64
values and individual NID values as described in
[draft-bhatti-ilnp-preference].
L64 values with Preference values are also present in ILNP Locator
Update (LU) messages as defined in [RFC6743].
1.1. Purpose
This document describes a notation for textual representation of L64
values, NID values, and I-LV values, such that when those values are
displayed for use by humans:
1. Any L64, NID, or I-LV values can be easily identified and
distinguished from each other.
2. Any L64, NID, or I-LV values are not confused as malformed or
partial IPv6 addresses.
Effectively, the notation described in this document introduces
implicit typing information within the written or displayed value
definitions for L64, NID, and I-LV data-types.
Bhatti, et al. Expires 9 November 2026 [Page 3]
Internet-Draft ILNP text May 2026
ILNP is defined for use with IPv6 and for use with IPv4, but all
references in this document to ILNP are for IPv6 only.
1.2. Rationale
The textual representation specified in this document could help to
avoid confusion or errors in written communication and configuration
definitions when ILNP is used. For ILNP, the separate L64 and NID
values, as well as I-LV values, are used directly. So, having a
separate, unambiguous notation for such values, different to IPv6, is
valuable for both IPv6 users and ILNP users.
The notation for L64, NID, and I-LV values as specified in this
document can lead to a slightly more verbose display than for IPv6
addresses. However, this notation reduces the chances of confusion
between the display of ILNP addressing information and the display of
IPv6 addressing information, and also makes it clear when ILNP is in
use.
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 terms are defined in [RFC6740]:
* Locator, L64
* Node Identifier, NID
* Identifier-Locator Vector, I-LV
* Source I-LV
* Destination I-LV
The following terms are defined in [draft-bhatti-ilnp-preference]:
* L64 Preference
* NID Preference
Bhatti, et al. Expires 9 November 2026 [Page 4]
Internet-Draft ILNP text May 2026
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].
3.1. RFC6740 and RFC6741
For [RFC6740] and [RFC6741], along with
[draft-bhatti-ilnp-preference], this document clarifies the use of
Preference values for both L64 and NID values.
3.2. RFC6742
For [RFC6742], this document defines the notation that SHOULD be used
for L64 and NID values including Preference values.
The examples in RFC6742 use the colon-separated notation for IPv6
addresses to specify values for L64s and NIDs. Such examples SHOULD
use the notation defined in this document, i.e. as described in
Section 4.3, Section 4.4, with examples in Section 5.2.
4. Textual representations of ILNP data-types
The notation described in this document SHOULD be used whenever
values for a L64, a NID, or an I-LV are presented and intended for
human consumption, e.g. in written documents, as text output from an
application, or in configuration files that are read or written by
humans.
This description uses the Augmented BNF notation described in
[RFC5234], with the "Core Rules" from Appendix B.1 of [RFC5234]. The
various sub-sections below specify the definitions for each data-
type. A complete ABNF specification of the data-types defined in
this document can be found in Appendix "Appendix A : ABNF
definitions".
4.1. ABNF definitions
The additional basic types that are used in this document are defined
in Figure 1.
Bhatti, et al. Expires 9 November 2026 [Page 5]
Internet-Draft ILNP text May 2026
h16 = 1*4HEXDIG ; positive integer, hexadecimal, range 0-ffff
d16 = 1*5DIGIT ; positive integer, decimal, range 0-65535
Figure 1: New basic type definitions for ILNP textual
representations.
4.2. Preference values
A L64 or NID Preference value is a 16-bit, positive, unsigned
integer, with the range 0-65535. To give the Preference value
contextual relevance, it SHOULD be used in relation to a L64 or NID
value as described, respectively, in Section 4.3 and Section 4.4. A
L64 or NID Preference value is represented in textual form as defined
in Figure 2:
preference = d16
Figure 2: Definition for a (L64 or NID) Preference value.
The use of a L64 or NID Preference value for ILNP addressing is
described in [draft-bhatti-ilnp-preference].
4.3. L64 values
A L64 is a 64-bit value (8 bytes, in network / canonical byte order),
that has the same syntax and semantics as a 64-bit IPv6 64-bit
address prefix. A L64 value is represented in textual form as
defined in Figure 3:
l64-value = ["(" preference ")"] h16 "-" h16 "-" h16 "-" h16
Figure 3: Notation for a L64 value with a L64 Preference.
The separator between h16 elements, "-", is a "minus" sign.
A L64 Preference value is OPTIONAL, but it is RECOMMENDED that a L64
Preference value is specified. If no L64 Preference value is given,
its value is considered to be zero.
Two examples of L64 values are given in Figure 4 along with what
might be considered numerical (but not exact) equivalents in IPv6,
i.e. for an address prefix:
Bhatti, et al. Expires 9 November 2026 [Page 6]
Internet-Draft ILNP text May 2026
2001-db8-0-1 # L64 by itself, L64 Preference is zero
(42)2001-db8-0-4242 # L64 with a L64 Preference value
2001:db8:0:1::/64
2001:db8:0:4242::/64
Figure 4: L64 example values (top), with their closest numerical
(though not exact) equivalents in IPv6 (bottom). The L64 value
is 64 bits, the IPv6 value is 128 bits with a 64 bit mask.
The IPv6 address prefix value still implies 128 bits with a mask,
while an ILNP L64 value is 64 bits only. The L64 Preference value
has no direct equivalent for an IPv6 address prefix.
4.4. NID values
A NID is a 64-bit value (8 bytes, in network / canonical byte order),
that has the same syntax as an IPv6 IID. A NID value is represented
in textual form as defined in Figure 5:
nid-value = ["(" preference ")"] h16 "+" h16 "+" h16 "+" h16
Figure 5: Notation for a NID value with a NID Preference.
The separator between h16 elements, "+", is a "plus" sign.
A NID Preference value is OPTIONAL, but it is RECOMMENDED that a NID
Preference value is specified. If no NID Preference value is given,
its value is considered to be zero.
Two examples of NID values are given in Figure 6 along with what
might be considered numerical (but not exact) equivalents in IPv6,
i.e. for an IID:
abcd+0+0+1 # NID by itself, NID Preference is zero
(42)abcd+0+0+4242 # NID with a NID Preference value
::abcd:0:0:1
::abcd:0:0:4242
Figure 6: NID example values (top), with their closest numerical
(though not exact) equivalents in IPv6 (bottom). The NID value
is 64 bits, the IPv6 value is 128 bits with zero value bytes in
the top 64 bits.
The IPv6 IID value still implies 128 bits, while an ILNP NID value is
64 bits only. The NID Preference value has no direct equivalent for
an IPv6 IID.
Bhatti, et al. Expires 9 November 2026 [Page 7]
Internet-Draft ILNP text May 2026
4.5. I-LV values
An I-LV value is the concatenation of a single L64 value with a
single NID value separated by a "." (full-stop or period), as defined
in Figure 7.
ilv-value = l64-value "." nid-value
Figure 7: Notation for an I-LV value
Two examples of I-LV values are as shown in Figure 8 along with
numerical (but not exact) equivalents in IPv6, i.e. IPv6 addresses:
2001-db8-0-1.abcd+0+0+1
(11)2001-db8-0-1111.(22)abcd+0+0+2222
2001:db8:0:1:abcd::1
2001:db8:0:1111:abcd::2222
Figure 8: I-LV example values (top), with their closest numerical
(though not exact) equivalents in IPv6 (bottom). I-LV values are
128 bits as are IPv6 addresses, but I-LVs and IPv6 addresses do
not have the same semantics and use at end-systems.
As already noted above for NID and L64 values, the respective
Preference values in ILNP have no equivalent in IPv6.
5. Common use case scenarios
This section contains three use-cases of this notation. These
examples are not intended to be exhaustive, but represent what the
authors believe to be three common application scenarios in which the
textual representations defined in this document are likely to be
used (outside of use in written documents).
Note that for applications using common software libraries for name
resolution, the document [draft-bhatti-ilnp-ip6-apps] describes how
ILNP addressing values are used for IPv6 applications.
5.1. Use case 1: Displaying packets from a traffic trace
When displaying packets that are part of a packet trace capture, if
an ILNP packet is detected (i.e. an IPv6 packet with the Nonce Header
[RFC6744]), the addressing information for the packet SHOULD be
displayed as an ILNP I-LV rather than as an IPv6 address.
Bhatti, et al. Expires 9 November 2026 [Page 8]
Internet-Draft ILNP text May 2026
The example in Figure 9 shows first a line of output (single packet)
from a traffic capture display where the application is not ILNP-
aware, and then the same line when the application is ILNP-aware.
16:52:37.525246 IP6 2001:db8:a:a::1 > 2001:db8:b:b::2
DSTOPT (type 0x8b: len=4) 50117 > 22: TCP Flags [.], cksum 0x8edd ...
16:52:37.525246 ILNP/IP6 2001-db8-a-a.0+0+0+1 > 2001-db8-b-b.0+0+0+2
DSTOPT (type 0x8b: len=4) 50117 > 22: TCP Flags [.], cksum 0x8edd ...
Figure 9: Example use of I-LV syntax in the display of a TCP
packet trace for an ILNP-aware application (bottom) compared to
an IPv6 application (top). IPv6 Destination Option Type 0x8b is
for the Nonce Header (RFC6744) which identifies an ILNP packet.
Additionally, the Locator Update (LU) message for ILNP as defined in
[RFC6744] is an ICMPv6 message that carries L64 values with L64
Preference values as part of its payload. So, a traffic capture
application SHOULD also display such values as described in
Section 4.3.
Please note that for the example in Figure 9, the format of the
output for a specific traffic capture application need not be exactly
as shown: the purpose of the example is to demonstrate how the
notation for I-LV values can be used in such cases for clear
identification of ILNP packets.
In such applications, display options typically allow the user to
select the nature of the output, and so it is not the intention of
this document to constrain either user choice or the flexibility of
visual display. For example, the user might prefer to have I-LVs
displayed as IPv6 addresses.
5.2. Use case 2: DNS server configuration files, such as zone files
DNS entries for L64 RRs and NID RRs MUST contain a Preference value
[RFC6742]. When a node receives L64 and NID RRs in response to a DNS
query, that indicates that the remote node is ILNP-capable, and so
ILNP-based communication can be initiated.
So, the DNS zone file entries SHOULD use the notation for L64 and NID
values as in Figure 10.
node-3 IN L64 (10)2001-db8-3-1
node-3 IN L64 (20)2001-db8-3-2
node-3 IN NID (10)0+0+0+31
node-3 IN NID (20)0+0+0+32
node-3 IN NID (30)0+0+0+33
Bhatti, et al. Expires 9 November 2026 [Page 9]
Internet-Draft ILNP text May 2026
Figure 10: Example of how L64 and NID values might appear in a
DNS zone configuration file.
Please note that for the example in Figure 10, the syntax for a zone
file for a specific DNS server application need not be exactly as
shown: the purpose of the example is to demonstrate how the notations
for L64 and NID values can be used for unambiguous configuration of
L64 and NID values.
5.3. Use case 3: /etc/hosts
In normal operation, an ILNP-capable node will perform a DNS query
and could receive L64 and NID RRs indicating that the remote node is
ILNP-capable also. However, in some circumstances, such as for use
in an experimental testbed or for debugging scenarios, it might be
practical or useful not to use DNS for name resolution.
In many end-system operating systems, name to address mappings can be
specified locally in a hosts database (as described in hosts(5)),
e.g. in /etc/hosts. For ILNP, I-LVs can be used in such a local
mapping file. Source I-LV values or Destination I-LV values can be
specified, as is the case for IPv6 addresses. Example entries in
/etc/hosts for a basic use of ILNP would be as shown in Figure 11,
i.e. I-LVs without Preference values.
2001-db8-0-1.abcd+0+a+1 node-a1.ilnp # a remote node
2001-db8-0-1.abcd+0+a+2 node-a2.ilnp # another remote node
Figure 11: Example entries in `/etc/hosts` for I-LV values
without Preference values.
Where the L64 Preference or NID Preference is not included, the
Preference value is considered to be zero. The I-LV entries for
node-a1.ilnp and node-a2.ilnp in Figure 11 are numerically equivalent
to two different address entries for IPv6. This might be for two
separate nodes, or two separate interfaces on the same node, or even
two addresses on the same interface. However, ILNP-based
communication will be initiated instead of IPv6-based communication
for node-a1.ilnp and node-a2.ilnp.
In Figure 12 is an example with Preference values for the L64 only.
If a node is sending a packet to node-b1.ilnp, the node would use the
_first_ I-LV: both values have the same Preference value for the NID
(zero), but the first entry for node-b1.ilnp has a lower Preference
value for the L64.
(1)2001-db8-0-1.abcd+0+b+1 node-b1.ilnp # a remote node
(2)2001-db8-0-2.abcd+0+b+1 node-b1.ilnp # the same remote node
Bhatti, et al. Expires 9 November 2026 [Page 10]
Internet-Draft ILNP text May 2026
Figure 12: Example entries in `/etc/hosts` for I-LV values using
L64 Preference.
For the examples in Figure 13, with Preference values also for the
NID, the second entry for node-c1.ilnp would be used because of the
lower Preference value for the NID.
(1)2001-db8-0-1.(2)abcd+0+c+2 node-c1.ilnp # a remote node
(2)2001-db8-0-2.(1)abcd+0+c+1 node-c1.ilnp # the same remote node
Figure 13: Example entries in `/etc/hosts` for I-LV values using
L64 Preference and NID Preference.
A fuller explanation of this I-LV selection process is provided in
[draft-bhatti-ilnp-preference].
6. Security Considerations
There are no new security considerations.
Security considerations remain unchanged from those already defined
for ILNP (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 mechanisms already
defined for ILNP remain unchanged (please see Section 10 of
[RFC6740], Section 12 of [RFC6741], Section 7 of [RFC6748]).
8. IANA Considerations
This document has no IANA actions.
9. 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-preference]
Bhatti, S. N., "ILNP addressing using Preference values",
8 May 2026. A related draft that is being produced in
parallel.
Bhatti, et al. Expires 9 November 2026 [Page 11]
Internet-Draft ILNP text May 2026
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
[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>.
[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>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/rfc/rfc7405>.
[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>.
Bhatti, et al. Expires 9 November 2026 [Page 12]
Internet-Draft ILNP text May 2026
[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>.
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_.
Appendix A : ABNF definitions
Below are the complete definitions for this document based on
Augmented BNF as defined in [RFC5234] (consistent with the [RFC7405]
update to [RFC5234]).
; start: RFCxxxx "ILNP textual representations", ABNF definitions
h16 = 1*4HEXDIG ; positive integer, hex, range 0-ffff
d16 = 1*5DIGIT ; positive integer, decimal, range 0-65535
preference = d16
l64-value = ["(" preference ")"] h16 "-" h16 "-" h16 "-" h16
nid-value = ["(" preference ")"] h16 "+" h16 "+" h16 "+" h16
ilv-value = l64-value "." nid-value
; end: RFCxxxx "ILNP textual representations", ABNF definitions
Authors' Addresses
Saleem N. Bhatti
University of St Andrews, UK
Email: saleem@st-andrews.ac.uk
Bhatti, et al. Expires 9 November 2026 [Page 13]
Internet-Draft ILNP text May 2026
Gregor T. Haywood
Abertay University, UK
Email: g.haywood@abertay.ac.uk
Ryo Yanagida
University of St Andrews, UK
Email: ryo@htonl.net
Rodney W. Grimes
Independent, USA
Email: rgrimes@FreeBSD.org
Bhatti, et al. Expires 9 November 2026 [Page 14]