Hi Pekka, >-----Original Message----- >From: Pekka Nikander [mailto:[email protected]] >Sent: Saturday, January 10, 2009 5:06 AM >To: Templin, Fred L >Cc: RRG >Subject: Re: 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. >>> >>> 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. > >I suggest that we take this off-line, as there are many details. If >someone else is interested, feel free to drop a note. It may be worth >to wrap the details into a draft, perhaps. > >Anyway, from my point of view, what you described in the message > >http://www.ietf.org/mail-archive/web/rrg/current/msg04312.html > >is the case of using vanilla HIP on a HIP-enabled host, landing on a >network behind a lisp xTR or a similar device. In that case you >indeed get the packet structures you described.
I'm actually meaning to refer to a HIP-enabled proxy router landing on the same platform as an xTR (although the model would be the same if the HIP-enabled proxy landed on a link downstream from the xTR). >However, if we aim for the kind of hybrid LISP-HIP-proxy design that >I've been suggesting, I believe that the packet formats could be much >simpler. I'm not exactly sure how; xTR means IP-in-IP encapsulation. Were you meaning for it to mean something else? >AFAICS, the crux will always be on how much demultiplexing / security >verification state you need at the receiving end, at the unwrapping >xTR. If your trust model allows you to decapsulate without >verification, you can live without such state and include the inner >locators or identifiers into the packet. However, if the trust model >requires one to verify the inner locators or identifiers, then there >must be the state at the receiving end, meaning that you get smaller >overhead if you don't include the full inner header in the packet but >just index to the state + any bits not directly stored in the state. With RANGER/VET/SEAL, I am looking for a way for the ITR to establish sufficient securing state in the ETR through a single message sent forward before any data messages are sent (i.e., a "1-way handshake"). Can HIP do that? Thanks - Fred [email protected] >--Pekka _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
