doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3263.txt b/doc/rfc/rfc3263.txt
new file mode 100644
index 0000000..37919cd
--- /dev/null
+++ b/doc/rfc/rfc3263.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                       J. Rosenberg
+Request for Comments: 3263                                   dynamicsoft
+Obsoletes: 2543                                           H. Schulzrinne
+Category: Standards Track                                    Columbia U.
+                                                               June 2002
+
+
+        Session Initiation Protocol (SIP): Locating SIP Servers
+
+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 (2002).  All Rights Reserved.
+
+Abstract
+
+   The Session Initiation Protocol (SIP) uses DNS procedures to allow a
+   client to resolve a SIP Uniform Resource Identifier (URI) into the IP
+   address, port, and transport protocol of the next hop to contact.  It
+   also uses DNS to allow a server to send a response to a backup client
+   if the primary client has failed.  This document describes those DNS
+   procedures in detail.
+
+Table of Contents
+
+   1          Introduction ........................................    2
+   2          Problems DNS is Needed to Solve .....................    2
+   3          Terminology .........................................    5
+   4          Client Usage ........................................    5
+   4.1        Selecting a Transport Protocol ......................    6
+   4.2        Determining Port and IP Address .....................    8
+   4.3        Details of RFC 2782 Process .........................    9
+   4.4        Consideration for Stateless Proxies .................   10
+   5          Server Usage ........................................   11
+   6          Constructing SIP URIs ...............................   12
+   7          Security Considerations .............................   12
+   8          The Transport Determination Application .............   13
+   9          IANA Considerations .................................   14
+   10         Acknowledgements ....................................   14
+   11         Normative References ................................   15
+   12         Informative References ..............................   15
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 1]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   13         Authors' Addresses ..................................   16
+   14         Full Copyright Statement ............................   17
+
+1 Introduction
+
+   The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a client-
+   server protocol used for the initiation and management of
+   communications sessions between users.  SIP end systems are called
+   user agents, and intermediate elements are known as proxy servers.  A
+   typical SIP configuration, referred to as the SIP "trapezoid", is
+   shown in Figure 1.  In this diagram, a caller in domain A (UA1)
+   wishes to call Joe in domain B (joe@B).  To do so, it communicates
+   with proxy 1 in its domain (domain A).  Proxy 1 forwards the request
+   to the proxy for the domain of the called party (domain B), which is
+   proxy 2.  Proxy 2 forwards the call to the called party, UA 2.
+
+   As part of this call flow, proxy 1 needs to determine a SIP server
+   for domain B.  To do this, proxy 1 makes use of DNS procedures, using
+   both SRV [2] and NAPTR [3] records.  This document describes the
+   specific problems that SIP uses DNS to help solve, and provides a
+   solution.
+
+2 Problems DNS is Needed to Solve
+
+   DNS is needed to help solve two aspects of the general call flow
+   described in the Introduction.  The first is for proxy 1 to discover
+   the SIP server in domain B, in order to forward the call for joe@B.
+   The second is for proxy 2 to identify a backup for proxy 1 in the
+   event it fails after forwarding the request.
+
+   For the first aspect, proxy 1 specifically needs to determine the IP
+   address, port, and transport protocol for the server in domain B.
+   The choice of transport protocol is particularly noteworthy.  Unlike
+   many other protocols, SIP can run over a variety of transport
+   protocols, including TCP, UDP, and SCTP.  SIP can also use TLS.
+   Currently, use of TLS is defined for TCP only.  Thus, clients need to
+   be able to automatically determine which transport protocols are
+   available.  The proxy sending the request has a particular set of
+   transport protocols it supports and a preference for using those
+   transport protocols.  Proxy 2 has its own set of transport protocols
+   it supports, and relative preferences for those transport protocols.
+   All proxies must implement both UDP and TCP, along with TLS over TCP,
+   so that there is always an intersection of capabilities.  Some form
+   of DNS procedures are needed for proxy 1 to discover the available
+   transport protocols for SIP services at domain B, and the relative
+   preferences of those transport protocols.  Proxy 1 intersects its
+   list of supported transport protocols with those of proxy 2 and then
+   chooses the protocol preferred by proxy 2.
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 2]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+    ............................          ..............................
+    .                          .          .                            .
+    .                +-------+ .          . +-------+                  .
+    .                |       | .          . |       |                  .
+    .                | Proxy |------------- | Proxy |                  .
+    .                |   1   | .          . |  2    |                  .
+    .                |       | .          . |       |                  .
+    .              / +-------+ .          . +-------+ \                .
+    .             /            .          .            \               .
+    .            /             .          .             \              .
+    .           /              .          .              \             .
+    .          /               .          .               \            .
+    .         /                .          .                \           .
+    .        /                 .          .                 \          .
+    .       /                  .          .                  \         .
+    .   +-------+              .          .                +-------+   .
+    .   |       |              .          .                |       |   .
+    .   |       |              .          .                |       |   .
+    .   | UA 1  |              .          .                | UA 2  |   .
+    .   |       |              .          .                |       |   .
+    .   +-------+              .          .                +-------+   .
+    .              Domain A    .          .   Domain B                 .
+    ............................          ..............................
+
+                        Figure 1: The SIP trapezoid
+
+   It is important to note that DNS lookups can be used multiple times
+   throughout the processing of a call.  In general, an element that
+   wishes to send a request (called a client) may need to perform DNS
+   processing to determine the IP address, port, and transport protocol
+   of a next hop element, called a server (it can be a proxy or a user
+   agent).  Such processing could, in principle, occur at every hop
+   between elements.
+
+   Since SIP is used for the establishment of interactive communications
+   services, the time it takes to complete a transaction between a
+   caller and called party is important.  Typically, the time from when
+   the caller initiates a call until the time the called party is
+   alerted should be no more than a few seconds.  Given that there can
+   be multiple hops, each of which is doing DNS lookups in addition to
+   other potentially time-intensive operations, the amount of time
+   available for DNS lookups at each hop is limited.
+
+   Scalability and high availability are important in SIP. SIP services
+   scale up through clustering techniques.  Typically, in a realistic
+   version of the network in Figure 1, proxy 2 would be a cluster of
+   homogeneously configured proxies.  DNS needs to provide the ability
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 3]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   for domain B to configure a set of servers, along with prioritization
+   and weights, in order to provide a crude level of capacity-based load
+   balancing.
+
+   SIP assures high availability by having upstream elements detect
+   failures.  For example, assume that proxy 2 is implemented as a
+   cluster of two proxies, proxy 2.1 and proxy 2.2.  If proxy 1 sends a
+   request to proxy 2.1 and the request fails, it retries the request by
+   sending it to proxy 2.2.  In many cases, proxy 1 will not know which
+   domains it will ultimately communicate with.  That information would
+   be known when a user actually makes a call to another user in that
+   domain.  Proxy 1 may never communicate with that domain again after
+   the call completes.  Proxy 1 may communicate with thousands of
+   different domains within a few minutes, and proxy 2 could receive
+   requests from thousands of different domains within a few minutes.
+   Because of this "many-to-many" relationship, and the possibly long
+   intervals between communications between a pair of domains, it is not
+   generally possible for an element to maintain dynamic availability
+   state for the proxies it will communicate with.  When a proxy gets
+   its first call with a particular domain, it will try the servers in
+   that domain in some order until it finds one that is available.  The
+   identity of the available server would ideally be cached for some
+   amount of time in order to reduce call setup delays of subsequent
+   calls.  The client cannot query a failed server continuously to
+   determine when it becomes available again, since this does not scale.
+   Furthermore, the availability state must eventually be flushed in
+   order to redistribute load to recovered elements when they come back
+   online.
+
+   It is possible for elements to fail in the middle of a transaction.
+   For example, after proxy 2 forwards the request to UA 2, proxy 1
+   fails.  UA 2 sends its response to proxy 2, which tries to forward it
+   to proxy 1, which is no longer available.  The second aspect of the
+   flow in the introduction for which DNS is needed, is for proxy 2 to
+   identify a backup for proxy 1 that it can send the response to.  This
+   problem is more realistic in SIP than it is in other transactional
+   protocols.  The reason is that some SIP responses can take a long
+   time to be generated, because a human user frequently needs to be
+   consulted in order to generate that response.  As such, it is not
+   uncommon for tens of seconds to elapse between a call request and its
+   acceptance.
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 4]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+3 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 RFC 2119 [4] and
+   indicate requirement levels for compliant SIP implementations.
+
+4 Client Usage
+
+   Usage of DNS differs for clients and for servers.  This section
+   discusses client usage.  We assume that the client is stateful
+   (either a User Agent Client (UAC) or a stateful proxy).  Stateless
+   proxies are discussed in Section 4.4.
+
+   The procedures here are invoked when a client needs to send a request
+   to a resource identified by a SIP or SIPS (secure SIP) URI.  This URI
+   can identify the desired resource to which the request is targeted
+   (in which case, the URI is found in the Request-URI), or it can
+   identify an intermediate hop towards that resource (in which case,
+   the URI is found in the Route header).  The procedures defined here
+   in no way affect this URI (i.e., the URI is not rewritten with the
+   result of the DNS lookup), they only result in an IP address, port
+   and transport protocol where the request can be sent.  RFC 3261 [1]
+   provides guidelines on determining which URI needs to be resolved in
+   DNS to determine the host that the request needs to be sent to.  In
+   some cases, also documented in [1], the request can be sent to a
+   specific intermediate proxy not identified by a SIP URI, but rather,
+   by a hostname or numeric IP address.  In that case, a temporary URI,
+   used for purposes of this specification, is constructed.  That URI is
+   of the form sip:<proxy>, where <proxy> is the FQDN or numeric IP
+   address of the next-hop proxy.  As a result, in all cases, the
+   problem boils down to resolution of a SIP or SIPS URI in DNS to
+   determine the IP address, port, and transport of the host to which
+   the request is to be sent.
+
+   The procedures here MUST be done exactly once per transaction, where
+   transaction is as defined in [1].  That is, once a SIP server has
+   successfully been contacted (success is defined below), all
+   retransmissions of the SIP request and the ACK for non-2xx SIP
+   responses to INVITE MUST be sent to the same host.  Furthermore, a
+   CANCEL for a particular SIP request MUST be sent to the same SIP
+   server that the SIP request was delivered to.
+
+   Because the ACK request for 2xx responses to INVITE constitutes a
+   different transaction, there is no requirement that it be delivered
+   to the same server that received the original request (indeed, if
+   that server did not record-route, it will not get the ACK).
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 5]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   We define TARGET as the value of the maddr parameter of the URI, if
+   present, otherwise, the host value of the hostport component of the
+   URI.  It identifies the domain to be contacted.  A description of the
+   SIP and SIPS URIs and a definition of these parameters can be found
+   in [1].
+
+   We determine the transport protocol, port and IP address of a
+   suitable instance of TARGET in Sections 4.1 and 4.2.
+
+4.1 Selecting a Transport Protocol
+
+   First, the client selects a transport protocol.
+
+   If the URI specifies a transport protocol in the transport parameter,
+   that transport protocol SHOULD be used.
+
+   Otherwise, if no transport protocol is specified, but the TARGET is a
+   numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
+   for a SIPS URI.  Similarly, if no transport protocol is specified,
+   and the TARGET is not numeric, but an explicit port is provided, the
+   client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI.  This is
+   because UDP is the only mandatory transport in RFC 2543 [6], and thus
+   the only one guaranteed to be interoperable for a SIP URI.  It was
+   also specified as the default transport in RFC 2543 when no transport
+   was present in the SIP URI.  However, another transport, such as TCP,
+   MAY be used if the guidelines of SIP mandate it for this particular
+   request.  That is the case, for example, for requests that exceed the
+   path MTU.
+
+   Otherwise, if no transport protocol or port is specified, and the
+   target is not a numeric IP address, the client SHOULD perform a NAPTR
+   query for the domain in the URI.  The services relevant for the task
+   of transport protocol selection are those with NAPTR service fields
+   with values "SIP+D2X" and "SIPS+D2X", where X is a letter that
+   corresponds to a transport protocol supported by the domain.  This
+   specification defines D2U for UDP, D2T for TCP, and D2S for SCTP.  We
+   also establish an IANA registry for NAPTR service name to transport
+   protocol mappings.
+
+   These NAPTR records provide a mapping from a domain to the SRV record
+   for contacting a server with the specific transport protocol in the
+   NAPTR services field.  The resource record will contain an empty
+   regular expression and a replacement value, which is the SRV record
+   for that particular transport protocol.  If the server supports
+   multiple transport protocols, there will be multiple NAPTR records,
+   each with a different service value.  As per RFC 2915 [3], the client
+   discards any records whose services fields are not applicable.  For
+   the purposes of this specification, several rules are defined.
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 6]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   First, a client resolving a SIPS URI MUST discard any services that
+   do not contain "SIPS" as the protocol in the service field.  The
+   converse is not true, however.  A client resolving a SIP URI SHOULD
+   retain records with "SIPS" as the protocol, if the client supports
+   TLS.  Second, a client MUST discard any service fields that identify
+   a resolution service whose value is not "D2X", for values of X that
+   indicate transport protocols supported by the client.  The NAPTR
+   processing as described in RFC 2915 will result in the discovery of
+   the most preferred transport protocol of the server that is supported
+   by the client, as well as an SRV record for the server.  It will also
+   allow the client to discover if TLS is available and its preference
+   for its usage.
+
+   As an example, consider a client that wishes to resolve
+   sip:user@example.com.  The client performs a NAPTR query for that
+   domain, and the following NAPTR records are returned:
+
+   ;          order pref flags service      regexp  replacement
+      IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.com.
+      IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.example.com
+      IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.example.com.
+
+   This indicates that the server supports TLS over TCP, TCP, and UDP,
+   in that order of preference.  Since the client supports TCP and UDP,
+   TCP will be used, targeted to a host determined by an SRV lookup of
+   _sip._tcp.example.com.  That lookup would return:
+
+   ;;          Priority Weight Port   Target
+       IN SRV  0        1      5060   server1.example.com
+       IN SRV  0        2      5060   server2.example.com
+
+   If a SIP proxy, redirect server, or registrar is to be contacted
+   through the lookup of NAPTR records, there MUST be at least three
+   records - one with a "SIP+D2T" service field, one with a "SIP+D2U"
+   service field, and one with a "SIPS+D2T" service field.  The records
+   with SIPS as the protocol in the service field SHOULD be preferred
+   (i.e., have a lower value of the order field) above records with SIP
+   as the protocol in the service field.  A record with a "SIPS+D2U"
+   service field SHOULD NOT be placed into the DNS, since it is not
+   possible to use TLS over UDP.
+
+   It is not necessary for the domain suffixes in the NAPTR replacement
+   field to match the domain of the original query (i.e., example.com
+   above).  However, for backwards compatibility with RFC 2543, a domain
+   MUST maintain SRV records for the domain of the original query, even
+   if the NAPTR record is in a different domain.  As an example, even
+   though the SRV record for TCP is _sip._tcp.school.edu, there MUST
+   also be an SRV record at _sip._tcp.example.com.
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 7]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+      RFC 2543 will look up the SRV records for the domain directly.  If
+      these do not exist because the NAPTR replacement points to a
+      different domain, the client will fail.
+
+   For NAPTR records with SIPS protocol fields, (if the server is using
+   a site certificate), the domain name in the query and the domain name
+   in the replacement field MUST both be valid based on the site
+   certificate handed out by the server in the TLS exchange.  Similarly,
+   the domain name in the SRV query and the domain name in the target in
+   the SRV record MUST both be valid based on the same site certificate.
+   Otherwise, an attacker could modify the DNS records to contain
+   replacement values in a different domain, and the client could not
+   validate that this was the desired behavior or the result of an
+   attack.
+
+   If no NAPTR records are found, the client constructs SRV queries for
+   those transport protocols it supports, and does a query for each.
+   Queries are done using the service identifier "_sip" for SIP URIs and
+   "_sips" for SIPS URIs.  A particular transport is supported if the
+   query is successful.  The client MAY use any transport protocol it
+   desires which is supported by the server.
+
+      This is a change from RFC 2543.  It specified that a client would
+      lookup SRV records for all transports it supported, and merge the
+      priority values across those records.  Then, it would choose the
+      most preferred record.
+
+   If no SRV records are found, the client SHOULD use TCP for a SIPS
+   URI, and UDP for a SIP URI.  However, another transport protocol,
+   such as TCP, MAY be used if the guidelines of SIP mandate it for this
+   particular request.  That is the case, for example, for requests that
+   exceed the path MTU.
+
+4.2 Determining Port and IP Address
+
+   Once the transport protocol has been determined, the next step is to
+   determine the IP address and port.
+
+   If TARGET is a numeric IP address, the client uses that address.  If
+   the URI also contains a port, it uses that port.  If no port is
+   specified, it uses the default port for the particular transport
+   protocol.
+
+   If the TARGET was not a numeric IP address, but a port is present in
+   the URI, the client performs an A or AAAA record lookup of the domain
+   name.  The result will be a list of IP addresses, each of which can
+   be contacted at the specific port from the URI and transport protocol
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 8]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   determined previously.  The client SHOULD try the first record.  If
+   an attempt should fail, based on the definition of failure in Section
+   4.3, the next SHOULD be tried, and if that should fail, the next
+   SHOULD be tried, and so on.
+
+      This is a change from RFC 2543.  Previously, if the port was
+      explicit, but with a value of 5060, SRV records were used.  Now, A
+      or AAAA records will be used.
+
+   If the TARGET was not a numeric IP address, and no port was present
+   in the URI, the client performs an SRV query on the record returned
+   from the NAPTR processing of Section 4.1, if such processing was
+   performed.  If it was not, because a transport was specified
+   explicitly, the client performs an SRV query for that specific
+   transport, using the service identifier "_sips" for SIPS URIs.  For a
+   SIP URI, if the client wishes to use TLS, it also uses the service
+   identifier "_sips" for that specific transport, otherwise, it uses
+   "_sip".  If the NAPTR processing was not done because no NAPTR
+   records were found, but an SRV query for a supported transport
+   protocol was successful, those SRV records are selected. Irregardless
+   of how the SRV records were determined, the procedures of RFC 2782,
+   as described in the section titled "Usage rules" are followed,
+   augmented by the additional procedures of Section 4.3 of this
+   document.
+
+   If no SRV records were found, the client performs an A or AAAA record
+   lookup of the domain name.  The result will be a list of IP
+   addresses, each of which can be contacted using the transport
+   protocol determined previously, at the default port for that
+   transport.  Processing then proceeds as described above for an
+   explicit port once the A or AAAA records have been looked up.
+
+4.3 Details of RFC 2782 Process
+
+   RFC 2782 spells out the details of how a set of SRV records are
+   sorted and then tried.  However, it only states that the client
+   should "try to connect to the (protocol, address, service)" without
+   giving any details on what happens in the event of failure.  Those
+   details are described here for SIP.
+
+   For SIP requests, failure occurs if the transaction layer reports a
+   503 error response or a transport failure of some sort (generally,
+   due to fatal ICMP errors in UDP or connection failures in TCP).
+   Failure also occurs if the transaction layer times out without ever
+   having received any response, provisional or final (i.e., timer B or
+   timer F in RFC 3261 [1] fires).  If a failure occurs, the client
+   SHOULD create a new request, which is identical to the previous, but
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 9]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   has a different value of the Via branch ID than the previous (and
+   therefore constitutes a new SIP transaction).  That request is sent
+   to the next element in the list as specified by RFC 2782.
+
+4.4 Consideration for Stateless Proxies
+
+   The process of the previous sections is highly stateful.  When a
+   server is contacted successfully, all retransmissions of the request
+   for the transaction, as well as ACK for a non-2xx final response, and
+   CANCEL requests for that transaction, MUST go to the same server.
+
+   The identity of the successfully contacted server is a form of
+   transaction state.  This presents a challenge for stateless proxies,
+   which still need to meet the requirement for sending all requests in
+   the transaction to the same server.
+
+   The problem is similar, but different, to the problem of HTTP
+   transactions within a cookie session getting routed to different
+   servers based on DNS randomization.  There, such distribution is not
+   a problem.  Farms of servers generally have common back-end data
+   stores, where the session data is stored.  Whenever a server in the
+   farm receives an HTTP request, it takes the session identifier, if
+   present, and extracts the needed state to process the request.  A
+   request without a session identifier creates a new one.  The problem
+   with stateless proxies is at a lower layer; it is retransmitted
+   requests within a transaction that are being potentially spread
+   across servers.  Since none of these retransmissions carries a
+   "session identifier" (a complete dialog identifier in SIP terms), a
+   new dialog would be created identically at each server.  This could,
+   for example result in multiple phone calls to be made to the same
+   phone.  Therefore, it is critical to prevent such a thing from
+   happening in the first place.
+
+   The requirement is not difficult to meet in the simple case where
+   there were no failures when attempting to contact a server.  Whenever
+   the stateless proxy receives the request, it performs the appropriate
+   DNS queries as described above.  However, the procedures of RFC 2782
+   are not guaranteed to be deterministic.  This is because records that
+   contain the same priority have no specified order.  The stateless
+   proxy MUST define a deterministic order to the records in that case,
+   using any algorithm at its disposal.  One suggestion is to
+   alphabetize them, or, more generally, sort them by ASCII-compatible
+   encoding.  To make processing easier for stateless proxies, it is
+   RECOMMENDED that domain administrators make the weights of SRV
+   records with equal priority different (for example, using weights of
+   1000 and 1001 if two servers are equivalent, rather than assigning
+   both a weight of 1000), and similarly for NAPTR records.  If the
+   first server is contacted successfully, the proxy can remain
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 10]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   stateless.  However, if the first server is not contacted
+   successfully, and a subsequent server is, the proxy cannot remain
+   stateless for this transaction.  If it were stateless, a
+   retransmission could very well go to a different server if the failed
+   one recovers between retransmissions.  As such, whenever a proxy does
+   not successfully contact the first server, it SHOULD act as a
+   stateful proxy.
+
+   Unfortunately, it is still possible for a stateless proxy to deliver
+   retransmissions to different servers, even if it follows the
+   recommendations above.  This can happen if the DNS TTLs expire in the
+   middle of a transaction, and the entries had changed.  This is
+   unavoidable.  Network implementors should be aware of this
+   limitation, and not use stateless proxies that access DNS if this
+   error is deemed critical.
+
+5 Server Usage
+
+   RFC 3261 [1] defines procedures for sending responses from a server
+   back to the client.  Typically, for unicast UDP requests, the
+   response is sent back to the source IP address where the request came
+   from, using the port contained in the Via header.  For reliable
+   transport protocols, the response is sent over the connection the
+   request arrived on.  However, it is important to provide failover
+   support when the client element fails between sending the request and
+   receiving the response.
+
+   A server, according to RFC 3261 [1], will send a response on the
+   connection it arrived on (in the case of reliable transport
+   protocols), and for unreliable transport protocols, to the source
+   address of the request, and the port in the Via header field.  The
+   procedures here are invoked when a server attempts to send to that
+   location and that response fails (the specific conditions are
+   detailed in RFC 3261). "Fails" is defined as any closure of the
+   transport connection the request came in on before the response can
+   be sent, or communication of a fatal error from the transport layer.
+
+   In these cases, the server examines the value of the sent-by
+   construction in the topmost Via header.  If it contains a numeric IP
+   address, the server attempts to send the response to that address,
+   using the transport protocol from the Via header, and the port from
+   sent-by, if present, else the default for that transport protocol.
+   The transport protocol in the Via header can indicate "TLS", which
+   refers to TLS over TCP.  When this value is present, the server MUST
+   use TLS over TCP to send the response.
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 11]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   If, however, the sent-by field contained a domain name and a port
+   number, the server queries for A or AAAA records with that name.  It
+   tries to send the response to each element on the resulting list of
+   IP addresses, using the port from the Via, and the transport protocol
+   from the Via (again, a value of TLS refers to TLS over TCP).  As in
+   the client processing, the next entry in the list is tried if the one
+   before it results in a failure.
+
+   If, however, the sent-by field contained a domain name and no port,
+   the server queries for SRV records at that domain name using the
+   service identifier "_sips" if the Via transport is "TLS", "_sip"
+   otherwise, and the transport from the topmost Via header ("TLS"
+   implies that the transport protocol in the SRV query is TCP).  The
+   resulting list is sorted as described in [2], and the response is
+   sent to the topmost element on the new list described there.  If that
+   results in a failure, the next entry on the list is tried.
+
+6 Constructing SIP URIs
+
+   In many cases, an element needs to construct a SIP URI for inclusion
+   in a Contact header in a REGISTER, or in a Record-Route header in an
+   INVITE.  According to RFC 3261 [1], these URIs have to have the
+   property that they resolve to the specific element that inserted
+   them.  However, if they are constructed with just an IP address, for
+   example:
+
+   sip:1.2.3.4
+
+   then should the element fail, there is no way to route the request or
+   response through a backup.
+
+   SRV provides a way to fix this.  Instead of using an IP address, a
+   domain name that resolves to an SRV record can be used:
+
+   sip:server23.provider.com
+
+   The SRV records for a particular target can be set up so that there
+   is a single record with a low value for the priority field
+   (indicating the preferred choice), and this record points to the
+   specific element that constructed the URI.  However, there are
+   additional records with higher values of the priority field that
+   point to backup elements that would be used in the event of failure.
+   This allows the constraint of RFC 3261 [1] to be met while allowing
+   for robust operation.
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 12]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+7 Security Considerations
+
+   DNS NAPTR records are used to allow a client to discover that the
+   server supports TLS.  An attacker could potentially modify these
+   records, resulting in a client using a non-secure transport when TLS
+   is in fact available and preferred.
+
+   This is partially mitigated by the presence of the sips URI scheme,
+   which is always sent only over TLS.  An attacker cannot force a bid
+   down through deletion or modification of DNS records.  In the worst
+   case, they can prevent communication from occurring by deleting all
+   records.  A sips URI itself is generally exchanged within a secure
+   context, frequently on a business card or secure web page, or within
+   a SIP message which has already been secured with TLS.  See RFC 3261
+   [1] for details.  The sips URI is therefore preferred when security
+   is truly needed, but we allow TLS to be used for requests resolved by
+   a SIP URI to allow security that is better than no TLS at all.
+
+   The bid down attack can also be mitigated through caching.  A client
+   which frequently contacts the same domain SHOULD cache whether or not
+   its NAPTR records contain SIPS in the services field.  If such
+   records were present, but in later queries cease to appear, it is a
+   sign of a potential attack.  In this case, the client SHOULD generate
+   some kind of alert or alarm, and MAY reject the request.
+
+   An additional problem is that proxies, which are intermediaries
+   between the users of the system, are frequently the clients that
+   perform the NAPTR queries.  It is therefore possible for a proxy to
+   ignore SIPS entries even though they are present, resulting in
+   downgraded security.  There is very little that can be done to
+   prevent such attacks.  Clients are simply dependent on proxy servers
+   for call completion, and must trust that they implement the protocol
+   properly in order for security to be provided.  Falsifying DNS
+   records can be done by tampering with wire traffic (in the absence of
+   DNSSEC), whereas compromising and commandeering a proxy server
+   requires a break-in, and is seen as the considerably less likely
+   downgrade threat.
+
+8 The Transport Determination Application
+
+   This section more formally defines the NAPTR usage of this
+   specification, using the Dynamic Delegation Discovery System (DDDS)
+   framework as a guide [7].  DDDS represents the evolution of the NAPTR
+   resource record.  DDDS defines applications, which can make use of
+   the NAPTR record for specific resolution services.  This application
+   is called the Transport Determination Application, and its goal is to
+   map an incoming SIP or SIPS URI to a set of SRV records for the
+   various servers that can handle the URI.
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 13]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+   The following is the information that DDDS requests an application to
+   provide:
+
+      Application Unique String: The Application Unique String (AUS) is
+         the input to the resolution service.  For this application, it
+         is the URI to resolve.
+
+      First Well Known Rule: The first well known rule extracts a key
+         from the AUS.  For this application, the first well known rule
+         extracts the host portion of the SIP or SIPS URI.
+
+      Valid Databases: The key resulting from the first well known rule
+         is looked up in a single database, the DNS [8].
+
+      Expected Output: The result of the application is an SRV record
+         for the server to contact.
+
+9 IANA Considerations
+
+   The usage of NAPTR records described here requires well known values
+   for the service fields for each transport supported by SIP.  The
+   table of mappings from service field values to transport protocols is
+   to be maintained by IANA.  New entries in the table MAY be added
+   through the publication of standards track RFCs, as described in RFC
+   2434 [5].
+
+   The registration in the RFC MUST include the following information:
+
+      Service Field: The service field being registered.  An example for
+         a new fictitious transport protocol called NCTP might be
+         "SIP+D2N".
+
+      Protocol: The specific transport protocol associated with that
+         service field.  This MUST include the name and acronym for the
+         protocol, along with reference to a document that describes the
+         transport protocol.  For example - "New Connectionless
+         Transport Protocol (NCTP), RFC 5766".
+
+      Name and Contact Information: The name, address, email address and
+         telephone number for the person performing the registration.
+
+   The following values have been placed into the registry:
+
+   Services Field               Protocol
+   SIP+D2T                       TCP
+   SIPS+D2T                      TCP
+   SIP+D2U                       UDP
+   SIP+D2S                       SCTP (RFC 2960)
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 14]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+10 Acknowledgements
+
+   The authors would like to thank Randy Bush, Leslie Daigle, Patrik
+   Faltstrom, Jo Hornsby, Rohan Mahy, Allison Mankin, Michael Mealling,
+   Thomas Narten, and Jon Peterson for their useful comments.
+
+11 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]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+         Specifying the Location of Services (DNS SRV)", RFC 2782,
+         February 2000.
+
+   [3]   Mealling, M. and R. Daniel, "The Naming Authority Pointer
+         (NAPTR) DNS Resource Record", RFC 2915, September 2000.
+
+   [4]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+12 Informative References
+
+   [6]   Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
+         "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+   [7]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+         One: The Comprehensive DDDS Standard", Work in Progress.
+
+   [8]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+         Three: The DNS Database", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 15]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+13 Authors' Addresses
+
+   Jonathan Rosenberg
+   dynamicsoft
+   72 Eagle Rock Avenue
+   First Floor
+   East Hanover, NJ 07936
+
+   EMail: jdrosen@dynamicsoft.com
+
+
+   Henning Schulzrinne
+   Columbia University
+   M/S 0401
+   1214 Amsterdam Ave.
+   New York, NY 10027-7003
+
+   EMail: schulzrinne@cs.columbia.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 16]
+
+RFC 3263               SIP: Locating SIP Servers               June 2002
+
+
+14  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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 assigns.
+
+   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 17]
+