draft-ietf-behave-rfc3489bis-12.txt   draft-ietf-behave-rfc3489bis-13.txt 
BEHAVE Working Group J. Rosenberg BEHAVE Working Group J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3489 (if approved) R. Mahy Obsoletes: 3489 (if approved) R. Mahy
Intended status: Standards Track Plantronics Intended status: Standards Track Plantronics
Expires: May 16, 2008 P. Matthews Expires: May 20, 2008 P. Matthews
Avaya Avaya
D. Wing D. Wing
Cisco Cisco
November 13, 2007 November 17, 2007
Session Traversal Utilities for (NAT) (STUN) Session Traversal Utilities for (NAT) (STUN)
draft-ietf-behave-rfc3489bis-12 draft-ietf-behave-rfc3489bis-13
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2008. This Internet-Draft will expire on May 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with NAT traversal. It can as a tool for other protocols in dealing with NAT traversal. It can
be used by an endpoint to determine the IP address and port allocated be used by an endpoint to determine the IP address and port allocated
skipping to change at page 7, line 36 skipping to change at page 7, line 36
arrives at the STUN server, it may have passed through one or more arrives at the STUN server, it may have passed through one or more
NATs between the STUN client and the STUN server (in Figure 1, there NATs between the STUN client and the STUN server (in Figure 1, there
were two such NATs). As the Binding Request message passes through a were two such NATs). As the Binding Request message passes through a
NAT, the NAT will modify the source transport address (that is, the NAT, the NAT will modify the source transport address (that is, the
source IP address and the source port) of the packet. As a result, source IP address and the source port) of the packet. As a result,
the source transport address of the request received by the server the source transport address of the request received by the server
will be the public IP address and port created by the NAT closest to will be the public IP address and port created by the NAT closest to
the server. This is called a reflexive transport address. The STUN the server. This is called a reflexive transport address. The STUN
server copies that source transport address into an XOR-MAPPED- server copies that source transport address into an XOR-MAPPED-
ADDRESS attribute in the STUN Binding Response and sends the Binding ADDRESS attribute in the STUN Binding Response and sends the Binding
Response back to the the STUN client. As this packet passes back Response back to the STUN client. As this packet passes back through
through a NAT, the NAT will modify the destination transport address a NAT, the NAT will modify the destination transport address in the
in the IP header, but the transport address in the XOR-MAPPED-ADDRESS IP header, but the transport address in the XOR-MAPPED-ADDRESS
attribute within the body of the STUN response will remain untouched. attribute within the body of the STUN response will remain untouched.
In this way, the client can learn its reflexive transport address In this way, the client can learn its reflexive transport address
allocated by the outermost NAT with respect to the STUN server. allocated by the outermost NAT with respect to the STUN server.
In some usages, STUN must be multiplexed with other protocols (e.g., In some usages, STUN must be multiplexed with other protocols (e.g.,
[I-D.ietf-mmusic-ice], [I-D.ietf-sip-outbound]). In these usages, [I-D.ietf-mmusic-ice], [I-D.ietf-sip-outbound]). In these usages,
there must be a way to inspect a packet and determine if it is a STUN there must be a way to inspect a packet and determine if it is a STUN
packet or not. STUN provides three fields in the STUN header with packet or not. STUN provides three fields in the STUN header with
fixed values that can be used for this purpose. If this is not fixed values that can be used for this purpose. If this is not
sufficient, then STUN packets can also contain a FINGERPRINT value sufficient, then STUN packets can also contain a FINGERPRINT value
skipping to change at page 10, line 44 skipping to change at page 10, line 44
The most significant two bits of every STUN message MUST be zeroes. The most significant two bits of every STUN message MUST be zeroes.
This can be used to differentiate STUN packets from other protocols This can be used to differentiate STUN packets from other protocols
when STUN is multiplexed with other protocols on the same port. when STUN is multiplexed with other protocols on the same port.
The message type defines the message class (request, success The message type defines the message class (request, success
response, failure response, or indication) and the message method response, failure response, or indication) and the message method
(the primary function) of the STUN message. Although there are four (the primary function) of the STUN message. Although there are four
message classes, there are only two types of transactions in STUN: message classes, there are only two types of transactions in STUN:
request/response transactions (which consist of a request message and request/response transactions (which consist of a request message and
a response message), and indication transactions (which consists a a response message), and indication transactions (which consists of a
single indication message). Response classes are split into error single indication message). Response classes are split into error
and success responses to aid in quickly processing the STUN message. and success responses to aid in quickly processing the STUN message.
The message type field is decomposed further into the following The message type field is decomposed further into the following
structure: structure:
0 1 0 1
2 3 4 5 6 7 8 9 0 1 2 3 4 5 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+ +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 38 skipping to change at page 12, line 38
This section defines the base procedures of the STUN protocol. It This section defines the base procedures of the STUN protocol. It
describes how messages are formed, how they are sent, and how they describes how messages are formed, how they are sent, and how they
are processed when they are received. It also defines the detailed are processed when they are received. It also defines the detailed
processing of the Binding method. Other sections in this document processing of the Binding method. Other sections in this document
describe optional procedures that a usage may elect to use in certain describe optional procedures that a usage may elect to use in certain
situations. Other documents may define other extensions to STUN, by situations. Other documents may define other extensions to STUN, by
adding new methods, new attributes, or new error response codes. adding new methods, new attributes, or new error response codes.
7.1. Forming a Request or an Indication 7.1. Forming a Request or an Indication
When formulating a request or indication message, the agehtn MUST When formulating a request or indication message, the agent MUST
follow the rules in Section 6 when creating the header. In addition, follow the rules in Section 6 when creating the header. In addition,
the message class MUST be either "Request" or "Indication" (as the message class MUST be either "Request" or "Indication" (as
appropriate), and the method must be either Binding or some method appropriate), and the method must be either Binding or some method
defined in another document. defined in another document.
The agent then adds any attributes specified by the method or the The agent then adds any attributes specified by the method or the
usage. For example, some usages may specify that the agent use an usage. For example, some usages may specify that the agent use an
authentication method (Section 10) or the FINGERPRINT attribute authentication method (Section 10) or the FINGERPRINT attribute
(Section 8). (Section 8).
skipping to change at page 21, line 31 skipping to change at page 21, line 31
any) to follow based on knowledge of which usage applies. For any) to follow based on knowledge of which usage applies. For
example, a STUN server on the public Internet supporting ICE would example, a STUN server on the public Internet supporting ICE would
have no authentication, whereas the STUN server functionality in an have no authentication, whereas the STUN server functionality in an
agent supporting connectivity checks would utilize short term agent supporting connectivity checks would utilize short term
credentials. An overview of these two mechanisms is given in credentials. An overview of these two mechanisms is given in
Section 3. Section 3.
Each mechanism specifies the additional processing required to use Each mechanism specifies the additional processing required to use
that mechanism, extending the processing specified in Section 7. The that mechanism, extending the processing specified in Section 7. The
additional processing occurs in three different places: when forming additional processing occurs in three different places: when forming
a message; when receiving a message immediately after the the basic a message; when receiving a message immediately after the basic
checks have been performed; and when doing the detailed processing of checks have been performed; and when doing the detailed processing of
error responses. error responses.
10.1. Short-Term Credential Mechanism 10.1. Short-Term Credential Mechanism
The short-term credential mechanism assumes that, prior to the STUN The short-term credential mechanism assumes that, prior to the STUN
transaction, the client and server have used some other protocol to transaction, the client and server have used some other protocol to
exchange a credential in the form of a username and password. This exchange a credential in the form of a username and password. This
credential is time-limited. The time-limit is defined by the usage. credential is time-limited. The time-limit is defined by the usage.
As an example, in the ICE usage [I-D.ietf-mmusic-ice], the two As an example, in the ICE usage [I-D.ietf-mmusic-ice], the two
skipping to change at page 27, line 34 skipping to change at page 27, line 34
o UDP was the only supported transport; o UDP was the only supported transport;
o The field that is now the Magic Cookie field was a part of the o The field that is now the Magic Cookie field was a part of the
transaction id field, and transaction ids were 128 bits long; transaction id field, and transaction ids were 128 bits long;
o The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding o The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding
method used the MAPPED-ADDRESS attribute instead; method used the MAPPED-ADDRESS attribute instead;
o There were three comprehension-required attributes, RESPONSE- o There were three comprehension-required attributes, RESPONSE-
ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESSthat have been removed ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESS that have been
from this specification; removed from this specification;
* These attributes are now part of the NAT Behavior Discovery * These attributes are now part of the NAT Behavior Discovery
usage. [I-D.ietf-behave-nat-behavior-discovery] usage. [I-D.ietf-behave-nat-behavior-discovery]
12.1. Changes to Client Processing 12.1. Changes to Client Processing
A client that wants to interoperate with a [RFC3489] server SHOULD A client that wants to interoperate with a [RFC3489] server SHOULD
send a request message that uses the Binding method, contains no send a request message that uses the Binding method, contains no
attributes, and uses UDP as the transport protocol to the server. If attributes, and uses UDP as the transport protocol to the server. If
successful, the success response received from the server will successful, the success response received from the server will
skipping to change at page 45, line 20 skipping to change at page 45, line 20
June 2002. June 2002.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-17 (work in progress), July 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., "Traversal Using Relays around NAT (TURN): Rosenberg, J., "Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT Relay Extensions to Session Traversal Utilities for NAT
(STUN)", draft-ietf-behave-turn-04 (work in progress), (STUN)", draft-ietf-behave-turn-04 (work in progress),
 End of changes. 10 change blocks. 
13 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/