# Mobility-Multihoming Duality
## 3 Identifier Locator Network Protocol (ILNP)
### ILNP and IPv6  
Whilst the change in addressing architecture for ILNP is radical, we have implemented ILNP as a superset of IPv6. The IPv6 packet carries an IL-V in its address fields. This allows a L64 value to be realised as an IPv6 routing prefix, which constitutes the most significant 64 bits of an IPv6 address. The ILNP NID value is then inserted as the least significant bits of the IPv6 address. This is shown in Figure 1. The L64 has the same syntax and semantics as a routing prefix--a network name--and is the only part of the address bits used by the IPv6 core network components for the routing packets. So, ILNP packets can be carried across an IPv6 network. The NID has the same syntax as the Interface ID (IID) for an IPv6 address, but it has different semantics. However, as these semantics are only local to the host, updating the host is all that is required to deploy ILNP.  
For local forwarding, as for IPv6, ILNP uses the full 128 bits of the IL-V as part of IPv6 Neighbor Discovery (ND) [39]. So, ND mechanisms and implementations do not need to be modified--link layer (layer 2) protocols can forward ILNP packets as they would IPv6 packets, e.g., forwarding in layer 2 relays, such as switches.  
At the transport layer (layer 4), there are also differences in bindings with respect to the state held in the communication end points. The state bindings in IP, the tuple expression (1), show the state information for a communication end point at host \(X\) for TCP communication between hosts \(X\) and \(Y\). \(A\) values are IP addresses, \(P\) values are port numbers, and \(if\) designates an interface on the host.  
\[\langle tcp:P_{X},A_{X},P_{Y},A_{Y}\rangle\langle ip:A_{X},A_{Y}\rangle\langle if :A_{X}\rangle \tag{1}\]  
For ILNP, the state bindings are as in the tuple expression (2):  
\[\langle tcp:P_{X},N_{X},P_{Y},N_{Y}\rangle\langle ilnp:(L_{X}),(L_{Y})\rangle \langle if:(L_{X})\rangle \tag{2}\]  
The port numbers are unchanged. However, the TCP state is bound to the NID values (node names), \(N\), and the IP layer is now only concerned with L64 values (network names), \(L\). The binding notation \((\ldots)\) denotes a dynamic binding rather than the fixed binding in an IP.  
Then, tuple expression (3) shows what happens when the ILNP node moves from the network with name \(L_{X}\) to the network with name \(L_{A}\). The tuple expression (4) shows what  
Figure 1: Comparison of the IPv6 unicast address format with the ILNP unicast addressing format. The L64 value has the same syntax and semantics as the IPv6 routing prefix. The NID value has the same syntax as the IPv6 Interface Identifier, but it has different semantics. The NID-L64 pairing is an Identifier Locator Vector (IL-V), which can be used the same way as an IPv6 address.  
happens when the ILNP node becomes multihomed on networks with names \(L_{X}\) and \(L_{A}\). \(L\) values are ILNP L64 values that are the same as the IPv6 (routing) prefix values.  
\[\langle tcp:P_{X},N_{X},P_{Y},N_{Y}\rangle\langle ilnp:(L_{A}),(L_{Y}) \rangle\langle\textit{if}:(L_{A})\rangle \tag{3}\] \[\langle tcp:P_{X},N_{X},P_{Y},N_{Y}\rangle\langle ilnp:(L_{X}|L_{A }),(L_{Y})\rangle\langle\textit{if}:(L_{X}|L_{A})\rangle \tag{4}\]  
The ILNP-specific state information is held in a data structure called the _ILNP Communication Cache (ILCC)_, which is a logical entity within the host that we use in our description of ILNP.