Hi Patte,

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


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:


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


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.

rrg mailing list

Reply via email to