On Mon, 31 Dec 2007, Gonzalo Camarillo wrote:
Hi Ali and Gonzalo,
sorry for catching up late.
Hi Ali,
HIP includes an ICE-based NAT traversal mechanism. If two nodes use HIP,
they will perform ICE at the HIP level, not at the application level.
Using application-level ICE to negotiate the use of HIP between nodes,
per your email below, is cumbersome. The use of HIP can be negotiated in
simpler ways.
Basically I agree with Gonzalo here, but to be more specific...
In a "normal" (no overlay, no extra mods to ICE or HIP) HIP scenario,
sending some data to a HIT would trigger an I1. Either with or without UDP
encapsulation, depending on local policies. When I1 is sent without UDP,
the hipd could speed up the connection set-up in the case there are no
NATs between the two machines. However, the ICE module would not know
when to stop the connectivity tests, because it wasn't HIP-aware in this
case. Also, this "optimization" would be unnecessary in the case there are
NATs between the two hosts because the HIP messages would be just dropped.
In another non-overlay scenario, where ICE is HIP-aware, we could define
that ICE and HIP module can interact with each other. Sending STUN
messages to a HIT would trigger a I1 packet without UDP encapsulation and
upon success the HIP module could abort the ICE connectivity tests
gracefully. One benefit of this would be that we would skip the UDP
encapsulation altogether, but the benefit is neglectible.
As indicated by the other discussion thread, applying HIP-aware ICE in
HIP-enabled overlays may have some caveats related to handling of multiple
overlays. Anyway, there should be a distinction between getting a direct
connection to the peer (using ICE) vs. routing through the overlay. I
think this could be implemented e.g. using a socket option.
With regards to the use of HIP in overlays, the simplest way would be to
deploy overlays where all nodes use HIP and overlays where none of the
nodes use HIP. However, some people have expressed interest in having
mixed overlays where some nodes use HIP while others don't. If people
are interested in doing this, we will have to look into ways to
negotiate its use within the overlay.
With regards to the use of HIP in overlays, the simplest way would be to
deploy overlays where all nodes use HIP and overlays where none of the
nodes use HIP. However, some people have expressed interest in having
mixed overlays where some nodes use HIP while others don't. If people
are interested in doing this, we will have to look into ways to
negotiate its use within the overlay.
Regarding to Ali's original suggestion on detecting localhost and peer
support, I think localhost support would be easy. Connecting to a HIT is
one way detect it, but it may include a timeout. Other ways are to go
through the addresses of host using e.g. getaddrinfo() and check if there
are any ORCHIDs there. Perhaps the quickest way is to create a socket with
PF_HIP family and check for errors in the return value.
--
Miika Komu http://www.iki.fi/miika/
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
