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

> -----Original Message-----
> From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] 
> Sent: Wednesday, December 26, 2007 6:45 AM
> To: Gonzalo Camarillo
> Cc: P2PSIP Mailing List
> Subject: [P2PSIP] a modular approach for integrating HIP for P2PSIP
> 
> 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?
> 

If you cannot count on HIP being present below your application, you are
probably going to provide the functionality yourself (ICE, mobility
support, security) if you want to deploy a successful P2P application.
And if so, do you then care much about using HIP if/when it later enters
the picture?  (see also: IPv6 deployment...)

I think the interesting thing for P2PSIP to decide is whether to try to
go for an architecture where ICE/mobility handling is (non-optionally)
layered below the application so that such components can be reused
generally across applications.  Specifying it as an option will just
lead to it being replicated everywhere.  

Tom

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip