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.
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.
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.
--Pekka
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
