Identifier-Locator Network Protocol (ILNP):
DNS / IPv6 stack integration demonstration @ IETF126/Vienna

Overview

This page is documentation of a set of experiments to demonstrate the first successful public demonstration of the use of ILNP integrated with DNS and IPv6 over the global Internet. The experiments used an implementation of ILNP in FreeBSD.

Experiment design, execution, and analyses by Saleem Bhatti with results from the Hackathon at IETF26/Vienna, 18-19 July 2026.
All the data (including pcap files) and graphs from the demonstration at IETF26/Vienna can be found at the University of St Andrews Research Portal (DOI: 10.17630/6a8f5c05-4d52-49a7-a4c1-75e1a38d4158).
The ILNP distribution used for this demonstration can be found here.

IETF126/Vienna banner full size
(Photo: Saleem Bhatti)
Several experiments were executed which demonstrated: The experiments were run between a client system connected to the IETF network at the Hackathon (at IETF126/Vienna, Austria), and a server at the University of St Andrews (Scotland, UK). The experiments used native IPv6 applications to show that they can benefit directly from use of ILNP without needing to be modified: i.e. using DNS for name resolution (domain ilnp.net); existing binaries using the standard C sockets API; and communicating directly over an existing IPv6 network, with no proxies, no tunnelling, no address translation, and using standard unicast routing.

The experimental scenario was a simple client-server communication to demonstrate that the following mechanisms could operate across the Internet (at least between Vienna and St Andrews):

The ILNP implementation that was used is available here (x86_64 binaries). That implementation also included the functionality documented in the Internet Draft (ID) documents listed below.

All of the IDs are updates to one or more of RFCs 6740/1/3/4/8, based on implementation experience with FreeBSD (and previously with Linux), plus testing and experiments at Hackathon events at the following IETF meetings: IETF104/Prague, IETF105/Montreal, IETF106/Singapore, IETF118/Prague, IETF119/Brisbane, IETF120/Vancouver, IETF121/Dublin, IETF122/Bangkok, IETF123/Madrid, IETF124/Montreal, IETF126/Vienna.

The Experiments at the Hackathon, 18-19 July 2026

The network configuration was as shown in Figure 1. The testbed at the Hackathon venue was as shown in Figure 2.

On the server system, h1.usta.ilnp.net (h1 for short), in St Andrews, the following were executed: drill(1), traceroute6(8), and iperf3(1) as a server for both TCP and UDP.

On the client system, c1.ietf.ilnp.net (c1 for short), in Vienna, the following were executed: drill(1), traceroute6(8), and iperf3(1) as a client for both TCP and UDP.

The DNS server was also at St Andrews, serving domain ilnp.net. Both h1.usta.ilnp.net and c1.ietf.ilnp.net resolved only to L64 and NID records, not AAAA records.

IETF126/Vienna experimental network configuration full size
Figure 1. A high-level diagram of the layer-3 end-to-end connectivity for the experiments at the IETF126/Vienna Hackathon. The host h1.usta.ilnp.net hardware was based on a desktop system (8-core/16-thread AMD Ryzen 7 5800X CPU, 32GB RAM), but housed in a 1U case in a rack for convenience. h1 was connected on 2001:630:35:1a::/64, and was on a separate IPv6 network to the DNS authoritative server, though both were on the St Andrews campus. The client c1 was 4-way multihomed, with four separate interfaces each using one of the routing-prefix values shown in the diagram (see Figure 2 for details of the testbed network at the IETF Hackathon site). The DNS server was IPv6 only.
IETF126/Vienna Hackathon testbed full size
(Photo: Saleem Bhatti)
Figure 2. The testbed set-up at IETF126/Vienna. c1.ietf.ilnp.net was a small desktop machine (Lenovo ThinkCentre M720q, 6-core/6-thread Intel i5-8400T CPU, 16GB RAM) at the bottom right of the mini-rack, and was 4-way multihomed using a quad-ethernet Intel NIC (with the on-board NIC used for an IPv4-only control channel). A duplicate / spare desktop machine is to the left, and was not used. The single router at the top of the mini-rack is a commercial unit (Ubiquiti EdgeRouter ER-12, EdgeOS v3.0.1). The router was assigned 2001:67c/1232:eee0::/60, which was then split into 4x /64 prefixes, i.e. four, separate IPv6 networks (see Figure 1). The 24-port ethernet switch (Netgear JGS524Ev2, firmware version 2.6.0.48) was used to provide VLANs for each of the four IPv6 networks.

Results: 19 July 2026

Data archive download. (DOI: 10.17630/6a8f5c05-4d52-49a7-a4c1-75e1a38d4158).

DNS resolution

In Figure 3, h1 (letf) and c1 (right) are able to resolve each other's FQDNs via the public Quad9 DNS service (IPv6 addresses 2620:fe::fe and 2620:fe::9), using drill. Notice that each FQDN resolves only to L64 and NID records, not to AAAA. However, when traceroute6 runs on each machine, it works correctly using the FQDN values.

This basic test shows that L64 and NID records can be used by IPv6 applications via the libc/getaddrinfo(3) modifications for ILNP.

video | h1 traceroute6 output | c1 traceroute6 output

drill and traceroute6 showing use of L64 and NID records from DNS full size
Figure 3. Use of L64 and NID records only. IPv6 applications can still operate correctly because of the modifications in libc/getaddrinfo(3) that create the I-LV (from the L64 and NID values) and present it as an IPv6 address via the socket API.

TCP multipath

