Re: [rrg] hIPv4 critique (draft = final)

[Robin Whittle <[e-mail]>]

Short version:   The 05 version of hIPv4 involves a new kind of IP
                 header, rather than an IPv4 header option.  This
                 would not be practical either, since no router
                 or host will recognise it.


Hi patte,

I don't want to discourage further development of your proposal, but I
think your version 05 is not at all practical since it involves a new
kind of packet format.  This would require all DFZ and all other routers
to be upgraded, and upgrades to all the stacks of all hosts which use
hIPv4.  I am sure these requirements would rule your proposal out of
consideration as a scalable routing proposal, since we can only plan to
develop something which will be voluntarily adopted on a very wide basis.

You wrote:

> your critique is valid, I did found some more papers around the usage
> of options.

Can you post the references to to the RRG list?

> Architecturally it would have been a clean approach to use options,
> but in the real world that is not much of an option...
> 
> So thanks for pointing this out for me!

OK - I wish all IPv4 routers could handle IPv4 header options.


> It took me back to the drawing board and I created a new header so
> that the IP header will be 20 bytes and stay in the fastpath though
> there are some extensions added by the endpoints
>
> http://tools.ietf.org/html/draft-frejborg-hipv4-05
>
> The extensions are no longer in the option field, instead a real shim
> header is created that the hIPv4 endpoints/nodes will identify by a
> new protocol number in the IP header - the upper layer protocol (e.g.
> transport) number can be found in the shim header. This shouldn't
> upset the intermediate legacy routers, or does it?  

They would be "upset" - routers wouldn't know what to do with a packet
with such a header.  They would drop the packet.  There's no reason they
would interpret it like some other header they do know about: IPv4 - and
if they did, it wouldn't work, since your new header is longer than the
IPv4 header.


> About the 32-bit address space, I think it is good enough. In the
> pre-RRG world it isn't but here at RRG two issues has been discussed
> quite a lot that changed my world quite radically, that is, the
> core-edge separation/elimination and the decoupling of
> identifier-locators.

I think Locator/Identifier Separation is a bad idea:

   Today's "IP addr. = ID = Loc" naming model should be retained
   http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html


I think the routing scaling problem can be solved for IPv4 (and for
IPv6), at least with my CES architecture:

  http://www.firstpr.com.au/ip/ivip/

I believe that in doing so, we will be able to use IPv4 space more
efficiently than at present, since millions of end-user networks will be
able to scalably get just the amount of space they need, rather than the
minimum 256 addresses they can get today with conventional BGP
techniques.  However, even though more than half of the BGP prefixes are
/24, they total a fraction of a percent of the global unicast address
space.  This means that millions of end-user networks will be
accommodated, scalably, without too much address usage.

Still, the 3.7 billion limit on IPv4 global unicast space remains a
serious long-term problem.  The main thing it can't handle is billions
of cellphones on IPv4.  I am not sure it can handle all the homes and
offices which ultimately want a DSL or fibre or whatever service like
people get today with DSL etc.: a single global unicast IPv4 address for
their NAT box, and with which they can port-forward whichever UDP and
TCP ports they like, since they are not sharing this IPv4 address with
anyone else.

I think 64 bits would be fine for a new addressing system.  I think
IPv6's 128 bits is overkill and makes packets too long, and host
software too complex, since CPUs only deal with 32 and 64 bits.

Anyway, that is academic for now - the best routing scalability
solutions do not require anything as drastic as new addressing systems,
and the consequent need to alter all host-stacks and substantially
rewrite all applications.

  - Robin