[VOIPSEC] Put STUN in NAT Boxes?
dwing at fuggles.com
Tue Jun 26 23:37:40 BST 2007
Simon Horne wrote:
> Dan (Wing)
> I noticed that you submitted a proposal to add STUN to NAT devices
Yes. I had asked for a BoF at the upcoming IETF meeting, but it was
denied. Discussion of that document is on the SAFE mailing list,
https://www1.ietf.org/mailman/listinfo/safe. I will ask for a BoF
at this fall's IETF (Vancouver).
Related, you might read
although it is incomplete.
> and looking at sect 14.4 of the STUN working document
> Your long term solution to NAT traversal is to control the NAT boxes? Are
> you giving up on the initial idea of ICE which was to work with existing
> NATs and instead taking the UPnP and MIDCOM type approach and putting some
> form of control into the NAT boxes and attempt to control/instruct them?
I don't know if you bumped into my discussion of STUN Control, but in
case you haven't, it's at:
In that post, I describe some of the motivations for STUN Control.
In summary -- no, this isn't "giving up". Rather, STUN Control
allows optimizing STUN when your own NAT(s) support STUN Control.
The most useful optimizations to STUN are (a) reducing keepalives
(which isn't a characteristic of STUN, but rather of any sort of
UDP hole-punching technique; STUN is one such technique), and (b)
getting per-call bindings without involving the STUN server
on the Internet.
More information about the Voipsec