Subject: [rrg] hIPv4 revised critique

From: Robin Whittle <[email-masked]>
Date: Fri, 05 Mar 2010 12:35:12 +1100

Hi Patte,

hIPv4 is one of two proposals currently lacking a critique in:

  http://tools.ietf.org/html/draft-irtf-rrg-recommendation-05

The other is the Compact Routing proposal, but Hannu and I have sent
text for a critique and a "rebuttal" to Lixia and Tony.

I have read your revised Summary for hIPv4:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06150.html

which I assume will replace the current Summary.  The references
section is already up-to-date with:

  http://tools.ietf.org/html/draft-frejborg-hipv4-05

While I don't feel that I fully understand your proposal, and while I
don't have time to read it carefully to improve my understanding,
here is a critique which I hope will be included in the RRG Report.
Perhaps you could write a "rebuttal" ASAP so that too can be included.

This is not a properly appreciative assesment of your proposal, nor a
complete critique.  It concerns only the question of whether hIPv4 in
its current form would be chosen ahead of my Ivip proposal - which I
consider to be the best proposal for IETF development - or LISP,
which I consider to be the only other proposal which could be
suitable for IETF development.   My reasons for these choices are in
my recent "Recommendation suggestion from RW" message (msg06162).

  - Robin

hIPv4 revised critique - 468 words
----------------------------------

hIPv4 is an innovative approach to expanding the IPv4 addressing
system in order to resolve the scalable routing problem.  This
critique does not attempt a full assessment of hIPv4's architecture
and mechanisms.  The only question addressed here is whether hIPv4
should be chosen for IETF development in preference to, or together
with, the only two proposals which appear to be practical solutions
for IPv4: Ivip and LISP.

Ivip and LISP appear to have a major advantage over hIPv4 in terms of
support for packets sent from non-upgraded hosts/networks.  Ivip's
DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel
Routers) both accept packets sent by any non-upgraded host/network
and tunnel them to the correct ETR - so providing full benefits of
portability, multihoming and inbound TE for these packets as well as
those sent by hosts in networks with ITRs.  hIPv4 appears to have no
such mechanism - so these benefits are only available for
communications between two upgraded hosts in upgraded networks.

This means that significant benefits for adopters - the ability to
rely on the new system to provide the portability, multihoming and
inbound TE benefits for all, or almost all, their communications -
will only arise after all, or almost all networks upgrade their
networks, hosts and addressing arrangements.  hIPv4's relationship
between adoption levels and benefits to any adopter therefore are far
less favourable to widespread adoption than those of CES
architectures such as Ivip and LISP.

This results in hIPv4 also being at a disadvantage regarding the
achievement of significant routing scaling benefits - which likewise
will only result once adoption is close to ubiquitous.  Ivip and LISP
can provide routing scaling benefits in direct proportion to their
level of adoption, since all adopters gain full benefits for all
their communications, in a highly scalable manner.

hIPv4 requires stack upgrades, which are not required by any CES
architecture.  Furthermore, a large number of existing IPv4
application protocols convey IP addresses between hosts in a manner
which will not work with hIPv4:  "There are several applications that
are inserting IPv4 address information in the payload of a packet.
Some applications use the IPv4 address information to create new
sessions or for identification purposes. This section is trying to
list the applications that need to be enhanced; however, this is by
no means a comprehensive list."

If even a few widely used applications would need to be rewritten to
operate successfully with hIPv4, then this would be such a
disincentive to adoption to rule out hIPv4 ever being adopted widely
enough to solve the routing scaling problem, especially since CES
architectures fully support all existing protocols, without the need
for altering host stacks.

It appears that hIPv4 involves major practical difficulties which
mean that in its current form it is not suitable for IETF development.

---

From: Tony Li <[email-masked]>
Date: Sat, 06 Mar 2010 15:39:30 -0800

> here is a critique which I hope will be included in the RRG Report.

Received and incorporated.

Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Sun, 7 Mar 2010 12:09:10 +0200

Hi Robin,

your statement "chosen ahead" was a surprise. And I agree here, the
hIPv4 framework shouldn't be chosen ahead - it should be chosen
together with a CES architecture (if hIPv4 is going to be chosen at
all).
Writing a rebuttal is hard, 500 words is setting up constraints - most
likely we would only end up in a yes-no-yes-no debate. So I have put
together some more text why a CES and hIPv4 solution might be an
interesting choice, attaching it  - it is also a very first early
draft. I have had plans to do this for a long time but can only work
on this during the weekends (when there is time to do some writings)
Have a look on that, feedback is highly appreciated -there could be
holes in the arguments because I have spent enough time on this to
feel comfortable with it.
I'll try to open up the use cases in more detail but I don't know when
I have time to do it - it might happen or not.

