based on Xiaohu's comments here is a revision to fix the minor
technical errors I made earlier (I want to get it right because Tony
will incorporate into the collection)
Lixia
PS: going through the text I realized the phrase "using DNS reverse
lookup" is a bit misleading -- it is NOT about lookup from IP address
to DNS names as the phrase literally means.
-----------------
RANGI critique
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. This
hierarchical structure addresses two weaknesses of the flat HIP ID:
the difficulty of doing the ID->locator lookup, and the administrative
scalability of doing firewall filtering on flat IDs. The usage of this
hierarchy is overloaded: it serves to make the ID unique, to drive the
lookup process, and possibly other things like firewall filtering.
RANGI ID uses 8-byte for the administrative hierarchy. More thought is
needed as to what constitutes these levels, the use of "DNS reverse
lookup" vs DHT for the ID-Locator resolution and their relations to
administrative boundaries.
The RANGI draft suggests FQDN->ID lookup through DNS, and separately
an ID->locator lookup which may be DNS or may be something else. This
represents additional cost compared to ILNP design where FQDN lookup
produces both ID and locators. Can one quantify the gain by one
additional lookup to justify the cost?
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.
In terms of scaling the DFZ routing, RANGI's solution closely
resembles that of ILNP based on locator rewrite at border routers.
Architecturally it seems 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.
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 uses proxies to deal with both "legacy IPv6" 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
softwire), 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
