Eric wrote:
By combining a true locator-identifier split (i.e., HIP) with a
map-and-encaps (e.g., LISP) one gets the combined benefits of both
approaches. Those benefits are
Dino replied:
But you add another layer of addressing that is probably more than
the user wants. It could get this bad:
HIT -> EID -> private-RLOC -> public-RLOC when behind a NAT
or
HIT -> private-EID -> public-EID -> RLOC when behind a NAT
I don't think those mappings are right.
If there is a NAT between the xTR/HIP-proxy and the "new" internet,
the mapping would be:
EID -> (HIT) -> private-RLOC -> public-RLOC
where the HIT would be invisible everywhere but inside the HIP proxies
and within the signalling protocol between the HIP proxies.
If there is a NAT between the legacy host and the xTR/HIP-proxy, the
mapping would be:
private-EID -> public-EID -> (HIT) -> RLOC
where again the HIT would be invisible, as explained above.
2-levels of mapping is plenty, adding 2 more probably is a non-
starter. Remember folks, we have to incrementally deploy this with
minimal cost, see Yakov's post early today, he makes good points.
I don't see how replacing the xTR internal functionality with the HIP-
proxy functionality would add much cost. It would change the protocol
between the xTRs, yes. HIP as a protocol is probably more complex
than the present xTR-xTR protocol, but it is well tested, been in
operational use at Boeing for a few years, as has three open source
implementations.
There is an extra mapping, i.e. replacing the EID->RLOC mapping with a
EID->(HIT)->RLOC mapping. But that mapping is internal to the proxies
and the signalling protocol, and not visible outside. In the simplest
case the HITs would be ephemeral and opportunistic, requiring no
configuration or storage anywhere. (The benefit from them is in terms
of security and mobility, especially in more complex scenarios than
the simplest case.)
--Pekka
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
