draft-ietf-behave-nat-behavior-discovery-02.txt   draft-ietf-behave-nat-behavior-discovery-03.txt 
BEHAVE D. MacDonald BEHAVE D. MacDonald
Internet-Draft CounterPath Solutions, Inc. Internet-Draft CounterPath Solutions, Inc.
Intended status: Experimental B. Lowekamp Intended status: Experimental B. Lowekamp
Expires: May 20, 2008 SIPeerior Technologies and William Expires: August 28, 2008 SIPeerior Technologies and William
& Mary & Mary
November 17, 2007 February 25, 2008
NAT Behavior Discovery Using STUN NAT Behavior Discovery Using STUN
draft-ietf-behave-nat-behavior-discovery-02 draft-ietf-behave-nat-behavior-discovery-03
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 36 skipping to change at page 1, line 36
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 20, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This specification defines an experimental usage of the Simple This specification defines an experimental usage of the Simple
Traversal Underneath Network Address Translators (NAT) (STUN) Traversal Underneath Network Address Translators (NAT) (STUN)
Protocol that discovers the presence and current behaviour of NATs Protocol that discovers the presence and current behaviour of NATs
and firewalls between the STUN client and the STUN server. and firewalls between the STUN client and the STUN server.
Requirements Language Requirements Language
skipping to change at page 3, line 17 skipping to change at page 3, line 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 26 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 26
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 26 A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 26
A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 26 A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 26
A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Applicability 1. Applicability
This experimental STUN usage does not allow an application behind a This experimental STUN usage does not allow an application behind a
NAT to make an absolute determination of the NAT's characteristics. NAT to make an absolute determination of the NAT's characteristics.
NAT devices do not behave consistently enough to predict future NAT devices do not behave consistently enough to predict future
behaviour with any guarantee. This STUN usage provides information behaviour with any guarantee. This STUN usage provides information
about observable transient behavior; it only truly determines a NAT's about observable transient behavior; it only truly determines a NAT's
skipping to change at page 6, line 16 skipping to change at page 6, line 16
2.2. Example Use with P2P Overlays 2.2. Example Use with P2P Overlays
An application could use Behavior Discovery in a P2P protocol to An application could use Behavior Discovery in a P2P protocol to
determine if a particular endpoint is a reasonable candidate to determine if a particular endpoint is a reasonable candidate to
participate as a peer or supernode (defined here as a peer in the participate as a peer or supernode (defined here as a peer in the
overlay that offers services, including message routing, to other overlay that offers services, including message routing, to other
members or clients of the overlay network). This P2P network members or clients of the overlay network). This P2P network
application is willing to select supernodes that might be located application is willing to select supernodes that might be located
behind NATs to avoid the cost of dedicated servers. A supernode behind NATs to avoid the cost of dedicated servers. A supernode
candidate requires that its NAT(s) offer(s) Address Independent candidate requires that its NAT(s) offer(s) Endpoint-Independent
Filtering. It might periodically re-run tests and would remove Filtering. It might periodically re-run tests and would remove
itself as a supernode if its NAT/FW chain lost this characteristic. itself as a supernode if its NAT/FW chain lost this characteristic.
These tests could be run with other supernode candidates acting as These tests could be run with other supernode candidates acting as
STUN servers as well as dedicated STUN servers. As many P2P STUN servers as well as dedicated STUN servers. As many P2P
algorithms tolerate non-transitive connectivity between a portion of algorithms tolerate non-transitive connectivity between a portion of
their peers, guaranteed pair-wise reliable reach might be sacrificed their peers, guaranteed pair-wise reliable reach might be sacrificed
in order to distribute the P2P overlay's load across peers that can in order to distribute the P2P overlay's load across peers that can
be directly contacted by the majority of users. be directly contacted by the majority of users.
Use of Behavior Discovery for such an application requires: Use of Behavior Discovery for such an application requires:
o Specification of protocols capable of offering reliable end-user o Specification of protocols capable of offering reliable end-user
performance using unreliable links between peers. performance using unreliable links between peers.
o The application is deployed behind NATs that provide Address o The application is deployed behind NATs that provide Endpoint-
Independent Filtering and that remain in this mode for an amount Independent Filtering and that remain in this mode for an amount
of time sufficient for the application to identify their behavior, of time sufficient for the application to identify their behavior,
distribute this information to the rest of the overlay, and distribute this information to the rest of the overlay, and
provide useful work for the application. provide useful work for the application.
This draft is experimental as deployed applications implementing open This draft is experimental as deployed applications implementing open
protocols have yet to be deployed in such environments to demonstrate protocols have yet to be deployed in such environments to demonstrate
that these two requirements have been met. However, apocryphal that these two requirements have been met. However, apocryphal
evidence suggests that household- and small business-targeted NAT evidence suggests that household- and small business-targeted NAT
devices have stable behaviour, especially when there are few clients devices have stable behaviour, especially when there are few clients
skipping to change at page 8, line 8 skipping to change at page 8, line 8
messages to be used to diagnose the current behavior of the NAT(s) messages to be used to diagnose the current behavior of the NAT(s)
between the client and server. between the client and server.
This section provides a descriptive overview of the typical use of This section provides a descriptive overview of the typical use of
these attributes. Normative behavior is described in Sections 5, 6, these attributes. Normative behavior is described in Sections 5, 6,
and 7. and 7.
3.1. Determining NAT Mapping 3.1. Determining NAT Mapping
A client behind a NAT wishes to determine if the NAT it is behind is A client behind a NAT wishes to determine if the NAT it is behind is
currently using independent, address dependent, or port dependent currently using endpoint-independent, address-dependent, or address
mapping[RFC4787]. The client performs a series of tests that make and port-dependent mapping[RFC4787]. The client performs a series of
use of the OTHER-ADDRESS attribute; these tests are described in tests that make use of the OTHER-ADDRESS attribute; these tests are
detail in Section 4. These tests send binding requests to the described in detail in Section 4. These tests send binding requests
alternate address and port of the STUN server to determine mapping to the alternate address and port of the STUN server to determine
behaviour. These tests can be used for UDP, TCP, or TCP/TLS mapping behaviour. These tests can be used for UDP, TCP, or TCP/TLS
connections. connections.
3.2. Determining NAT Filtering 3.2. Determining NAT Filtering
A client behind a NAT wishes to determine if the NAT it is behind is A client behind a NAT wishes to determine if the NAT it is behind is
currently using independent, address dependent, or port dependent currently using endpoint-independent, address-dependent, or address
filtering[RFC4787]. The client performs a series of tests that make and port-dependent filtering[RFC4787]. The client performs a series
use of the OTHER-ADDRESS and CHANGE-REQUEST attributes; these tests of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST
are described in Section 4. These tests request responses from the attributes; these tests are described in Section 4. These tests
alternate address and port of the STUN server; a precondition to request responses from the alternate address and port of the STUN
these tests is that no binding be established to the alternate server; a precondition to these tests is that no binding be
address and port. Because the NAT does not know that the alternate established to the alternate address and port. Because the NAT does
address and port belong to the same server as the primary address and not know that the alternate address and port belong to the same
port, it treats these responses the same as it would those from any server as the primary address and port, it treats these responses the
other host on the Internet. Therefore, the success of the binding same as it would those from any other host on the Internet.
responses sent from the alternate address and port indicate whether Therefore, the success of the binding responses sent from the
the NAT is currently performing independent filtering, address alternate address and port indicate whether the NAT is currently
dependent filtering, or address and port dependent filtering. This performing endpoint-independent filtering, address-dependent
test applies only to UDP datagrams. filtering, or address and port-dependent filtering. This test
applies only to UDP datagrams.
3.3. Binding Lifetime Discovery 3.3. Binding Lifetime Discovery
Many systems, such as VoIP, rely on being able to keep a connection Many systems, such as VoIP, rely on being able to keep a connection
open between a client and server or between peers of a P2P system. open between a client and server or between peers of a P2P system.
Because NAT bindings expire over time, keepalive messages must be Because NAT bindings expire over time, keepalive messages must be
sent across the connection to preserve it. Because keepalives impose sent across the connection to preserve it. Because keepalives impose
some overhead on the network and servers, reducing the frequency of some overhead on the network and servers, reducing the frequency of
keepalives can be useful. keepalives can be useful.
skipping to change at page 9, line 39 skipping to change at page 9, line 39
XOR-RESPONSE-TARGET. XOR-RESPONSE-TARGET.
3.6. Detecting Generic ALGs 3.6. Detecting Generic ALGs
A number of NAT boxes are now being deployed into the market which A number of NAT boxes are now being deployed into the market which
try to provide "generic" ALG functionality. These generic ALGs hunt try to provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This behavior can be detected rewrite them if they match a binding. This behavior can be detected
because the STUN server returns both the MAPPED-ADDRESS and XOR- because the STUN server returns both the MAPPED-ADDRESS and XOR-
MAPPED-ADDRESS in the same response. If the result in the two does MAPPED-ADDRESS in the same response. If the result in the two does
not match, there is a NAT with a generic ALG in the path. not match, there is a NAT with a generic ALG in the path. This test
apples to UDP and TCP, but not TLS over TCP connections.
4. Discovery Process 4. Discovery Process
The NAT Behavior Discovery usage provides primitives that allow STUN The NAT Behavior Discovery usage provides primitives that allow STUN
checks to be made to determine the current behaviour of the NAT or checks to be made to determine the current behaviour of the NAT or
NATs an application is behind. These tests can only give the NATs an application is behind. These tests can only give the
instantaneous behaviour of a NAT; it has been found that NATs can instantaneous behaviour of a NAT; it has been found that NATs can
change behaviour under load and over time. An application must change behaviour under load and over time. An application must
assume that NAT behaviour can become more restrictive at any time. assume that NAT behaviour can become more restrictive at any time.
The tests described here are for UDP connectivity, NAT mapping The tests described here are for UDP connectivity, NAT mapping
skipping to change at page 10, line 24 skipping to change at page 10, line 25
4.2. Determining NAT Mapping Behavior 4.2. Determining NAT Mapping Behavior
This will require at most three tests. In test I, the client This will require at most three tests. In test I, the client
performs the UDP connectivity test. The server will return its performs the UDP connectivity test. The server will return its
alternate address and port in OTHER-ADDRESS in the binding response. alternate address and port in OTHER-ADDRESS in the binding response.
If OTHER-ADDRESS is not returned, the server does not support this If OTHER-ADDRESS is not returned, the server does not support this
usage and this test cannot be run. The client examines the XOR- usage and this test cannot be run. The client examines the XOR-
MAPPED-ADDRESS attribute. If this address and port are the same as MAPPED-ADDRESS attribute. If this address and port are the same as
the local IP address and port of the socket used to send the request, the local IP address and port of the socket used to send the request,
the client knows that it is not NATed and the effective mapping will the client knows that it is not NATed and the effective mapping will
be Endpoint Independent. be Endpoint-Independent.
In test II, the client sends a Binding Request to the alternate In test II, the client sends a Binding Request to the alternate
address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding
Response is the same as test I the NAT currently has Endpoint Response is the same as test I the NAT currently has Endpoint-
Independent Mapping. If not, test III is performed: the client sends Independent Mapping. If not, test III is performed: the client sends
a Binding Request to the alternate address and port. If the XOR- a Binding Request to the alternate address and port. If the XOR-
MAPPED-ADDRESS matches test II, the NAT currently has Address MAPPED-ADDRESS matches test II, the NAT currently has Address-
Dependent Mapping; if it doesn't match it currently has Address and Dependent Mapping; if it doesn't match it currently has Address and
Port Dependent Mapping. Port-Dependent Mapping.
4.3. Determining NAT Filtering Behavior 4.3. Determining NAT Filtering Behavior
This will also require at most three tests. These tests should be This will also require at most three tests. These tests should be
performed using a port that wasn't used for mapping or other tests as performed using a port that wasn't used for mapping or other tests as
packets sent during those tests may affect results. In test I, the packets sent during those tests may affect results. In test I, the
client performs the UDP connectivity test. The server will return client performs the UDP connectivity test. The server will return
its alternate address and port in OTHER-ADDRESS in the binding its alternate address and port in OTHER-ADDRESS in the binding
response. If OTHER-ADDRESS is not returned, the server does not response. If OTHER-ADDRESS is not returned, the server does not
support this usage and this test cannot be run. support this usage and this test cannot be run.
In test II, the client sends a binding request to the primary address In test II, the client sends a binding request to the primary address
of the server with the CHANGE-REQUEST attribute set to change-port of the server with the CHANGE-REQUEST attribute set to change-port
and change-IP. This will cause the server to send its response from and change-IP. This will cause the server to send its response from
its alternate IP address and alternate port. If the client receives its alternate IP address and alternate port. If the client receives
a response the current behaviour of the NAT is Address Independent a response the current behaviour of the NAT is Endpoint-Independent
Filtering. Filtering.
If no response is received, test III must be performed to distinguish If no response is received, test III must be performed to distinguish
between Address Dependent Filtering and Address and Port Dependent between Address-Dependent Filtering and Address and Port-Dependent
Filtering. In test III, the client sends a binding request to the Filtering. In test III, the client sends a binding request to the
original server address with CHANGE-REQUEST set to change-port. If original server address with CHANGE-REQUEST set to change-port. If
the client receives a response the current behaviour is Address the client receives a response the current behaviour is Address-
Dependent Filtering; if no response is received the current behaviour Dependent Filtering; if no response is received the current behaviour
is Address and Port Dependent Filtering. is Address and Port-Dependent Filtering.
4.4. Combining and Ordering Tests 4.4. Combining and Ordering Tests
Clients may wish to combine and parallelize these tests to reduce the Clients may wish to combine and parallelize these tests to reduce the
number of packets sent and speed the discovery process. For example, number of packets sent and speed the discovery process. For example,
test I of the filtering and mapping tests also checks if UDP is test I of the filtering and mapping tests also checks if UDP is
blocked. Furthermore, an application or user may not need as much blocked. Furthermore, an application or user may not need as much
detail as these sample tests provide. For example, establishing detail as these sample tests provide. For example, establishing
connectivity between nodes becomes significantly more difficult if a connectivity between nodes becomes significantly more difficult if a
NAT has any behavior other than endpoint independent mapping, which NAT has any behavior other than endpoint-independent mapping, which
requires only test I and II of Section 4.2. An application requires only test I and II of Section 4.2. An application
determining its NAT does not always provide independent mapping might determining its NAT does not always provide independent mapping might
notify the user if no relay is configured, whereas an application notify the user if no relay is configured, whereas an application
behind a NAT that provides endpoint independent mapping might not behind a NAT that provides endpoint-independent mapping might not
notify the user until a subsequent connection actually fails or might notify the user until a subsequent connection actually fails or might
provide a less urgent notification that no relay is configured. Such provide a less urgent notification that no relay is configured. Such
a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but
it does provide some information regarding whether ICE is likely to it does provide some information regarding whether ICE is likely to
be successful establishing non-relayed connections. be successful establishing non-relayed connections.
Care must be taken when parallelizing tests, as some NAT devices have Care must be taken when parallelizing tests, as some NAT devices have
an upper limit on how quickly bindings will be allocated. an upper limit on how quickly bindings will be allocated.
4.5. Binding Lifetime Discovery 4.5. Binding Lifetime Discovery
skipping to change at page 19, line 47 skipping to change at page 19, line 47
If PADDING is present in the Binding Request and the server supports If PADDING is present in the Binding Request and the server supports
it, PADDING MUST be present in the Binding Response. The server it, PADDING MUST be present in the Binding Response. The server
SHOULD use the same length PADDING as was used in the Binding SHOULD use the same length PADDING as was used in the Binding
Request, but it MAY use another length if it knows what length is Request, but it MAY use another length if it knows what length is
required to cause fragmentation along the return path. If the server required to cause fragmentation along the return path. If the server
supports PADDING (i.e. doesn't return a 420 in response to a Request supports PADDING (i.e. doesn't return a 420 in response to a Request
containing PADDING), then it MUST use either the requested length or containing PADDING), then it MUST use either the requested length or
a length it knows is sufficient to cause fragmentation. a length it knows is sufficient to cause fragmentation.
PADDING MUST be no longer than 64K and SHOULD be an even multiple of PADDING MUST be no longer than 64K and SHOULD be an even multiple of
four bytes. four bytes. Because STUN messages with PADDING are intended to test
the behavior of UDP fragments, they are an exception to the usual
rule that STUN messages be less than the MTU of the path.
7.8. CACHE-TIMEOUT 7.8. CACHE-TIMEOUT
The CACHE-TIMEOUT is used in Binding Requests and Responses. It The CACHE-TIMEOUT is used in Binding Requests and Responses. It
indicates the time duration (in seconds) that the server will cache indicates the time duration (in seconds) that the server will cache
the source address and USERNAME of an original binding request that the source address and USERNAME of an original binding request that
will later by followed by a request from a different source address will later by followed by a request from a different source address
with a XOR-RESPONSE-TARGET asking that a response be reflected to the with a XOR-RESPONSE-TARGET asking that a response be reflected to the
source address of the original binding request. A server SHOULD NOT source address of the original binding request. A server SHOULD NOT
send a response to a target address requested with XOR-RESPONSE- send a response to a target address requested with XOR-RESPONSE-
skipping to change at page 22, line 42 skipping to change at page 22, line 42
solution. solution.
As long as NATs are present, means of adapting to their presence will As long as NATs are present, means of adapting to their presence will
be required. Direct control or discovery of NATs by applications, be required. Direct control or discovery of NATs by applications,
such as proposed in Nat Control STUN Usage such as proposed in Nat Control STUN Usage
[I-D.wing-behave-nat-control-stun-usage], will eliminate the need for [I-D.wing-behave-nat-control-stun-usage], will eliminate the need for
anonymous diagnostics of NAT behavior. anonymous diagnostics of NAT behavior.
9.5. Issues with Existing NAPT Boxes 9.5. Issues with Existing NAPT Boxes
>From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports. existing, deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market which A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This usage avoids that problem rewrite them if they match a binding. This usage avoids that problem
by using the XOR-REFLECTED-FROM and XOR-RESPONSE-TARGET attributes by using the XOR-REFLECTED-FROM and XOR-RESPONSE-TARGET attributes
instead of the older REFLECTED-FROM and RESPONSE-ADDRESS attributes. instead of the older REFLECTED-FROM and RESPONSE-ADDRESS attributes.
skipping to change at page 23, line 19 skipping to change at page 23, line 19
not be readily detected using the tests described herein. However, not be readily detected using the tests described herein. However,
the techniques described in this usage can be assembled in different the techniques described in this usage can be assembled in different
combinations to test NAT behaviors not now known or envisioned. combinations to test NAT behaviors not now known or envisioned.
10. IANA Considerations 10. IANA Considerations
This specification defines several new STUN attributes. This section This specification defines several new STUN attributes. This section
directs IANA to add these new protocol elements to the IANA registry directs IANA to add these new protocol elements to the IANA registry
of STUN protocol elements. of STUN protocol elements.
OPEN ISSUE: does IANA consider CHANGE-REQUEST a new attribute or is
it forever from original 3489?
0x0003: CHANGE-REQUEST 0x0003: CHANGE-REQUEST
0x0027: XOR-RESPONSE-TARGET 0x0027: XOR-RESPONSE-TARGET
0x0028: XOR-REFLECTED-FROM 0x0028: XOR-REFLECTED-FROM
0x0026: PADDING 0x0026: PADDING
0x8027: CACHE-TIMEOUT 0x8027: CACHE-TIMEOUT
0x802b: RESPONSE-ORIGIN 0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS 0x802c: OTHER-ADDRESS
This specification defines two new STUN error response codes. This specification defines two new STUN error response codes.
skipping to change at page 24, line 48 skipping to change at page 24, line 45
specification [RFC3489] from which many of the ideas, attributes, and specification [RFC3489] from which many of the ideas, attributes, and
description in this document originated. description in this document originated.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-12 (work in progress), draft-ietf-behave-rfc3489bis-15 (work in progress),
November 2007. February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
skipping to change at page 25, line 28 skipping to change at page 25, line 25
[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-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-10 (work in progress), July 2007. draft-ietf-sip-outbound-11 (work in progress),
November 2007.
[I-D.wing-behave-nat-control-stun-usage] [I-D.wing-behave-nat-control-stun-usage]
Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering, Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering,
Querying, and Controlling Firewalls and NATs", Querying, and Controlling Firewalls and NATs",
draft-wing-behave-nat-control-stun-usage-05 (work in draft-wing-behave-nat-control-stun-usage-05 (work in
progress), October 2007. progress), October 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
skipping to change at page 27, line 10 skipping to change at page 27, line 10
o Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address o Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address
compatibility with 3489bis clients. Renamed SOURCE-ADDRESS as compatibility with 3489bis clients. Renamed SOURCE-ADDRESS as
RESPONSE-ORIGIN to avoid conflicts with 3489. RESPONSE-ORIGIN to avoid conflicts with 3489.
o Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGET o Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGET
o Added discussion of FINGERPRINT and ALTERNATE-SERVER for o Added discussion of FINGERPRINT and ALTERNATE-SERVER for
compliance with 3489bis stun usage definition requirements. compliance with 3489bis stun usage definition requirements.
A.4. from draft-ietf-behave-nat-behavior-discovery-02
o fix terminology for endpoint-independent, address-dependent, and
address and port-dependent from rfc4787
o define the ALG detection to apply to UDP and TCP
o fix >From typo in 9.5
o added exception to single MTU size restriction for PADDING
o removed OPEN ISSUE about CHANGE-REQUEST IANA registry based on the
belief that we need to list that definition here now that 3489bis
is dropping it.
Authors' Addresses Authors' Addresses
Derek C. MacDonald Derek C. MacDonald
CounterPath Solutions, Inc. CounterPath Solutions, Inc.
Suite 300, One Bentall Centre, 505 Burrard St Suite 300, One Bentall Centre, 505 Burrard St
Vancouver, BC V7X1M3 Vancouver, BC V7X1M3
Canada Canada
Phone: +1-604-320-3344 Phone: +1-604-320-3344
Email: derek@counterpath.com Email: derek@counterpath.com
skipping to change at page 28, line 7 skipping to change at page 28, line 7
SIPeerior Technologies and William & Mary SIPeerior Technologies and William & Mary
3000 Easter Circle 3000 Easter Circle
Williamsburg, Virginia 23188 Williamsburg, Virginia 23188
USA USA
Phone: +1-757-565-0101 Phone: +1-757-565-0101
Email: lowekamp@sipeerior.com Email: lowekamp@sipeerior.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 28 change blocks. 
47 lines changed or deleted 65 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/