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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [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, . [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, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . 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]