Subject: Re: [rrg] Proposal for recommendation language - ILNP & IPv4

From: [email-masked] (Noel Chiappa)
Date: Fri, 23 Apr 2010 11:07:59 -0400 (EDT)

> From: Robin Whittle <[email-masked]>

    > 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.)

    > As far as I know, this is not documented anywhere.

I am told there's something in the Springer paper, but unfortunately that's
not freely available online.

	Noel

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 23 Apr 2010 20:12:05 +0300

On Fri, Apr 23, 2010 at 6:07 PM, Noel Chiappa <[email-masked]> wrote:
>    > From: Robin Whittle <[email-masked]>
>
>    > How would ILNP work with the 32 bits of IPv4 address split between
>    > Locator and Identifier?
>
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