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. _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
