]> University of St Andrews, UK

saleem@st-andrews.ac.uk

Abertay University, UK

g.haywood@abertay.ac.uk

University of St Andrews, UK

ryo@htonl.net

Independent, USA

rgrimes@FreeBSD.org

Network Network Working Group Identifier Locator Network Protocol (ILNP) Identifier-Locator Vector (I-LV) Locator (L64) Node Identifier (NID) DNS 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. Status information for this document may be found at . Discussion of this document takes place on the Network Network Working Group mailing list ().

Introduction The Identifier Locator Network Protocol (ILNP) redefines the IP addressing architecture by use of new addressing data-types . 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 : an ILNP packet will use the address fields in an IPv6 packet 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 . L64 values with Preference values are also present in ILNP Locator Update (LU) messages as defined in .

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: Any L64, NID, or I-LV values can be easily identified and distinguished from each other. 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. ILNP is defined for use with IPv6 and for use with IPv4, but all references in this document to ILNP are for IPv6 only.

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.

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 when, and only when, they appear in all capitals, as shown here.

Definitions from other documents The following terms are defined in : Locator, L64 Node Identifier, NID Identifier-Locator Vector, I-LV Source I-LV Destination I-LV The following terms are defined in : L64 Preference NID Preference

Updates to previous RFC documents RFC documents that are updated by this document are: RFC6740 "Identifier-Locator Network Protocol (ILNP) Architectural Description" . RFC6741 "Identifier-Locator Network Protocol (ILNP) Engineering Considerations" . RFC6742 "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)" .

RFC6740 and RFC6741 For and , along with , this document clarifies the use of Preference values for both L64 and NID values.

RFC6742 For , 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 , , with examples in .

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 , with the "Core Rules" from . 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 .

ABNF definitions The additional basic types that are used in this document are defined in .

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 and . A L64 or NID Preference value is represented in textual form as defined in :

The use of a L64 or NID Preference value for ILNP addressing is described in .

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 :

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 along with what might be considered numerical (but not exact) equivalents in IPv6, i.e. for an address prefix:

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.

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 :

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 along with what might be considered numerical (but not exact) equivalents in IPv6, i.e. for an IID:

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.

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 .

Two examples of I-LV values are as shown in along with numerical (but not exact) equivalents in IPv6, i.e. IPv6 addresses:

As already noted above for NID and L64 values, the respective Preference values in ILNP have no equivalent in IPv6.

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 describes how ILNP addressing values are used for IPv6 applications.

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 ), the addressing information for the packet SHOULD be displayed as an ILNP I-LV rather than as an IPv6 address. The example in 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.

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 ... ]]>

Additionally, the Locator Update (LU) message for ILNP as defined in 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 . Please note that for the example in , 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.

Use case 2: DNS server configuration files, such as zone files DNS entries for L64 RRs and NID RRs MUST contain a Preference value . 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 .

Please note that for the example in , 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.

Use case 3: Entries in the /etc/hosts file 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 , i.e. I-LVs 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 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 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.

For the examples in , 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.

A fuller explanation of this I-LV selection process is provided in .

Security Considerations There are no new security considerations. Security considerations remain unchanged from those already defined for ILNP (please see , ).

Privacy Considerations There are no new privacy considerations. The existing identity privacy and location privacy mechanisms already defined for ILNP remain unchanged (please see , , ).

IANA Considerations This document has no IANA actions.

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community. This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. University of St Andrews, UK A related draft that is being produced in parallel. University of St Andrews, UK Abertay University, UK University of St Andrews, UK Independent, USA A related draft that is being produced in parallel. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

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 (consistent with the update to ).