inline rrg-boun...@irtf.org wrote on 01/19/2010 05:36:10 AM:
> From: Lixia Zhang <li...@cs.ucla.edu> > To: rrg@irtf.org > Date: 01/19/2010 05:36 AM > Subject: [rrg] critique of RANGI: a revision > Sent by: rrg-boun...@irtf.org > > 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? The ID->locator lookup is needed in any event. Adding the locator to the FQDN->ID lookup is straightforward. Your wording makes it sound like RANGI is opposed to returning both ID and locator in the FQDN, which I doubt is the case. My original text said: 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. I still kinda prefer the original wording, but if you want to include the comparison with ILNP, then how about this: 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 (as does ILNP). I also think 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. > > 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). 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? 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 > 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 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