In Figure 4, on h1 (left), getaddrinfo(1) was used to show the DNS resolution of c1.ietf.ilnp.net, before an iperf3 server was started. On c1 (right), getaddrinfo(1) was used to show the DNS resolution of h1.usta.ilnp.net before an iperf3 client was started to h1. Once the client had started, additional interfaces were brought up on the client machine, each offering an additional L64 value (IPv6 prefix learned via IPv6 Router Advertisement messages), which were used by c1 to migrate the TCP connection to a multipath flow. The use of getaddrinfo(1) was simply for the purposes of demonstration of the name resolution, and was not required for iperf3 to function.

This showed that a TCP connection can be created for an IPv6 application, with the underlying socket end-points being ILNP end-points, so that flow is capable of multipath communication as part of normal ILNP operation. The L64 management at the network layer, with dynamic binding of NID and L64 values, means that any transport protocol can have multipath operation.

video | throughput graph

getaddrinfo, then an iperf3 TCP connection that is multipath capable because of ILNP full size
Figure 4. TCP multipath. An IPv6 TCP connection but with ILNP connection end-points, allowing the use of ILNP NID-to-L64 dynamic bindings for multipath communication to be used (different L64 values -- IPv6 prefixes -- labelled in the graphs as eee1, eee2, eee3, and eee4). The TCP flow was constrained to 4Mb/s at the client because the experiments were conducted across the IETF Hackathon network, which was shared with hundreds of other users at the event. Note that the flow was "regular" TCP (CUBIC, in this case), so it was not multipath-aware for its congestion control: with a more diverse set of multiple paths (in terms of end-to-end to delay, loss, and throughput), the overall end-to-end throughput might not have been so smooth unless the congestion control algorithm was designed to be multipath-aware.

UDP multipath

In Figure 5, an IPv6 UDP flow uses multipath operation. The network configuration used was identical to that for TCP, above (Figure 4), but for a UDP flow instead. Again, h1 (left) used getaddrinfo(1) to show DNS resolution of c1.ietf.ilnp.net, then an iperf3 server was started. On c1 (right), getaddrinfo(1) to demonstrate the DNS resolution of h1.usta.ilnp.net before an iperf3 client was started to h1. Again, as for the TCP experiment, at the client, additional interfaces were brought up and used by c1 to migrate the UDP flow to a multipath flow.

This showed that a UDP flow can be created for an IPv6 application, with the underlying socket end-points being ILNP end-points, allowing UDP multipath communication as part of normal ILNP operation. In essence, this is the same as for TCP: the dynamic binding of NID and L64 values allows the multipath flow.

video | throughput graph

getaddrinfo, then an iperf3 UDP flow that is multipath capable because of ILNP full size
Figure 5. UDP multipath. An IPv6 UDP flow but with ILNP end-points, allowing multipath communication to be used. The UDP flow was constrained to 4Mb/s at the client because the experiments were conducted across the IETF Hackathon network, which was shared with hundreds of other users at the event. As for the TCP experiment, there was little diversity observed for that end-to-end path on that execution (in terms of end-to-end to delay, loss, and throughput), so the overall end-to-end throughput was very smooth.

eNID for identity privacy

In Figure 6, the ephemeral NID (eNID) mechanism, as described in [7], was demonstrated. h1 was already running a standard ssh server, and a pcap capture was started on it. Then, on c1, nc was used to make 16 successive TCP connections to the ssh server. When the pcap file was examined for TCP handshakes, we found, as expected, that each had a different NID, so each looks like it came from a different remote host, improving identity privacy at the packet-level.

This demonstrated the late, dynamic binding capability of NID and L64 values in the ILNP addressing architecture. However, as 128-bit I-LV values can be used as IPv6 addresses, an IPv6 application can still make a TCP connection correctly from the same client machine to the same server over ILNP.

video | TCP conversations (from tshark, listed by NID value)

nc used to make successive TCP handshakes with ssh over ILNP to show eNID behaviour full size
Figure 6. Ephemeral NID (eNID) values for flows. The use of nc was to invoke a minimal TCP handshake to the ssh server, and then terminate the connection. The successive TCP connections by nc from c1 to h1 each have a different NID value, so flows from the same end-system cannot be so easily correlated and linked to a single user by an observer.

References

[1] RFC6740(E) Identifier-Locator Network Protocol (ILNP) Architectural Description, November 2012.
[2] RFC6741(E) Identifier-Locator Network Protocol (ILNP) Engineering Considerations, November 2012.
[3] RFC6742(E) DNS Resource Records for the Identifier-Locator Network Protocol (ILNP), November 2012.
[4] RFC6743(E) ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6), November 2012.
[5] RFC6744(E) IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6), November 2012.
[6] Mobility-Multihoming Duality. Future Internet, vol. 16, no. 10, pages 1-42. October 2024. DOI: 10.3390/fi16100358.
[7] Ephemeral Node Identifiers for Enhanced Flow Privacy. Future Internet, vol. 17, no. 5, pages 1-27. April 2025. DOI: 10.3390/fi17050196.

Acknowledgements

This work was partly supported by the ICANN Grant Program. The experiments were completed as part of the DIGS project.

Thanks go to the IETF NOC Team for providing connectivity to make the testing and experiments possible over many IETF meetings: at the Hackathon events, and in the Shared Workspace areas (sometimes under challenging circumstances).

Initial FreeBSD code development by Gregor Haywood.
FreeBSD porting and further development by Rodney Grimes and Saleem Bhatti.
Previous work on ILNP in Linux by Ryo Yanagida.

Contact

Saleem Bhatti (ILNP Project Lead).
ILNP main page.