# Mobility-Multihoming Duality
## 8 Conclusions  
We have demonstrated a design and implementation for harmonised mobility and multihoming for the Internet Protocol based on an approach implemented as a superset of IPv6. We have considered the key addressing and naming issues for the architecture, as well as the dynamic bindings of layer-specific names to objects in a network architecture. We have shown that it is possible to implement a _mobility-multihoming duality_ by managing those names and object bindings. Specifically, we have shown the following:  
* That current approaches to mobility and multihoming are restricted in their architectural approaches by relying on the re-use of IP addresses within their design. * The use of crisp, well-defined names for nodes (hosts) and networks. Along with well-defined dynamic bindings for those names within the network stack, we have a harmonised approach. This realises a model of network connectivity that is flexible enough to provide both mobility and multihoming together. * The use of ILNP with a simple signalling protocol and re-use of the IPv6 address space in IPv6 packets can be used to implement such a model of dynamic bindings for addressing. We have shown in our testbed experiments that such a model will operate over existing IPv6 networks. We have also shown that it can be used with existing TCP and UDP protocols, with good performance across end-to-end delays from \(\sim\)0 ms to 200 ms.  
* With a mechanism implemented at the network layer, applications using TCP and UDP can benefit from the use of ILNP without needing to be redesigned or re-engineered. Our experiments used traffic flows generated by iperf2 v2.0.9, the binary for which was not recompiled or modified in any way. Overall, our experiments suggest that existing applications could make use of harmonised mobility and multihoming capability with ILNP over an IPv6 network. Future Work  
In our discussion of Section 7 we have highlighted some potential challenges in real deployment scenarios for ILNP. The greatest of these from a practical point of view is that of deployment in scenarios with firewalls and middleboxes. These might use more detailed inspection of traffic, especially in an enterprise environment. We can imagine a user-space tool that writes to and reads from the network wire images of ILNP packets directly. Such a tool would allow for the transmission and reception of ILNP packets so that testing can be performed without having to deploy the ILNP kernel. Software libraries and APIs that allow low-level access to network interfaces are already available that would permit such a tool to be constructed. For practical purposes, it would be useful to measure the performance of some common applications running over ILNP. Our measurements in this paper show that TCP and UDP can operate over ILNP via the existing socket(3) API. That API forms the basis of many other software libraries and APIs implemented in popular high-level languages, such as Python, Rust, and Go. From a scientific perspective, we have ongoing work related to improvements in security and privacy for IP-based applications. These also exploit the clean naming and dynamic binding mechanisms provided by the ILNP architecture [46; 48]. Security and privacy are important areas for further improvement, as the Internet plays an increasingly prevalent role in service and information provision for many aspects of society and industry. Conceptualization, R.Y. and S.N.B. ; methodology, R.Y. and S.N.B. ; software, R.Y. ; validation, R.Y. and S.N.B. ; formal analysis, R.Y. and S.N.B. ; investigation, R.Y. ; resources, S.N.B. ; data curation, R.Y. ; writing--original draft preparation, R.Y. and S.N.B. ; writing--review and editing, R.Y. and S.N.B. ; visualization, R.Y. and S.N.B. ; supervision, S.N.B. ; project administration, S.N.B. ; funding acquisition, S.N.B. All authors have read and agreed to the published version of the manuscript. This research received no external funding. Summary data are contained within the article.