draft-ietf-sip-srv-02.txt   draft-ietf-sip-srv-03.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft Schulzrinne/Rosenberg Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-sip-srv-02.txt Columbia U./dynamicsoft draft-ietf-sip-srv-03.txt dynamicsoft,Columbia U.
March 24, 2001 December 24, 2001
Expires: June 2001 Expires: May 2002
SIP: Session Initiation Protocol -- Locating SIP Servers SIP: Locating SIP Servers
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes how a SIP client locates a SIP server based The Session Initiation Protocol (SIP) makes use of DNS procedures to
on the Request-URI or a preconfigured outbound proxy server. This allow a client to resolve a SIP URI into the IP address, port, and
document updates the process described in RFC 2543. transport of the next hop to contact. It also uses DNS to allow a
server to send a response to a backup client in the event of a
failure of the primary client. This document describes those DNS pro-
cedures in detail.
1 Introduction 1 Introduction
This document updates Sections 1.3 and 1.4.2 and supersedes Appendix The Session Initiation Protocol (SIP) [1] is a client-server protocol
D of RFC 2543 [1]. Inter alia, it defines the term outbound proxy and used for the initiation and management of communications sessions
replaces references to the obsoleted RFC 2052 with current references between users. SIP end systems are called user agents, and intermedi-
to RFC 2782. ate 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, UA1 wishes to call joe@B. To do so, it communi-
cates 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
1.1 Terminology 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 the SRV [2] and NAPTR [3] records. This document describes the
specific problems that SIP uses DNS to help solve, and provides a
In this document, the key words "MUST", "MUST NOT", "REQUIRED", 2 Problems DNS is Needed to Solve
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant SIP implementations.
1.2 Definitions DNS is needed to help solve several aspects of the general call flow
described in the Introduction.
Outbound proxy: A proxy that is located near the originator of First off, proxy 1 needs to discover the SIP server in domain B, in
requests. It receives all outgoing requests from a order to forward the call for joe@B. Specifically, it needs to deter-
particular UAC, including those requests whose Request-URLs mine the IP address, port and transport for the server in domain B.
identify a host other than the outbound proxy. The outbound Transport is particularly noteworthy. Unlike other protocols, SIP can
proxy sends these requests, after any local processing, to run over a variety of transports, including TCP, UDP, TLS/TCP and
the address indicated in the Request-URI. (All other proxy SCTP. Therefore, discovery of transports for a particular domain is
servers are simply referred as proxies, not inbound an important part of the processing. The proxy sending the request
proxies.) has a particular set of transports it supports (all proxies must
implement both TCP and UDP) and a preference for using those tran-
sports. Proxy 2 has its own set of transports it supports (the
minimal overlap is UDP and TCP in this case), and relative prefer-
ences for those transports. Some form of DNS procedures are needed
for proxy 1 to discover the available transports for SIP services at
domain B, and the relative preferences of those transports. This
information can be merged with the supported transports and prefer-
ences at proxy 1, resulting in a selection of a transport.
2 Locating a SIP Server It is important to note that DNS processing can be used multiple
times throughout processing of a call. In general, an element that
wishes to send a request (generally called a client) may need to per-
form DNS processing to determine the IP address, port, and transport
of a next hop element, generally called a server (it can be a proxy
or a user agent). Such processing could, in principle, occur at every
hop between elements.
When a client wishes to send a request, the client either sends it to Since SIP is used for the establishment of interactive communications
a locally configured SIP proxy server, the so-called outbound proxy , services, the time it takes to complete a transaction between a
independent of the Request-URI, or sends it to the IP address and caller and called party is important. Typically, the total delay
port corresponding to the Request-URI. The outbound proxy can be between when a user initiates the call, and when they get an indica-
configured by any mechanism, including DHCP [3] and can be specified tion that the called party is being alerted to the call, needs to be
either as a set of parameters such as network address or host name, ............................ ..............................
protocol port and transport protocol, or as a SIP URI. . . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |------------- | Proxy | .
. | 1 | . . | 2 | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
If the Request-URI is used, the client needs to determine the Figure 1: The SIP trapezoid
protocol, port and IP address of a server to which to send the
request. A client SHOULD follow the steps below to obtain this
Clients MUST re-run the above selection algorithm, re-drawing any less than a few seconds. Given that there can be multiple hops, each
random numbers involved, once per transaction rather than for each of which is doing DNS processing in addition to other potentially
request, i.e., requests within the same transaction MUST be sent to time-intensive operations, the amount of time available for DNS pro-
the same network address. Thus, the same address is used for the cessing at each hop is limited.
request, any retransmissions, any associated CANCEL requests and ACK
requests for non-2xx responses. However, ACKs for 2xx responses use
another iteration of the selection algorithm. (Indeed, in many cases,
they may have different request URIs.)
A stateless proxy can accomplish this, for example, by using the Scalability and high availability are important in SIP. SIP services
modulo N of a hash of the Call-ID value or some other combination of scale up through clustering techniques. In a more realistic version
transaction-identifying headers as the uniform random number of the network in Figure 1, proxy 2 would typically be a cluster of
described in the weighting algorithm of RFC 2782. Here, N is the sum homogeneously configured proxies. DNS needs to provide the ability
of weights within the priority class. 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
A client SHOULD be able to interpret explicit network notifications High availability is accomplished in SIP through detection of
(such as ICMP messages) which indicate that a server is not failures by upstream elements. For example, proxy 1 would send a
reachable, rather than relying solely on timeouts. (For socket-based request to proxy 2.1 (one of the proxies in the "cluster" proxy 2).
programs: For TCP, connect() returns ECONNREFUSED if the client This request would fail, and that would be detected by proxy 1. Proxy
could not connect to a server at that address. For UDP, the socket 1 would then try another of the proxies, proxy 2.2. In many cases,
needs to be bound to the destination address using connect() rather such as the one above, proxy 1 will not know which domains it will
than sendto() or similar so that a second write() or send() fails ultimately communicate with. That information would be known when a
with ECONNREFUSED if there is no server listening) If the client user actually makes a call to another user in that domain. Proxy 1
finds the server is not reachable at a particular address, it SHOULD may never communicate with that domain again after the call com-
behave as if it had received a 400-class error response to that pletes. Proxy 1 could communicate with thousands of different domains
request. 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, it is not generally possible for an ele-
ment to perpetually maintain dynamic availability state for the prox-
ies 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 thats available. The identity of the avail-
able server would ideally be cached for some amount of time in order
to reduce call setup delays of subsequent calls. However, the client
cannot actively "ping" the failed servers to determine when they come
back alive, because of scalability concerns. Furthermore, the availa-
bility state must eventually be flushed in order to redistribute load
to recovered elements when they come back online.
The client tries to find one or more addresses for the SIP server by It is possible for elements to fail in the middle of a transaction.
querying DNS. If a step elicits no addresses, the client continues to For example, after proxy 2 forwards the request to UA 2, proxy 1
the next step. However if a step elicits one or more addresses, but fails. UA 2 sends its response to proxy 2, which tries to forward it
no SIP server at any of those addresses responds, then the client to proxy 1, which is no longer available. Ideally, we would like
concludes the server is down and does not continue on to the next proxy 2 to use DNS procedures to identify a backup server for proxy 1
step. that it can use to forward the response. This problem is more realis-
tic in SIP than it is in other transactional protocols. The reason is
that a SIP response 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.
If the client is configured with the address of an outbound proxy, 3 Client Usage
the parameters of the outbound proxy, including transport protocol
and port, become the destination used below.
If there is no outbound proxy, the destination is the Request-URI. Usage of DNS differs for clients and for servers. This section
The destination address is the maddr parameter if it exists and the discusses client usage. The assumption is that the client is stateful
host element if not. The transport protocol is the transport (either a UAC or a stateful proxy). Considerations for stateless
parameter. proxies are discussed in Section 3.4.
The service identifier for DNS SRV records [4] is "_sip". The procedures here are invoked when a client needs to send a request
to a server for which it does not already know an explicit IP
address, port, and transport. This occurs when an element wishes to
send a request to a server identified by a SIP URI, or when an ele-
ment wishes to send a request to a specific configured server,
independent of the SIP URI, but the configured server is identified
by a domain name instead of a numeric IP address.
1. If the destination address is a numeric IP address, the The procedures here MUST only be done once per transaction. That is,
client contacts the server at the given address and the once a server has successfully been contacted (success is defined
port number specified in the SIP-URI or, if not specified, below), all retransmissions of the request and the ACK for non-2xx
the default port (5060). responses MUST be sent to the same server. Furthermore, a CANCEL for
a particular request MUST be sent to the same server that the request
was delivered to.
If the destination specifies a protocol, the client Note that, because the ACK request for 2xx responses constitutes a
contacts the server using that protocol. If no protocol is different transaction, there is no requirement that it be delivered
specified, the client first tries UDP. If attempt fails, or to the same server that received the original request (indeed, if
if the client does not support UDP but supports other that server did not record-route, it will most definitely not get the
protocols, it tries those protocols in some ACK).
implementation-defined order.
The client then skips the remaining steps. If the request is being delivered to an outbound proxy, a temporary
URI, used for purposes of this specification, is constructed. That
URI is of the form sip:<proxy>, where <proxy> is the domain of the
outbound proxy.
2. If the destination specifies no port number or port number The first step is to identify the TARGET. The TARGET is set to the
5060, the transport protocol determines the use of one of value of the maddr parameter of the URI, if present, otherwise, the
the following three rules: host value of the hostport construction. It represents the domain to
be contacted.
- If the destination does not specify a transport protocol, 3.1 Selecting a Transport
DNS SRV records are retrieved according to RFC 2782 [4].
The results of the query or queries are merged and
ordered based on priority, keeping only records with
transport protocols that the client supports. Then, the
searching technique outlined in RFC 2782 [4] is used to
select servers in order. Server selection across requests
is independent of previous choices, except as noted above
for stateless proxies. Message length or other request
properties do not influence the server selection. The
client attempts to contact each server in the order
listed, at the port number specified in the SRV record.
If none of the servers can be contacted, the client gives
up. If there are no SRV records (with any transport
protocol), DNS address records are used, as described
- If a transport protocol is specified and this protocol is Next, a transport is selected.
supported by the client, the procedure in the paragraph
above is used, limited to DNS resource records with the
transport protocol specified in the SIP-URI.
- If the transport protocol specified is not supported by If the URI specifies a transport, that transport MUST be used.
the client, the client gives up.
If there are no SRV records, the next step applies. Otherwise, if no transport is specified, but the TARGET is a numeric
IP address, the client SHOULD use UDP.
3. If the destination specifies a port number other than 5060 Otherwise, if no transport is specified, and the target is not a
or if there are no SRV records, the client queries the DNS numeric IP address, the client SHOULD perform a NAPTR query. This
server for address records for the destination address. query is for the service "SIP+D2T", which provides a mapping from a
Address records include A RR's, AAAA RR's, or other similar domain to a transport for contacting that domain. The transport is of
records, chosen according to the client's network protocol the form of an SRV record, using the "S" NAPTR flag. The resource
capabilities. record will contain a replacement value (not a regular expression),
which is the SRV record for a particular transport. If the server
supports multiple transports, there will be multiple NAPTR records,
each with a different order value. The client MUST discard any
records that contain an SRV value with a transport not supported by
the client, but otherwise follow the processing rules of [3]. The
result is that the most preferred transport of the server that is
supported by the client will get used.
If the DNS server returns no address records, the client As an example, consider foo.com. A client wishes to contact a SIP
gives up. If there are address records, the same rules as server in foo.com. It performs a NAPTR query for that domain, and the
in step 2 apply. following records are returned:
Clients MUST NOT cache query results except according to the rules in ;; order pref flags service regexp replacement
RFC 1035 [5]. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.foo.com
IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._udp.foo.com
IN NAPTR 110 50 "s" "SIP+D2T" "" _sip._tls.foo.com
3 Security Considerations This indicates that the server supports TCP, UDP, and TLS, in that
order of preference. If the client supports UDP and TLS, UDP will be
used, based on an SRV lookup of _sip._udp.foo.com.
The security considerations in RFC 2543 [1] apply. Somehow this doesn't seem right, since the client needs to
look at the replacement values to discard entries. Perhaps
the query should instead be done for sip.<domain>, and the
service field is "TCP+D2T" or "UDP+D2T"?
4 Authors' Addresses It is STRONGLY RECOMMENDED that the domain suffixes in the replace-
ment field (i.e., foo.com above) match the domain of the original
query. Without that, backwards compatibility between RFC 2543 and
this specification will not be possible.
Henning Schulzrinne THis is because RFC 2543 clients will go directly to SRV
Dept. of Computer Science records using the domain suffixes. If these are non-
Columbia University existent, because the NAPTR replacement used a different
1214 Amsterdam Avenue suffix, communication will not take place.
New York, NY 10027
electronic mail: schulzrinne@cs.columbia.edu
Jonathan Rosenberg In the event that no NAPTR records are found, the client constructs
dynamicsoft SRV records for those transports it supports, and does a query for
72 Eagle Rock Ave each. Queries are done using the service identifier "_sip". If the
East Hanover, NJ 07936 query is successful, it means that the particular transport is sup-
USA ported. The client MAY use any transport it desires which is sup-
electronic mail: jdrosen@dynamicsoft.com ported by the server.
5 Bibliography This is a change from RFC 2543, which used to merge the
priority values across different SRV records.
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 3.2 Determining port and IP
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement Once the transport has been determined, the next step is to determine
levels," Request for Comments 2119, Internet Engineering Task Force, the IP address and port.
Mar. 1997.
[3] G. Nair and H. Schulzrinne, "DHCP option for SIP servers," If TARGET is a numeric IP address, use that address. If the URI also
Internet Draft, Internet Engineering Task Force, Apr. 2000. Work in contains a port, use that port. If no port is specified, use the
progress. default port for the particular transport.
[4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying If the TARGET was not a numeric IP address, but a port is present in
the location of services (DNS SRV)," Request for Comments 2782, the URI, first check the cache to determine if a server has been pre-
Internet Engineering Task Force, Feb. 2000. viously contacted successfully for that TARGET and port. If one has
been, use that server. Otherwise, perform an A or AAAA record lookup
of the domain name. The result will be a list of IP address, each of
which can be contacted at the specific port from the URI and tran-
sport determined previously. Processing then proceeds as described in
Section 3.3.
[5] P. V. Mockapetris, "Domain names - implementation and There is a weird case where, where the URI had a domain
specification," Request for Comments 1035, Internet Engineering Task name and a port. SRV records will potentially be used to
Force, Nov. 1987. determine the transport, based on the algorithms above, but
A records used for the actual lookup. That seems odd.
Full Copyright Statement If the TARGET was not a numeric IP address, and no port was present
in the URI, first check the cache to see if a server had been previ-
ously contacted successfully for that TARGET. If one had been, use
that. Otherwise, perform an SRV query using the service identifier
"_sip" and the transport as determined from Section 3.1, as specified
in RFC 2782 [2]. The procedures of RFC 2782, as described in the Sec-
tion titled "Usage rules" are followed, augmented by the additional
procedures of Section 3.3.
Copyright (c) The Internet Society (2001). All Rights Reserved. This is a change. Previously, if the port was explicit, but
with a value of 5060, SRV records were used. Now, A records
will be used. A result of this is that the URL comparison
rules need to change to reflect that sip:user@foo and
sip:user@foo:5060 are NOT equivalent any longer. I think
this should not cause any serious interoperability issues,
but further consideration is needed.
This document and translations of it may be copied and furnished to 3.3 Details of 2782 process
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
The limited permissions granted above are perpetual and will not be RFC 2782 spells out the details of how a set of SRV records are
revoked by the Internet Society or its successors or assigns. 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,
in the case of SIP, are described here.
This document and the information contained herein is provided on an For SIP requests, failure occurs if the transaction layer reports a
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 503 error response or a transport failure of some sort (generally,
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING due to ICMP errors or TCP connection failures). Failure also occurs
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION if the transaction layer times out without ever having received ANY
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF response, provisional or final (i.e., timer B or timer F fires). If a
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. failure occurs, the client SHOULD create a new request, which is
identical to the previous, but 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 rfc2782.
A server has been contacted "successfully" if a request sent to that
server generates any kind of response, provisional or final. A map-
ping of the tuple (TARGET, input TRANSPORT, input PORT) to a specific
server (IP address, transport, port) that was contacted successfully
SHOULD be cached for a duration equal to the TTL of the A record for
that server itself. Note, in the above tuple, input TRANSPORT and
input PORT refer to the transport and port values from the URI
itself, if present.
If a client attempts to contact the server listed in the cache, but
the request fails, the server MUST be removed from the cache, and the
entire DNS processing must restart by following the procedures in
Section 3.1 again.
3.4 Consideration for Stateless Proxies
The process of the previous sections is highly stateful. When a
server is contacted successfully, all requests for the transaction
(plus a CANCEL for that transaction) MUST go to the same server. The
identity of the successfully contacted server is a form of transac-
tion state. This presents a challenge for stateless proxies, which
still need to meet the requiretment for sending all requests in the
transaction to the same server.
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. Unfortunately, the procedures of RFC
2782 and RFC 2915 are not guaranteed to be deterministic. This is
because records that contain the same priority and weight (in the
case of SRV) or order and preference (in the case of NAPTR) have no
specified order. The stateless proxy MUST define a deterministic
order to the records in that case, using any algorithm at its dispo-
sal. One suggestion is to alphabetize them, for example. To make life
easier for stateless proxies, it is RECOMMENDED that domain adminis-
trators 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 simi-
larly for NAPTR records. If the first server is contacted success-
fully, things are fine. However, if the first server is not contacted
successfully, and a subsequent server is, the proxy cannot remain
stateless for this transaction. This is because a retransmission
could very well go to a different server if the failed one recovers
between retransmissions. As such, whenever a proxy does not success-
fully contact the first server, it SHOULD act as a stateful proxy.
4 Server Usage
RFC 2543bis defines procedures for sending responses from a server
back to the client. Typically, for unicast requests, the response is
sent back to the source IP address where the request came from, using
the port contained in the Via header. However, it is important to
provide failover support when the client element fails between send-
ing the request and receiving the response.
The procedures here are invoked when a server sends a response to the
client and that response fails. "Fails" is defined here as any
response which causes an ICMP error message to be returned, or when
the transport connection the request came in on closes before the
response can be sent.
In these cases, the server examines the value of the sent-by con-
struction 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 from the Via header, and the port from sent-by,
if present, else the default for that transport.
If, however, the sent-by field contained a domain name and a port
number, the server queries for A 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 from the
Via. As in the client processing, the next entry in the list is tred
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 using the service identifier
"_sip" and the transport from the topmost Via header. 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.
5 Security Considerations
The authors do not believe that this specification introduces any
additional security issues beyond those already described in RFC 2782
and RFC 2915.
6 Registration of NATPR D2T Resolution Service
Name: Domain Name to Transport
* Mnemonic: D2T
* Number of Operands: 1
* Type of Each Operand: Each operand is a domain
* Format of Each Operand: Each operand is a domain name in standard
* Algorithm: Opaque
* Output: One or more SRV record keys
* Error Conditions:
o No overlap in transport between client and server
* Security Considerations:
7 Author's Addresses
Jonathan Rosenberg
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
8 Bibliography
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Oct.
2001. Work in progress.
[2] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," Request for Comments 2782,
Internet Engineering Task Force, Feb. 2000.
[3] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR)
DNS resource record," Request for Comments 2915, Internet Engineering
Task Force, Sept. 2000.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/