Ok, here is the depersonalized RANGI critique. PF
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. More thought is needed as to what constitutes these levels with respect to these various roles. The RANGI draft suggests FQDN->ID lookup through DNS, and separately an ID->locator lookup which may be DNS or may be something else (a hierarchy of DHTs). It would be more efficient if the FQDN lookup produces both ID and locators (as does ILNP). Probably DNS alone is sufficient for the ID->locator lookup since individual DNS servers can hold very large numbers of mappings. 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. Architecturally there are many advantages to putting 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 may not be adequate (HIP's lack of uptake being an example). RANGI does not have an explicit solution for the mobility race condition (there is no mention of a home-agent like device). However, host-to-host notification combined with fallback on the ID->locators lookup (assuming adequate dynamic update of the lookup system) may be 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). These transition technologies are in any event being pursued outside of RRG and do not need to be specified in RANGI drafts per se. RANGI only needs to address how it interoperates with IPv4 and legacy IPv6, which through proxies it appears to do adequately well. From: Lixia Zhang <li...@cs.ucla.edu> To: Paul Francis <fran...@mpi-sws.org> Cc: rrg@irtf.org Date: 01/19/2010 09:24 AM Subject: Re: [rrg] critique of RANGI: a revision On Dec 30, 2009, at 12:02 AM, Paul Francis wrote: >> .... >> 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. > > Adding the DFZ scaling sentence at the beginning of this paragraph > produces a non-sequitur. > > More importantly, as Huawei mentioned in his last email, the > rewriting is > for incoming traffic engineering at multihomed sites, not for > scaling DFZ > routing. I suggest we just remove the DFZ sentence (I'm not sure what > point you are trying to make with it). I am trying to identify commonalities of mechanisms among different proposals. > More generally, I wrote the initial critique in the first person, and > included a few statements which are clearly meant to be my opinion > rather > than fact per se. I was under the impression that there could be > multiple > critiques per proposal, each written by an individual or group. Is > this > the case, or is there supposed to be one critique per proposal? the latter, that's the only reason I changed your text > If the > former, I'd prefer just to keep the critique as originally written. > If the > latter, then I'd like to modify the proposal to remove the first > person > perspective and opinions. > > PF please feel free to revise, and fix any errors you thought I introduced. Lixia _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
