On Fri, Apr 23, 2010 at 6:07 PM, Noel Chiappa <[email protected]> wrote: > > From: Robin Whittle <[email protected]> > > > How would ILNP work with the 32 bits of IPv4 address split between > > Locator and Identifier? > > I have been informed offline that that's not how it works. The 32-bit fields > in the IPv4 header are used for source and destination locators. The endpoint > identifiers are carried 'elsewhere' - exactly where is not certain yet, but > an IPv4 option is currently the front-runner. (Hence the recent messages > about how core routers now mostly ignore IP options.) > Ah, then ILNPv4 and hIPv4 are not that far from each other - hIPv4 carries two 32-bit fields in a shim header, I'm calling them locators because I wanted to have a hierarchical address space, i.e 4 bytes x 4 bytes and the shim header should also get around the IP option issue.
In appendix E in my draft I tried to make my proposal compatible with CES-architectures, I also tried to put some rationale behind it. So hIPv4 is pretty much similar as a CES-architecture - got put in the map&encap basket by the chairs though this is a host based approach and thus not a pure map&encap solution - but I have no problem with that. What I think and trying to say in appendix E is that we have to start with a proxy solution, e.g. LISP, because it simply take too much time to upgrade hosts before some harvesting can be achieved. But the CES proposal shouldn't stop at the xTR level and exclude the option to upgrade the host stacks. There are also open questions with cache management, mapping databases etc, it is still work in progress. Think it is doable to integrate hIPv4 with CES, hIPv4 is only providing a new address scheme for CES and a glue to combine MPTCP with CES when it is integrated to the hosts. If there is scalability issues with e.g. ALT solution or caches, then the end user have an option to upgrade their host stack. In long term, the CES solution might be extended to host stacks as well - or have I missed something here? If you combine CES together with CEE approaches the senior management at enterprises has a toolkit to choose from - install a CES-node in front of your hosts, or - install a CES-node in front your hosts and upgrade some hosts, or - upgrade your hosts and give them options go either to IPv6 (ILNP) or to something that is backwards compatible with the current deployed stack. But that will take some effort and they have to give up something in return, also act promptly or they end up with IPv6. This way we don't tell the Internet citizens that "you have to upgrade to x or the wolf will get you" - with this approach the problem is "forwarded" to the Internet citizens, what to choose since the options do have some implications - their choice and they have to deal with it (and why should we decide in behalf of them?). Also, my deepest respect for Mr Eric Fleischman and RFC 1687 - I have seen that situation for a couple of years but to have that insight back in 1994!!! -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
