> -----Original Message----- > From: Ali Fessi [mailto:[EMAIL PROTECTED] > 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 [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
