Earlier, Patrick Frejborg wrote: > Ah, then ILNPv4 and hIPv4 are not that far from each other...
Correct, and that is not a coincidence. Both HIP and ILNP have their roots in the IRTF NSRG. There are limited ways to use off-the-shelf mechanisms to carry identifiers in IPv4. The ILNP designers have gone to some lengths to document that HIP-like mechanisms could fit inside the architecture (NB: This required no protocol changes in ILNP, just clarity of documentation.) Multiple ILNP papers have made it clear that one can also use a cryptographically-generated ID with ILNP. That might be a CGA-like thing. It also could be a HIT-like thing. (As a user, I do NOT want to use cryptography on all or even most of my packets, so I find that HIP's focus on cryptography isn't well aligned with my personal operational requirements. Other folks mileage may vary. Similarly, I find the CGA arguments non-persuasive and would not want to use a CGA for my own packets. ILNP leaves the ID generation flexible, so users can make choices sensible for local environments.) Later, he wrote: > ...give them options go either to IPv6 (ILNP) or > to something that is backwards compatible with > the current deployed stack. ILNP already *IS* backwards-compatible with the current deployed stack. So the quoted phrase, especially the word "or", is very confusing. RFC-1687 says many things (e.g. convergence with ISO CLNP would be nice). It wasn't obvious which part of that RFC Patrick was referring to. Yours, Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
