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.
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.
Cheers,
Gonzalo
Ali Fessi wrote:
Dear Gonzalo, all,
according to draft-ietf-mmusic-ice, addresses collected for ICE can be
also "obtained through a tunnel mechanism, such as a Virtual Private
Network (VPN) or Mobile IP (MIP)".
If i understand correctly (please correct me if i am wrong) the ORCHID
(alternatively the LSI if the application uses IPv4) is bound locally to
a virtual interface. So the application can use it the same way it uses
an IP address obtained by a VPN (or any other IP address, e.g. obtained
by STUN)
So is there a reason why HIP ORCHIDs cannot be used in the ICE
candidates list?
Also the ICE host candidates' sorting process (as described in Section
2.3 "Sorting Candidates" in draft-ietf-mmusic-ice) could recognize the
HIP ORCHID (due to the unique prefix) and give it higher priority in the
host candidate list if the application should benefit from the HIP
advantages.
I think that could provide a simple - though modular and flexible -
approach for integrating HIP for P2PSIP (at least for the NAT traversal
part)
In other words:
- the application can easily check whether the host where it is running
supports HIP.
- a peer can inform another peer that it supports HIP (using the ICE
candidates list and the priorities given to the addresses). If both
peers support HIP and they are in the same HIP overlay, then they can
(and maybe should) use it.
- if one of the peer hosts does not support HIP, then the peers will
need to go forward in the ICE host candidate list and use other
addresses for connectivity, e.g. those obtained by STUN.
I mentioned, this could provide a modular approach for the NAT traversal
problem. But maybe it could be extended to cope with the other features
that HIP provides, e.g. mobility and multi-homing.
Any comments?
Thanks in advance.
Cheers,
Ali
Gonzalo Camarillo wrote:
Hi,
what is if peers add the HIP ORCHID at the first position of the list
of gathered addresses for ICE?
ORCHIDs are identifiers. You need locators (i.e., IP addresses) for
the ICE process.
Cheers,
Gonzalo
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
