Hi Miika, what is the status of this?
Thanks, Gonzalo On 07/03/2016 2:35 PM, Gonzalo Camarillo wrote: > 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 > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
