Hi List,
I had an off-line continuation of my question with Gregor and Saleem. They have given me permission to forward their answers. All text from here on is theirs.
Thanks again to Gregor for the talk and to Saleem and Gregor for the responses.
Cheers,
Adrian
> What are your thoughts on deployment practicalities?
ILNP is designed to be end-to-end in the original sense and philosophy of the Internet architecture: only end-systems know about the identifier/locator semantic of the address bits, and so only end-systems need to be updated, e.g. via "over-the-air" updates as is common today for many OSs, desktop, server, and mobile.
There is information on backwards compatibility and incremental deployment in Section 8 of RFC6740(E):
https://datatracker.ietf.org/doc/html/rfc6740#section-8
and Section 10 of RFC6741(E):
https://datatracker.ietf.org/doc/html/rfc6741#section-10
ILNP can be realised as a superset of either IPv6 or IPv4. In reality, the IPv4 variant is impractical. However, the IPv6 variant looks readily deployable. Currently, I am only working on the IPv6 variant, and that is what I refer to when I talk about ILNP.
> Are there issues of interactions with existing routing and addressing
> systems?
I imagine that some of the answer to this questions is in the RFC sections listed above.
The addressing model (identifier / locator semantic) used by ILNP is visible only at end-systems: across the network, ILNP packets look like IPv6 packets. So, no need to modify routers and switches as long as they know how to deal with IPv6: they treat address fields in ILNP packets the same as they would for IPv6 packets.
> What about network OAM and security monitoring techniques? Are these made
> particularly hard by the random variations in addresses?
In its "vanilla" form (not implementing the work that Gregor described for the NIPAA paper [1]), ILNP has similar properties to IPv6 from the point of view of passive monitoring of traffic.
If ephemeral NIDs and ephemeral L64s are used, then you have the kind of additional challenge for monitoring as described by Gregor [1], which is, of course, the point of the work presented -- to perturb passive monitoring in keeping with Section 2 of RFC7258(BCP).
From an OAM perspective, where addresses have previously been assigned, e.g. to an interface, and then used as say, application-level identifier values, the OAM applications *could* break, but that would depend on how the values are actually used.
Firewalls and IPv6 NATs could cause a problem for ILNP. I currently have a Masters student working on a script-based tool to generate ICMPv6 packets to test ILNP connectivity / deployability without having to install an ILNP-enabled OS kernel.
[1] End-to-End Privacy for Identity & Location with IP. NIPAA-21 - 2nd Workshop on New Internetworking Protocols, Architecture and Algorithms (ICNP 2021). Virtual event (COVID-19). Nov 2021.
https://saleem.host.cs.st-andrews.ac.uk/publications/2021/nipaa21/nipaa21-bhy2021.pdf
Please let me know if you any further questions.
########################################################################
To unsubscribe from the SARAH list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=SARAH&A=1
This message was issued to members of www.jiscmail.ac.uk/SARAH, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
|
