ILNP textual representations

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

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

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.1. ABNF definitions

The additional basic types that are used in this document are defined in Figure 1.¶

h16 = 1*4HEXDIG ; positive integer, hexadecimal, range 0-ffff

d16 = 1*5DIGIT  ; positive integer, decimal, range 0-65535

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

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

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:¶

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

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

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

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

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

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

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

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

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

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

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

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

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

A fuller explanation of this I-LV selection process is provided in [draft-bhatti-ilnp-preference].¶