



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]
