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 i...@ietf.org 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 L.
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
heinerhum...@aol.com
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
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
