[P2PSIP] Re: a modular approach for integrating HIP for P2PSIP

[Gonzalo Camarillo <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip