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

[Patrick Frejborg <[e-mail]>]

Hi Robin

seems to be some misunderstandings in our dialogue, will try to
explain in more details

On Sat, Feb 13, 2010 at 4:03 PM, Robin Whittle <[e-mail]> wrote:
> 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.
>

It is a new format but the legacy routers will not see the new format
since to them this is a legacy IPv4 header - the only change is that
there is new protocol number in the IPv4 header. And routers shouldn't
care about that, the packets should stay in the fast path as long as
the header length is 20 bytes.
The new protocol number is used by the endpoints and the LSR to
distinguish between IPv4 and hIPv4 packets, when the new protocol
number is used the endpoint and LSR knows that after the IPv4 header
there is a shim header and not a transport protocol header.


> 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.

Nope, the routers shouldn't see it all - the locator header is not
part of the IPv4 header. It is a shim header sitting between the IP
and transport header. Thus the hIPv4 packet stays in the fast lane and
gets routed through the legacy network, the LSR and destination
endpoint will know by the new protocol number that there is an
additional header before the transport protocol

>
>
>> 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
>
>

Here I disagree, think the HTTP cookie mechanism is great and a
generic model should be created to enhance endpoint mobility. If the
identifier is in the address space you have to use an overlay solution
such as MIP. It matters where you place the identifier in the TCP/IP
model


> 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.
>
Have you ever wondered why PSTN doesn't suffer from this kind of
problem - how can they have billions and billions of landline and
cellphones hooked into the PSTN?
Over here my cellphone number is mine, I can choose any cellco and my
numbers stays the same when I change cellco
http://www.numpac.fi/index.php?site=127

> 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.

Exactly.

If you create a two level hierarchy you can preserve the current
addressing scheme and still create a new routing architecture. If you
reserve a 256k/512k/1M address space for ALOC then each ISP can have
their own IPv4 address space for their customers. With one IPv4
address space 1,7 billion users have been able to enjoy the Internet
experience, with e.g. 512k times more IPv4 address spaces we should be
able provide Internet experience for everyone.
It will have implications though - you can't share routing information
of every prefix with every one - then you would run into overlapping
prefixes. Thus one ISP can have only its directly attached customers
in their RIB, the ISP will not accept any routing information from
other ISPs except their ALOC information - the PI and PA prefixes from
other ISP stays within each ISP's RIB. Also, if I'm running an ISP -
why should I be interested if a certain prefix of another ISP is
installed in my RIB or not (using power, space, cooling and FIB
resources if installed)? For me it is enough that I can find the other
ISP (by the ALOC), send the packets over to that ISP and they will
deal with the local forwarding  - it is their problem to route the
packets to the final destination, it is not my problem and actually I
don't care how they do it. The outcome is that the RIB of  core-DFZ is
reduced quite a lot, also the amount of paths are suppressed in the
DFZ because the edge prefixes (PA and PI addresses) are aggregated
behind one ALOC prefix.
This will have implications for multi-homing solutions, but here MPTCP
comes to rescue

-- patte
>
>  - Robin
>
>