doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3581.txt b/doc/rfc/rfc3581.txt
new file mode 100644
index 0000000..6ba996f
--- /dev/null
+++ b/doc/rfc/rfc3581.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                       J. Rosenberg
+Request for Comments: 3581                                   dynamicsoft
+Category: Standards Track                                 H. Schulzrinne
+                                                     Columbia University
+                                                             August 2003
+
+
+       An Extension to the Session Initiation Protocol (SIP) for
+                       Symmetric Response Routing
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Session Initiation Protocol (SIP) operates over UDP and TCP,
+   among others.  When used with UDP, responses to requests are returned
+   to the source address the request came from, and to the port written
+   into the topmost Via header field value of the request.  This
+   behavior is not desirable in many cases, most notably, when the
+   client is behind a Network Address Translator (NAT).  This extension
+   defines a new parameter for the Via header field, called "rport",
+   that allows a client to request that the server send the response
+   back to the source IP address and port from which the request
+   originated.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 1]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . . .  4
+   5.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
+   9.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . .  6
+       9.1.  Problem Definition . . . . . . . . . . . . . . . . . . .  8
+       9.2.  Exit Strategy  . . . . . . . . . . . . . . . . . . . . .  8
+       9.3.  Brittleness Introduced by this Specification . . . . . .  9
+       9.4.  Requirements for a Long Term Solution  . . . . . . . . . 10
+       9.5.  Issues with Existing NAPT Boxes  . . . . . . . . . . . . 10
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+       11.1. Normative References . . . . . . . . . . . . . . . . . . 11
+       11.2. Informative References . . . . . . . . . . . . . . . . . 11
+   12. Intellectual Property and Copyright Statements . . . . . . . . 11
+   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
+   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+1.  Introduction
+
+   The Session Initiation Protocol (SIP) [1] operates over UDP and TCP.
+   When used with UDP, responses to requests are returned to the source
+   address the request came from, and to the port written into the
+   topmost Via header field value of the request.  This results in a
+   "hybrid" way of computing the destination of the response.  Half of
+   the information (specifically, the IP address) is taken from the IP
+   packet headers, and the other half (specifically, the port) from the
+   SIP message headers.  SIP operates in this manner so that a server
+   can listen for all messages, both requests and responses, on a single
+   IP address and port.  This helps improve scalability.  However, this
+   behavior is not desirable in many cases, most notably, when the
+   client is behind a NAT.  In that case, the response will not properly
+   traverse the NAT, since it will not match the binding established
+   with the request.
+
+   Furthermore, there is currently no way for a client to examine a
+   response and determine the source port that the server saw in the
+   corresponding request.  Currently, SIP provides the client with the
+   source IP address that the server saw in the request, but not the
+   port.  The source IP address is conveyed in the "received" parameter
+   in the topmost Via header field value of the response.  This
+   information has proved useful for basic NAT traversal, debugging
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 2]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+   purposes, and support of multi-homed hosts.  However, it is
+   incomplete without the port information.
+
+   This extension defines a new parameter for the Via header field,
+   called "rport", that allows a client to request that the server send
+   the response back to the source IP address and port where the request
+   came from.  The "rport" parameter is analogous to the "received"
+   parameter, except "rport" contains a port number, not the IP address.
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
+   [2] and indicate requirement levels for compliant implementations.
+
+3.  Client Behavior
+
+   The client behavior specified here affects the transport processing
+   defined in Section 18.1 of SIP (RFC 3261) [1].
+
+   A client, compliant to this specification (clients include UACs and
+   proxies), MAY include an "rport" parameter in the top Via header
+   field value of requests it generates.  This parameter MUST have no
+   value; it serves as a flag to indicate to the server that this
+   extension is supported and requested for the transaction.
+
+   When the client sends the request, if the request is sent using UDP,
+   the client MUST be prepared to receive the response on the same IP
+   address and port it used to populate the source IP address and source
+   port of the request.  For backwards compatibility, the client MUST
+   still be prepared to receive a response on the port indicated in the
+   sent-by field of the topmost Via header field value, as specified in
+   Section 18.1.1 of SIP [1].
+
+   When there is a NAT between the client and server, the request will
+   create (or refresh) a binding in the NAT.  This binding must remain
+   in existence for the duration of the transaction in order for the
+   client to receive the response.  Most UDP NAT bindings appear to have
+   a timeout of about one minute.  This exceeds the duration of non-
+   INVITE transactions.  Therefore, responses to a non-INVITE request
+   will be received while the binding is still in existence.  INVITE
+   transactions can take an arbitrarily long amount of time to complete.
+   As a result, the binding may expire before a final response is
+   received.  To keep the binding fresh, the client SHOULD retransmit
+   its INVITE every 20 seconds or so.  These retransmissions will need
+   to take place even after receiving a provisional response.
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 3]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+   A UA MAY execute the binding lifetime discovery algorithm in Section
+   10.2 of RFC 3489 [4] to determine the actual binding lifetime in the
+   NAT.  If it is longer than 1 minute, the client SHOULD increase the
+   interval for request retransmissions up to half of the discovered
+   lifetime.  If it is shorter than one minute, it SHOULD decrease the
+   interval for request retransmissions to half of the discovered
+   lifetime.  Note that discovery of binding lifetimes can be
+   unreliable.  See Section 14.3 of RFC 3489 [4].
+
+4.  Server Behavior
+
+   The server behavior specified here affects the transport processing
+   defined in Section 18.2 of SIP [1].
+
+   When a server compliant to this specification (which can be a proxy
+   or UAS) receives a request, it examines the topmost Via header field
+   value.  If this Via header field value contains an "rport" parameter
+   with no value, it MUST set the value of the parameter to the source
+   port of the request.  This is analogous to the way in which a server
+   will insert the "received" parameter into the topmost Via header
+   field value.  In fact, the server MUST insert a "received" parameter
+   containing the source IP address that the request came from, even if
+   it is identical to the value of the "sent-by" component.  Note that
+   this processing takes place independent of the transport protocol.
+
+   When a server attempts to send a response, it examines the topmost
+   Via header field value of that response.  If the "sent-protocol"
+   component indicates an unreliable unicast transport protocol, such as
+   UDP, and there is no "maddr" parameter, but there is both a
+   "received" parameter and an "rport" parameter, the response MUST be
+   sent to the IP address listed in the "received" parameter, and the
+   port in the "rport" parameter.  The response MUST be sent from the
+   same address and port that the corresponding request was received on.
+   This effectively adds a new processing step between bullets two and
+   three in Section 18.2.2 of SIP [1].
+
+   The response must be sent from the same address and port that the
+   request was received on in order to traverse symmetric NATs.  When a
+   server is listening for requests on multiple ports or interfaces, it
+   will need to remember the one on which the request was received.  For
+   a stateful proxy, storing this information for the duration of the
+   transaction is not an issue.  However, a stateless proxy does not
+   store state between a request and its response, and therefore cannot
+   remember the address and port on which a request was received.  To
+   properly implement this specification, a stateless proxy can encode
+   the destination address and port of a request into the Via header
+   field value that it inserts.  When the response arrives, it can
+   extract this information and use it to forward the response.
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 4]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+5.  Syntax
+
+   The syntax for the "rport" parameter is:
+
+   response-port = "rport" [EQUAL 1*DIGIT]
+
+   This extends the existing definition of the Via header field
+   parameters, so that its BNF now looks like:
+
+   via-params        =  via-ttl / via-maddr
+                        / via-received / via-branch
+                        / response-port / via-extension
+
+6.  Example
+
+   A client sends an INVITE to a proxy server which looks like, in part:
+
+   INVITE sip:user@example.com SIP/2.0
+   Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
+
+   This INVITE is sent with a source port of 4540 and a source IP
+   address of 10.1.1.1.  The proxy is at 192.0.2.2 (proxy.example.com),
+   listening on both port 5060 and 5070.  The client sends the request
+   to port 5060.  The request passes through a NAT on the way to the
+   proxy, so that the source IP address appears as 192.0.2.1 and the
+   source port as 9988.  The proxy forwards the request, but not before
+   appending a value to the "rport" parameter in the proxied request:
+
+   INVITE sip:user@example.com SIP/2.0
+   Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
+   Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
+    ;branch=z9hG4bKkjshdyff
+
+   This request generates a response which arrives at the proxy:
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
+   Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
+    ;branch=z9hG4bKkjshdyff
+
+   The proxy strips its top Via header field value, and then examines
+   the next one.  It contains both a "received" parameter and an "rport"
+   parameter.  The server follows the rules specified in Section 4 and
+   sends the response to IP address 192.0.2.1, port 9988, and sends it
+   from port 5060 on 192.0.2.2:
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 5]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
+    ;branch=z9hG4bKkjshdyff
+
+   This packet matches the binding created by the initial request.
+   Therefore, the NAT rewrites the destination address of this packet
+   back to 10.1.1.1, and the destination port back to 4540.  It forwards
+   this response to the client, which is listening for the response on
+   that address and port.  The client properly receives the response.
+
+7.  Security Considerations
+
+   When a server uses this specification, responses that it sends will
+   now include the source port where the request came from.  In some
+   instances, the source address and port of a request are sensitive
+   information.  If they are sensitive, requests SHOULD be protected by
+   using SIP over TLS [1].  In such a case, this specification does not
+   provide any response routing functions (as these only work with TCP);
+   it merely provides the client with information about the source port
+   as seen by the server.
+
+   It is possible that an attacker might try to disrupt service to a
+   client by acting as a man-in-the-middle, modifying the "rport"
+   parameter in a Via header in a request sent by a client.  Removal of
+   this parameter will prevent clients from behind NATs from receiving
+   service.  The addition of the parameter will generally have no
+   impact.  Of course, if an attacker is capable of launching a man-in-
+   the-middle attack, there are many other ways of denying service, such
+   as merely discarding the request.  Therefore, this attack does not
+   seem significant.
+
+8.  IANA Considerations
+
+   There are no IANA considerations associated with this specification.
+
+9.  IAB Considerations
+
+   The IAB has studied a class of protocols referred to as Unilateral
+   Self Address Fixing (UNSAF) protocols [5].  These protocols allow a
+   client behind a NAT to learn the IP address and port that a NAT will
+   allocate for a particular request, in order to use this information
+   in application layer protocols.  An example of an UNSAF protocol is
+   the Simple Traversal of UDP Through NATs (STUN) [4].
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 6]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+   Any protocol is an UNSAF protocol if it reveals, to a client, the
+   source IP address and port of a packet sent through that NAT.
+   Although not designed for that purpose, this specification can be
+   used as an UNSAF protocol.  Using the "rport" parameter (defined
+   here) and the "received" parameter (defined in RFC 3261 [1]) in the
+   topmost Via header field value of a response, a client sending a
+   request can learn its address as it was seen by the server which sent
+   the response.
+
+   There are two uses of this information.  The first is for
+   registrations.  Consider a client behind a NAT wishing to register
+   with a proxy/registrar on the other side of the NAT.  The client must
+   provide, in its registration, the address at which it should receive
+   incoming SIP requests from the proxy.  However, since the client is
+   located behind a NAT, none of the addresses on any of its interfaces
+   will be reachable from the proxy.  If the client can provide the
+   proxy with an address that the proxy can reach, the client can
+   receive incoming requests.  Using this specification, a client behind
+   a NAT can learn its address and port as seen by the proxy which
+   receives a REGISTER request.  The client can then perform an
+   additional registration, using this address in a Contact header.
+   This would allow a client to receive incoming requests, such as
+   INVITE, on the IP address and port it used to populate the source IP
+   address and port of the registration it sent.  This approach will
+   only work when servers send requests to a UA from the same address
+   and port on which the REGISTER itself was received.
+
+   In many cases, the server to whom the registration is sent won't be
+   the registrar itself, but rather a proxy which then sends the request
+   to the registrar.  In such a case, any incoming requests for the
+   client must traverse the proxy to whom the registration was directly
+   sent.  The Path header extension to SIP [3] allows the proxy to
+   indicate that it must be on the path of such requests.
+
+   The second usage is for record routing, to address the same problem
+   as above, but between two proxies.  A proxy behind a NAT which
+   forwards a request to a server can use OPTIONS, for example, to learn
+   its address as seen by that server.  This address can be placed into
+   the Record-Route header field of requests sent to that server.  This
+   would allow the proxy to receive requests from that server on the
+   same IP address and port it used to populate the source IP address
+   and port of the OPTIONS request.
+
+   Because of this potential usage, this document must consider the
+   issues raised in [5].
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 7]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+9.1.  Problem Definition
+
+   From [5], any UNSAF proposal must provide:
+
+      Precise definition of a specific, limited-scope problem that is to
+      be solved with the UNSAF proposal.  A short term fix should not be
+      generalized to solve other problems; this is why "short term fixes
+      usually aren't".
+
+   This specification is primarily aimed at allowing SIP responses to be
+   received when a request is sent through a NAT.  In this primary
+   application, this specification is not an UNSAF proposal.  However,
+   as a side effect of this capability, this specification can be used
+   as an UNSAF protocol.  In that usage, it would address two issues:
+
+   o  Provide a client with an address that it could use in the Contact
+      header of a REGISTER request when it is behind a NAT.
+
+   o  Provide a proxy with an address that it could use in a Record-
+      Route header in a request, when it is behind a NAT.
+
+9.2.  Exit Strategy
+
+   From [5], any UNSAF proposal must provide:
+
+      Description of an exit strategy/transition plan.  The better short
+      term fixes are the ones that will naturally see less and less use
+      as the appropriate technology is deployed.
+
+   The SIP working group has recognized that the usage of this
+   specification to support registrations and record-routing through
+   NATs is not appropriate.  It has a number of known problems which are
+   documented below.  The way to eliminate potential usage of this
+   specification for address fixing is to provide a proper solution to
+   the problems that might motivate the usage of this specification for
+   address fixing.  Specifically, appropriate solutions for
+   registrations and record-routing in the presence of NATs need to be
+   developed.  These solutions would not rely on address fixing.
+
+   Requirements for such solutions are already under development [6].
+
+   Implementors of this specification are encouraged to follow this work
+   for better solutions for registrations and record-routing through
+   NAT.
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 8]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+9.3.  Brittleness Introduced by this Specification
+
+   From [5], any UNSAF proposal must provide:
+
+      Discussion of specific issues that may render systems more
+      "brittle".  For example, approaches that involve using data at
+      multiple network layers create more dependencies, increase
+      debugging challenges, and make it harder to transition.
+
+   This specification, if used for address fixing, introduces several
+   points of brittleness into a SIP system:
+
+   o  If used for UDP registrations, a client will need to frequently
+      re-register in order to keep the NAT bindings fresh.  In many
+      cases, these registrations will need to take place nearly one
+      hundred times more frequently than the typical refresh interval of
+      a registration.  This introduces load into the system and hampers
+      scalability.
+
+   o  A client cannot accurately determine the binding lifetime of a NAT
+      it is registering (or record-routing) through.  Therefore, there
+      may be periods of unreachability that occur between the time a
+      binding expires and the next registration or OPTIONS refresh is
+      sent.  This may result in missed calls, messages, or other
+      information.
+
+   o  If the NAT is of the symmetric variety [4], a client will only be
+      able to use its address to receive requests from the server it has
+      sent the request to.  If that server is one of many servers in a
+      cluster, the client may not be able to receive requests from other
+      servers in the cluster.  This may result in missed calls,
+      messages, or other information.
+
+   o  If the NAT is of the symmetric variety [4], a client will only be
+      able to use its address to receive requests if the server sends
+      requests to the client from the same address and port the server
+      received the registrations on.  This server behavior is not
+      mandated by RFC 3261 [1], although it appears to be common in
+      practice.
+
+   o  If the registrar and the server to whom the client sent its
+      REGISTER request are not the same, the approach will only work if
+      the server uses the Path header field [3].  There is not an easy
+      and reliable way for the server to determine that the Path header
+      should be used for a registration.  Using Path when the address in
+      the topmost Via header field is a private address will usually
+      work, but may result in usage of Path when it is not actually
+      needed.
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 9]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+9.4.  Requirements for a Long Term Solution
+
+   From [5], any UNSAF proposal must provide:
+
+      Identify requirements for longer term, sound technical solutions
+      -- contribute to the process of finding the right longer term
+      solution.
+
+   The brittleness described in Section 9.3 has led us to the following
+   requirements for a long term solution:
+
+   The client should not need to specify its address.  Registrations and
+      record routing require the client to specify the address at which
+      it should receive requests.  A sound technical solution should
+      allow a client to explicitly specify that it wants to receive
+      incoming requests on the connection over which the outgoing
+      request was sent.  In this way, the client does not need to
+      specify its address.
+
+   The solution must deal with clusters of servers.  In many
+      commercially deployed SIP systems, there will be multiple servers,
+      each at different addresses and ports, handling incoming requests
+      for a client.  The solution must explicitly consider this case.
+
+   The solution must not require increases in network load.  There
+      cannot be a penalty for a sound technical solution.
+
+9.5.  Issues with Existing NAPT Boxes
+
+   From [5], any UNSAF proposal must provide:
+
+      Discussion of the impact of the noted practical issues with
+      existing, deployed NA[P]Ts and experience reports.
+
+   To our knowledge, at the time of writing, there is only very limited
+   usage of this specification for address fixing.  Therefore, no
+   specific practical issues have been raised.
+
+10.  Acknowledgements
+
+   The authors would like to thank Rohan Mahy and Allison Mankin for
+   their comments and contributions to this work.
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 10]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+11.  References
+
+11.1.  Normative References
+
+   [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+       Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
+       Session Initiation Protocol", RFC 3261, June 2002.
+
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
+       Extension Header Field for Registering Non-Adjacent Contacts",
+       RFC 3327, December 2002.
+
+   [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
+       Simple Traversal of User Datagram Protocol (UDP) Through Network
+       Address Translators (NATs)", RFC 3489, March 2003.
+
+11.2.  Informative References
+
+   [5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral
+       Self-Address Fixing (UNSAF) Across Network Address Translation",
+       RFC 3424, November 2002.
+
+   [6] Mahy, R., "Requirements for Connection Reuse in the Session
+       Initiation Protocol (SIP)", Work in Progress.
+
+12.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 11]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+13.  Authors' Addresses
+
+   Jonathan Rosenberg
+   dynamicsoft
+   600 Lanidex Plaza
+   Parsippany, NJ  07054
+   US
+
+   Phone: +1 973 952-5000
+   EMail: jdrosen@dynamicsoft.com
+   URI:   http://www.jdrosen.net
+
+
+   Henning Schulzrinne
+   Columbia University
+   M/S 0401
+   1214 Amsterdam Ave.
+   New York, NY  10027
+   US
+
+   EMail: schulzrinne@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu/~hgs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 12]
+
+RFC 3581               Symmetric Response Routing            August 2003
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 13]
+