About issues with applications, e.g. those who are using IP addresses
for identification. You could view this from another angle. If you
really provide a new routing architecture or you provide a true
location-identifier decoupling you should get into trouble with some
applications, especially those who are not architecturally clean. So I
claim that hIPv4 provides a new routing architecture, because I get
into trouble with some applications - that is my evidence. You are
saying that every application is preserved in the CES architectures
-then I claim that the CES architecture is not really a new routing
architecture - it is an improvement of the current architecture. And
here is another reason why the CES-architecture should come first,
after a while or simultaneously you start to roll-out the hIPv4
framework -  but there are some "trouble" application where you can't
make a full migration to the hIPv4 framework until those applications
has been fixed first.

Note that inside an enterprise's network, there are no need to apply
changes to applications - they will still use IPv4 as the forwarding
mechanism. And the same is valid inside an ALOC realm (a service
provider's routing domain). But when sessions are established between
ALOC realms you have some challenges, I can think of IPsec, SSH/Telnet
and SIP. SSH/Telnet and SIP should be quite easy to fix - IPsec is
providing the most challenges. You could
1. Do something similar as in ILNP, that is, assemble first a legacy
IPv4 packet, calculate the checksums and store that in the locator
header (new field needed) once it has been added to the packet. This
should be doable, but what about mobility? It really doesn't provide a
location-identifier separation, ILNP has solved this, so this is not a
critique against ILNP - in hIPv4 I'm trying to keep the identifier
functionality away from the IP-header.
2. Use a PKI and TLS instead. But again what about mobility - how to
solve that? My skills about PKI systems are limited.
3. Then what about HIP, could it provide something interesting here?
HIP is providing a rendezvous service for mobile endpoints and
identifying endpoints on an identifier and not on the IP address.
This way the enterprises could start to build their VPN with a
mechanism that is decoupled from the location (IP address space). I
think this is one reason why MPLS VPN has been so very successful
compared to IPsec VPN at the service providers.
So if you could use HIP to identify the endpoints and e.g. TLS to
encrypt the payload we could get rid of IPsec  - IPsec will not fit
well in the mobile world anyway, so why try to preserve an application
that is an architectural disaster?
But it will take time before there is an replacement for IPsec, thus
start with CES and the long term goal is to have endpoints upgraded
and some applications fixed.

You have also criticized hIPv4 for lacking support of IPv6. My
intention was not to avoid IPv6, it just sort of happened. As I have
mentioned earlier I had the opportunity to have a deep technology dive
at  a MVNO, how they do number portability between cellco providers.
In the cell-phone world you can't really do much aggregation of
numbers - how can this then scale globally? Well, they do have
hierarchy in the addressing scheme. What numbers are moved between
Finnish service providers is a local matter, the rest of the world is
not interested what happens over here - it is enough that the world
have 358 prefix in their tables, then they can route the call over
here and the Finnish provider will take care of the "last mile"
routing. What if we could do the same in Internet? Have a global
unique IP address space and a more regional unique IP address space -
don't apply that on countries but instead of areas of service
providers (in Internet there is nothing such as country borders, only
AS borders).
Should I use IPv6 or IPv4 headers? Which will cause more overhead for
the packets? Which protocol has the forwarding in place? Oh, if you
introduce hierarchy in the address space you get more addresses as
well - nice side effect.
It seems that if you desire a new routing architecture you most likely
have to do something to the address space as well -  there seems to be
a very strong coupling between a routing architecture and an
addressing scheme.

My 2 cents...

-- patte

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 23 Mar 2010 13:08:44 +0200

Hi all,

my apologizes for being late, finally found some time to write down my
thoughts about how and why hIPv4 can/should be integrated with a CES
solution. You can find that in appendix E at
http://tools.ietf.org/html/draft-frejborg-hipv4-06

There has been some discussions about how endpoint mobility is
supported in the proposals -  I have added a brief summary in section
12 how hIPv4 should deal with the challenge

-- patte

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 23 Mar 2010 09:38:07 -0700

> 12 how hIPv4 should deal with the challenge

Thanks.
We'll try to fold the material into the framework of our Friday  
discussion.

Lixia