Identifier-Locator Network Protocol (ILNP):
Multipath addressing management and video-streaming demonstration @ IETF124/Montreal

Overview

This page is documentation of a set of experiments to demonstrate multipath transport, plus the first attempt at using multipath transport with ILNP for streaming video 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 and main meeting at IETF124/Montreal, 01-07 November 2025.
All the data (including pcap files) and graphs from the demonstration at IETF124/Montreal can be found at the University of St Andrews Research Portal (DOI: 10.17630/4af9d0f0-2b11-4161-b0ba-2730742394e6).
The ILNP distribution used for this demonstration can be found here.

IETF124/Montreal banner — (Photo: Saleem Bhatti)

Several experiments were executed which demonstrated:

Use of ILNP to manage addressing for multipath operation: TCP and UDP flows generated using iperf(3) transmitted over 4-way multihomed connectivity.
DASH video-streaming over multipath TCP: a nginx server (at St Andrews) and Firefox browser (Montreal) showed standard DASH-based streaming of video for a DASH / TLS / HTTP / TCP / ILNP 4-way multipath flow.

The experiments were run between a client system connected to the IETF network at IETF124/Montreal (Canada), 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, over the existing IPv6 global connectivity.

The 4 different paths were only dieferent on the last hop at the client-side: 4 different interfaces at the client, each with a separate ILNP Locator (L64, equivalent to an IPv6 /64 prefix). The flows used the existing TCP and UDP implementations that had not been modified to be aware of multipath operation. The objective was to show that the Locator Update signalling for ILNP will work across the Internet and allow the addressing management at the network layer, so that it is can be used potentially by any transport protocol, including existing (legacy) transport protocols.

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

Use of the end-to-end ILNP addressing architecture as described in RFC6740(E) [1] and RFC6741(E) [2].
Signalling with a ICMPv6 using a Locator Update (LU) message as described in RFC6743(E) [3].
The ILNP Nonce (the IPv6 Nonce Header Destination Option, an IPv6 end-to-end extension header) as described in RFC6744(E) [4].
Dynamic multihoming / multipath transport for TCP and UDP, as described in this paper [5].
An example of standard applications, in this case DASH streaming with dynamic multihoming / multipath transport TLS / TCP / ILNP 4-way multihoming.

The ILNP implementation that was used is available here (x86_64 binaries).

The Experiments, 01-07 November 2025

The network configuration for experiments was as shown in Figure 1, with the testbed as shown in Figure 2. iperf3(1) was used for client and server for the multipath experiments for TCP and UDP.

The network configuration for the multipath DASH streaming experiments was as shown in Figure 2a, with the testbed as shown in Figure 2b. nginx was used at the server node, in St Andrews, and a Firefox at the client node, in Montreal.

IETF124/Montreal experimental network configuration for TCP and UDP multipath — **Figure 1. A high-level diagram of the layer-3 end-to-end connectivity for the experiments at IETF124/Montreal for TCP and UDP multipath.** The server 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. was connected on 2001:630:31:1a::/64. The client was 4-way multihomed, with four separate interfaces each using one of the routing-prefix values shown in the diagram (see Figure 1a for details of the testbed network at the IETF Hackathon site).

IETF126/Vienna Hackathon testbed — (Photo: Saleem Bhatti)
**Figure 2. The testbed set-up at IETF124/Montreal.** The client 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 (right, middle, background, not so easily visible), 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 v2.0.9). 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 1a). The 24-port ethernet switch (Netgear GS724Tv3, firmware version 5.4.2.30) was used to provide VLANs for each of the four IPv6 networks.

Results

Data archive download. (DOI: 10.17630/4af9d0f0-2b11-4161-b0ba-2730742394e6).

References to c1c1 are to the client node (IETF124/Montreal).
References to demo1 are to the server node (St Andrews).

Connectivity

traceroute6: St Andrews to IETF124/Montreal | IETF124/Montreal to St Andrews

TCP / UDP multipath

4-way dynamic multipath with flow migration across paths.

iperf3, TCP 4-way multipath, c1c1 (client at IETF) to demo1 (server at St Andrews):
html | png
iperf3, UDP 4-way multipath, c1c1 (client at IETF) to demo1 (server at St Andrews):
html | png

4-way dynamic multipath with use of simultaneous multiple paths.

iperf3, TCP 4-way multipath, demo1 (client at St Andrews) to c1c1 (server at IETF):
html | png
iperf3, UDP 4-way multipath, demo1 (client at St Andrews) to c1c1 (server at IETF):
html | png

DASH video-streaming

IETF124/Montreal video streaming example — **Figure 3. An example of multipath video-streaming experiment**. 4-way mutlihoming at the client over TCP, and the video flow migrating across the 4 available paths.

DASH video single stream (baseline), c1c1 (client at IETF) streaming from demo1 (server at St Andrews):
html | png
DASH video 4-way multipath, c1c1 (client at IETF) streaming from demo1 (server at St Andrews):
html | png

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] RFC6743(E) ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6), November 2012.
[4] RFC6744(E) IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6), November 2012.
[5] Mobility-Multihoming Duality. Future Internet, vol. 16, no. 10, pages 1-42. October 2024. DOI: 10.3390/fi16100358.

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.

Identifier-Locator Network Protocol (ILNP): Multipath addressing management and video-streaming demonstration @ IETF124/Montreal