update to STUN

Jonathan Rosenberg <[email protected]> Mon, 19 Jul 2004 11:35:59 -0400
Newsgroups gmane.ietf.midcom
Organization dynamicsoft
Message-ID <[email protected]>
Folks,

Per our discussion at the last IETF, I have submitted an Internet Draft 
that revises RFC 3489. Here is the document:

http://www.ietf.org/internet-drafts/draft-rosenberg-rfc3489bis-00.txt

The changes I have made are:

o  Removed the usage of STUN for NAT type detection and binding
       lifetime discovery.  These techniques have proven overly brittle
       due to wider variations in the types of NAT devices than described
       in this document.  The protocol semantics used for NAT type
       detection remain, however, to provide backwards compatibility, and
       to allow for the NAT type detection to occur in purely diagnostic
       applications.
    o  Removed the STUN example that centered around the separation of
       the control and media planes.  Instead, provided more information
       on using STUN with protocols.
    o  Added the XOR-MAPPED-ADDRESS attribute, which clients prefer to
       the MAPPED-ADDRESS when both are present in a Binding Response.
       XOR-MAPPED-ADDRESS is obfuscated so that NATs which try to "help"
       by rewriting binary IP addresses they find in protocols will not
       interfere with the operation of STUN.
    o  Added the XOR-ONLY attribute, which clients can use to request
       that the server send a response with only the XOR-MAPPED-ADDRESS.
       This is necessary in case a Binding Response fails integrity
       checks due to a NAT that rewrites the MAPPED-ADDRESS.
    o  Explicitly point out that the most significant two bits of STUN
       are 0b00, allowing easy differentiation with RTP packets when used
       with ICE.
    o  Added support for IPv6.  Made it clear that an IPv4 client could
       get a v6 mapped address, and vice-a-versa.


There is one open issue in the document, which is whether or not we 
should do an IANA port registration for the second stun port. Probably 
we should.

I do not plan on asking for any agenda time for this at San Diego. 
Indeed, we decided that this would not be a midcom work item. Please let 
me know if anyone has comments, questions, or other things they'd like 
to see fixed.

Thanks,
Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com