Hi, I have just talked with Miika and he has volunteered to take the pen and add the necessary clarifications to the draft so that it is more readable. Thanks, Miika!
First he will look into adding clarifications to the existing draft while still referencing the old RFC. If the group is not happy with the readability after the editorial pass (or our AD does not finally let us downref the old RFC), we can consider bringing material from the old RFC directly into the new one. I would also like the group to comment on the following two proposals: 1) the draft will allow implementers to use HIP native relays only. In addition, the use of STUN and TURN relays will be optional. 2) in addition to covering the base exchange, the draft will also cover the mobility readdressing exchange. Thanks, Gonzalo On 29/02/2016 4:41 PM, Miika Komu wrote: > Hi, > > On 02/27/2016 10:49 AM, Gonzalo Camarillo wrote: >> Hi Jeff, >> >> thanks for your feedback. >> >>> Regarding pros/cons: >>> How widely-deployed is STUN/TURN? Are public servers widespread? >> >> there are several of them. They are mostly used for VoIP. You can google >> for "public stun turn servers" or something similar. There are a few >> lists out there. > > I guess the situation is like this: > > HIP control plane relay: > * new critical infrastructure that needs to be deployed anyway (TURN > server cannot be used for this) > > Gathering of address candidates: > * from a STUN server (many available) > * ...or from control plane relay registration (which is mandatory anyway) > > Data plane relay: > * using TURN server (it seems some are available) > * ...or using the ESP relay as specified in native NAT spec (none > deployed, but I guess could co-locate with the HIP control plane relay) > > So, the critical part are the HIP control plane relays which provide > also similar functionality as STUN servers (i.e. provide server > reflexive candidates). So I guess the question boils down to the > availability of TURN servers. > > P.S. Nothing really prevents to use STUN servers to discover address > candidates in the native NAT traversal version. The discovery process is > independent of the NAT penetration process. > > > > _______________________________________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
