Hi Gang,
I've attached a critique of RANGI.
PF
RANGI critique, by Paul Francis
RANGI is an ID/locator split protocol that, like HIP, places a
cryptographically signed ID between the network layer (IPv6) and transport.
Unlike the HIP ID, the RANGI ID has a hierarchical structure that allows it to
support ID->locator lookups. I think this adequately addresses two major
weaknesses of the flat HIP ID: first the difficulty of doing the ID->locator
lookup, and second the administrative scalability of doing firewall filtering
on flat IDs. This hierarchy is overloaded in that it serves to at least make
the ID unique and to drive the lookup process, and possibly other things like
firewall filtering. More thought is needed as to what constitutes these
levels, and how flexible this should be.
The RANGI draft suggests FQDN->ID lookup through DNS, and separately an
ID->locator lookup which may be DNS or may be something else. I think it would
be better if the FQDN lookup produces both ID and locators, and that it is
sufficient that the ID->locator lookup be DNS.
RANGI provides strong sender identification, but at the cost of computing
crypto. Many hosts (public web servers) may prefer to forgo the crypto at the
expense of losing some functionality (receiver mobility or dynamic multihome
load balance). While RANGI doesn't require that the receiver validate the
sender, it may be good to have a mechanism whereby the receiver can signal to
the sender that it is not validating, so that the sender can avoid locator
changes.
I think that architecturally it is best to put the mapping function at the end
host (versus at the edge). This simplifies the neighbor aliveness and delayed
first packet problems, and avoids stateful middleboxes. Unfortunately the
early-adopter incentive for host upgrade strikes me as weak at best (though to
be fair, I don't see a strong incentive for ANY of the RRG proposals).
RANGI suffers from the mobility race condition (there is no mention of a
home-agent like device), though my personal opinion is that host-to-host
notification combined with fallback on the ID->locators lookup (assuming
adequate dynamic update of the lookup system) is good enough for the vast
majority of mobility situations.
RANGI specifies the use of proxies to deal with both "legacy IPv6" (that gave
me a chuckle) and IPv4 sites. RANGI proxies have no mechanisms to deal with
the edge-to-edge aliveness problem. The edge-to-edge proxy approach dirties-up
an otherwise clean end-to-end model.
RANGI exploits existing IPv6 transition technologies (ISATAP and softwires),
but it seems to me that these transition issues are orthogonal and don't need
to be specified in RANGI drafts per se. RANGI only need address dealing with
legacy IPv6, which it appears to do adequately well.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
