Pekka, >-----Original Message----- >From: Pekka Nikander [mailto:[email protected]] >Sent: Friday, January 09, 2009 12:31 AM >To: Templin, Fred L >Cc: RRG >Subject: Recursive re-encapsulations > >>>> Regarding HIP + map/encaps, maybe it is obvious to everyone else >>>> already but I think what that gives you is an endpoint identity >>>> (the HIT), an inner routing locator (iRLOC), and an outer RLOC >>>> (oRLOC). Up to now, LISP (and perhaps others) have been using the >>>> term "EID" to refer to what I mean by "iRLOC", and the term "RLOC" >>>> to refer to what I mean by "oRLOC". >>> >>> That is my basic model as well. Further, as Brian observed, that >>> can be applied recursively. >> >> Yes. One small but important distinction though is that recursion is >> not meaning to say that there would be recursive encapsulations >> (i.e., IP0-in-IP1-in-IP2-in ... in-IPN); else we would eat ourselves >> out of MTU in a hurry. > >I agree. > >> Rather, we can talk about recursive RE-encapsulations. So, the >> initial encapsulation would be: HIT-in-iRLOC-in-oRLOC0. The packet >> would be forwarded within the scope within which oRLOC0 is routable, >> then decapsulated and re-encapsulated as HIT-in-iRLOC-in-oRLOC1. > >Well, I would expect 1-to-1 mapping between HITs and iRLOCs, allowing >one to use just one encapsulation or even almost-null encapsulation. >That is, e.g. iRLOC-in-oRLOCi, HIT-in-oRLOCi, or TAG-in-oRLOCi where >TAG is whatever minimal encapsulation/tag is needed for demuxing at >oRLOCi.
I may not have made myself clear. I am talking about HIP in conjunction with the RANGER/VET/SEAL model, and specifically about the over-the-wire encapsulation format. iRLOC refers to the IP addresses HIP sees, while oRLOC refers to the outer encapsulation applied by RANGER/VET/SEAL. Both iRLOCs and oRLOCs name interfaces (not end systems) hence they are routable within a certain limited scope. My understanding is that HITs are true end system identifiers (EIDs) and not routable within any scope. My assumption is that HIP can deal with multihomed hosts (i.e., there may be one HIT to many iRLOCs), but let's say there is just one interface for now. So, when a HIP-aware transport inserts a HIT (and then does BEET-mode encapsulation, I guess) the packet goes out as: +--------------+ | data | +--------------+ | transport | +--------------+ | HIT | +--------------+ | IPsec/ESP | +--------------+ | Inner IP hdr | | src=iSRC | | dst=iDST | +--------------+ Then, somewhere in the path (it may or may not be on the same platform that sourced the packet), an ITR performs an iRLOC to oRLOC mapping and appends an outer IP header: +--------------+ | data | +--------------+ | transport | +--------------+ | HIT | +--------------+ | IPsec/ESP | +--------------+ | Inner IP hdr | | src=iSRC | | dst=iDST | +--------------+ | Outer IP hdr | | src=oSRC(0) | | dst=oDST(0) | +--------------+ The packet is then routed according to the outer IP protocol within the scope within which oSRC(0) and oDST(0) are valid, then hits an ETR/ITR that decapsulates and re-encapsulates as: +--------------+ | data | +--------------+ | transport | +--------------+ | HIT | +--------------+ | IPsec/ESP | +--------------+ | Inner IP hdr | | src=iSRC | | dst=iDST | +--------------+ | Outer IP hdr | | src=oSRC(1) | | dst=oDST(1) | +--------------+ and the chain can continue recursively with an indefinite number of ITR(i)->ETR(i), ITR(i+1)->ETR(i+1), etc. transitions, with the decapsulation and re-encapsulation occurring at each transition. The iRLOCs in the inner IP header never change, but the inner IP TTL/Hop limit is decremented upon each ETR->ITR transition. This is what I mean by HIP being used in conjunction with map/encaps. But, HIP simply sees map/encaps as an ordinary interface over which packets can be sent. Does this clarify? Fred [email protected] > >> It is exactly analogous to the way the L2 destination is changed on >> each IP forwarding hop without the L3 destination address changing. >> The only difference is that the outer IP protocol is seen as L2 by >> the inner IP protocol. > >I think that has been discussed more extensively in the following >papers and drafts. But I didn't check, I may be wrong. > >Jukka Ylitalo, Patrik Salmela, and Hannes Tschofenig, "SPINAT: >Integrating IPsec into Overlay Routing", in Proc. of the First >International Conference on Security and Privacy for Emerging Areas in >Communication Networks (SecureComm'05), pp. 315-326, Athens, Greece, >September 5-9, 2005, ISBN 0-7695-2369-2 > >http://www.ietf.org/internet-drafts/draft-melen-spinat-01.txt > >A. Eriksson and B. Ohlman, "Dynamic Internetworking Based on Late >Locator Construction," IEEE Global Internet Symposium, 2007. > >--Pekka _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
