Re: [rrg] hIPv4 revised critique

[Patrick Frejborg <[e-mail]>]

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

On Fri, Mar 5, 2010 at 3:35 AM, Robin Whittle <[e-mail]> wrote:
> 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.
>
>
>