Hi David, David Barrett wrote:
For what it's worth, I think P2PSIP over HIP is a fantastic idea, with the caveat that HIP should be deployable within standalone applications by statically linking some BSD-licensed library (ie, without requiring users to make TCP stack changes or install virtual network interfaces).
This should be doable. The application would need to be "HIP aware" (i.e., not use just the standard socket API) for this to work, but I suppose that's not a big problem. Or maybe we could link our app with a non-standard libc. To not require root rights for the program we would need to use UDP encapsulation, but then again, we need to do it for NAT traversal anyway. Also, it's worth noting that even the current implementations of HIP require no changes in the TCP stack.
It is true that installing some implementations of HIP is not at the moment as easy as it should be, but there are ongoing efforts to improve the situation. When/if HIP is (hopefully one day) provided natively by the major OSs, this won't be a problem anymore. Meanwhile, if we can make installing and enabling HIP (if not already available) as easy as clicking "yes" a few times when installing a program that needs it, I suppose we can live with it.
A VPN/virtual-interface over HIP would be really cool -- don't get me wrong. It'd be like an open-source, standardized version of Hamachi. But as an application developer, I wouldn't ever ask my users to deploy some scary virtual tunnel just to use my thing.
Well, the users don't have to know about the scary tunnels :-) But seriously, I think the users won't really mind what is installed as long as the thing works and does not break anything. And if we run HIP over UDP and don't do any kernel tricks (which are usually done just to get better performance), using HIP doesn't really differ that much from using any other network protocol.
Cheers, Ari _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
