Re: [rrg] Rebooting the RRG

["Fleischman, Eric" <[e-mail]>]

Heiner,

It’s currently a lonely job in many large corporations to be an IPv6 specialist. I can’t help but wonder how many large corporations have plans to migrate away from IPv4? The view from my knothole is that RFC 1687 is as true today as it was in 1993 when I first wrote it. It’s more than just inertia – it’s also a very strong perception that IPv4 serves us very well.

Best wishes,

--Eric

From: rrg [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, November 19, 2013 3:20 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [rrg] Rebooting the RRG

Scott, you wrote:

Heiner, the IETF has said it doesn't want to come up with any more clever ways to help organizations continue to squeeze more life out of IPv4 addresses. It will help with transition away from IPv4. Thus IPv4 address depletion isn't a favored topic, and neither is making significant changes to Internet routing and/or addressing architecture in response. I suspect that ideas for routing multiple namespaces efficiently could be worth considering, but I would generalize it beyond just IPv4 and IPv6.  What else could you route?

Well, I know for quite a while that the IETF, and particularly the IESG, does not care for IPv4. On March 13 I wrote to the IESG:

 -----email to [e-mail]<mailto:[e-mail]> on 13th March 2013 -------------------Subject: IETF should not abandon IPv4 ---------------------------------------------------------------------


Dear Ladies and Sirs of the IESG,
I am writing this letter, being concerned about how IPv4 is going to be abandoned,
without having anything better instead (certainly not IPv6).

We are running out of IPv4 addresses. The hope was, that as a result of the loc-id-split idea each host-IPv4 address is combined with a Locator, as is well known from postal letters where the name of the receiving person (identifier) is enhanced with his postal address (locator). That locator could have been constructed such that the so-called scalability problem were gone forever. And that the IPv4 address depletion issue were solved: That the combination {host IPv4 address; Locator} would be globally unique, a) with the Locator being globally unique, b) with the host IPv4 address being unique just per that locator. Hereby the lifetime of IPv4 could have easily be extended for another thousand years.

When LISP started out 10 years ago several variants were envisioned but the chosen one (LISP-DDT) is unable to provide global uniqueness as described above, instead LISP-DDT relies and depends on globally unique IPv4 addresses.
I learnt that some months ago, when I argued on the LISP-mailinglist, that LISP-DDT can never work, by saying you cannot send a letter to Mr. Li (where there are millions of people with this name) and ask the ingress post office to add the proper address by itself. Indeed, LISP-DDT does lookup the Locator based on the destination’s IPv4 address and not based on its FQDN. Hereby I learnt that the LISP community presumes that the destination’s IPv4 address is globally unique in the first place, which however is a much greater problem ( as a matter of fact, I wasn’t worried about a failing LISP-DDT, as my own TARA solution is much better while considering Unicast, Multicast, Anycast alike, i.e. not Unicast only).

A working solution would have been if the host sends a query with input=FQDN of the desti-nation to the DNS and gets in one response the respective {(locator-unique) IPv4 address; globally unique Locator}. But LISP-DDT neither involves the user (host) nor the DNS ☹.

As a result the lifetime of IPv4 depends entirely on NAT, NAT, and again on NAT.  There are more re-known “Nat-haters” in the IETF-community who better than I know how troublesome NAT really is. Myself I like to add one argument: Imagine a Multicast instance whereby the sender is mobile and indeed roaming all over the world, just like the receivers!
(For this scenario I did work out a model whereby the entire multicast instance is identified by a globally unique Multicast-Locator which comprises 2 leading octets of the sender’s “home”-Unicast-Locator plus a unique 2 (or 3) octets sized number whose administration is shared by all those routers whose locators share the same leading 2 octets. You may consider this solution being a slight shift back towards MADCAP).
It would be pretty ugly to outline a respective solution whereby the multicast instance is PIM-like and  NAT depending.
I conclude that the doublet {globally unique Locator; locally unique IPv4 address} would be better than NATed IPv4.
But as I have shown, LISP-DDT does NOT provide this as to extend IPv4’s lifetime. Just the opposite, it eats up IPv4 addresses for its own deployment. It is also weird to see how it offers LISP-Locator based routing to IPv6 – just as if 16 octets are not enough. OK, the truth is that indeed 16 octets eventually could not be enough and that one needs, for ensuring successful detours, transit address points in addition which should be enabled by a flexible address size. (Routing to such transit address points based on GRE techniques is even worse by  taking even more octets.)
However LISP-DDT syntax does not cater for extendable LISP-headers either, such that LISP-locators of transit points can be included (my TARA-header however does !).

Hoping that the IESG does care about the IPv4’s fate, I am Yours Truly
Heiner Hummel

[e-mail]<mailto:[e-mail]>
www.hummel-research.de<http://www.hummel-research.de/>

-----------------------------------------end of email to the IESG ---------------------------------------------------------------------------------------------------------------------------------------------------------

I haven't got any response ever.

Given this sad situation I think that some other standardization body  ( I suggest ITU-T ) should give  home to IPv4 so that the IETF can give all its attention and spend all its effort to IPv6 ( which I despise just like Brian C. hates NAT .-).

"What else could you route?" .
 Well, if you read the referenced TARA-document issued by ICI GLOBAL you will see a lot about routing technology which is unfortunately not  (yet)
state of the art in the internet community, but which bears the potential that a young generation of students and IETF attendees can built on it for a long time.

Heiner