draft-ietf-sip-sctp-05.txt   draft-ietf-sip-sctp-06.txt 
SIP J. Rosenberg SIP J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: May 25, 2005 H. Schulzrinne Expires: July 14, 2005 H. Schulzrinne
Columbia University Columbia University
G. Camarillo G. Camarillo
Ericsson Ericsson
November 24, 2004 January 13, 2005
The Stream Control Transmission Protocol (SCTP) as a Transport for The Stream Control Transmission Protocol (SCTP) as a Transport for
the Session Initiation Protocol (SIP) the Session Initiation Protocol (SIP)
draft-ietf-sip-sctp-05.txt draft-ietf-sip-sctp-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 25, 2005. This Internet-Draft will expire on July 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies a mechanism for usage of SCTP (the Stream This document specifies a mechanism for usage of SCTP (the Stream
Control Transmission Protocol) as the transport between SIP (Session Control Transmission Protocol) as the transport between SIP (Session
Initiation Protocol) entities. SCTP is a new protocol which provides Initiation Protocol) entities. SCTP is a new protocol which provides
several features that may prove beneficial for transport between SIP several features that may prove beneficial for transport between SIP
entities which exchange a large amount of messages, including entities which exchange a large amount of messages, including
gateways and proxies. As SIP is transport independent, support of gateways and proxies. As SIP is transport independent, support of
SCTP is a relatively straightforward process, nearly identical to SCTP is a relatively straightforward process, nearly identical to
support for TCP. support for TCP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Potential Benefits . . . . . . . . . . . . . . . . . . . . . . 3 3. Potential Benefits . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Advantages over UDP . . . . . . . . . . . . . . . . . . . 3 3.1 Advantages over UDP . . . . . . . . . . . . . . . . . . . 3
3.2 Advantages over TCP . . . . . . . . . . . . . . . . . . . 4 3.2 Advantages over TCP . . . . . . . . . . . . . . . . . . . 4
4. Usage of SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Transport Parameters . . . . . . . . . . . . . . . . . . . . . 5
4.1 Mapping of SIP Transactions into SCTP Streams . . . . . . 6 5. SCTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Locating a SIP Server . . . . . . . . . . . . . . . . . . . . 7 5.1 Mapping of SIP Transactions into SCTP Streams . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Locating a SIP Server . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2 Informative References . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 9.2 Informative References . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
1. Introduction 1. Introduction
The Stream Control Transmission Protocol (SCTP) [3] has been designed The Stream Control Transmission Protocol (SCTP) [4] has been designed
as a new transport protocol for the Internet (or intranets), at the as a new transport protocol for the Internet (or intranets), at the
same layer as TCP and UDP. SCTP has been designed with the transport same layer as TCP and UDP. SCTP has been designed with the transport
of legacy SS7 signaling messages in mind. We have observed that many of legacy SS7 signaling messages in mind. We have observed that many
of the features designed to support transport of such signaling are of the features designed to support transport of such signaling are
also useful for the transport of SIP (the Session Initiation also useful for the transport of SIP (the Session Initiation
Protocol) [4], which is used to initiate and manage interactive Protocol) [5], which is used to initiate and manage interactive
sessions on the Internet. sessions on the Internet.
SIP itself is transport-independent, and can run over any reliable or SIP itself is transport-independent, and can run over any reliable or
unreliable message or stream transport. However, procedures are only unreliable message or stream transport. However, procedures are only
defined for transport over UDP and TCP. This document defines defined for transport over UDP and TCP. This document defines
transport of SIP over SCTP. transport of SIP over SCTP.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Potential Benefits 3. Potential Benefits
Coene et. al. present some of the key benefits of SCTP [7]. We Coene et. al. present some of the key benefits of SCTP [10]. We
summarize some of these benefits here and analyze how they relate to summarize some of these benefits here and analyze how they relate to
SIP (a more detailed analysis can be found in [9]). SIP (a more detailed analysis can be found in [12]).
3.1 Advantages over UDP 3.1 Advantages over UDP
All the advantages that SCTP has over UDP regarding SIP transport are All the advantages that SCTP has over UDP regarding SIP transport are
also shared by TCP. Below there is a list of the general advantages also shared by TCP. Below there is a list of the general advantages
that a connection-oriented transport protocol such as TCP or SCTP has that a connection-oriented transport protocol such as TCP or SCTP has
over a connection-less transport protocol such as UDP. over a connection-less transport protocol such as UDP.
Fast Retransmit: SCTP can quickly determine the loss of a packet, as Fast Retransmit: SCTP can quickly determine the loss of a packet, as
a result of its usage of SACK and a mechanism which sends SACK a result of its usage of SACK and a mechanism which sends SACK
skipping to change at page 5, line 21 skipping to change at page 5, line 21
Multihoming: An SCTP connection can be associated with multiple IP Multihoming: An SCTP connection can be associated with multiple IP
addresses on the same host. Data is always sent over one of the addresses on the same host. Data is always sent over one of the
addresses, but should it become unreachable, data sent to one can addresses, but should it become unreachable, data sent to one can
migrate to a different address. This improves fault tolerance; migrate to a different address. This improves fault tolerance;
network failures making one interface of the server unavailable do network failures making one interface of the server unavailable do
not prevent the service from continuing to operate. SIP servers not prevent the service from continuing to operate. SIP servers
are likely to have substantial fault tolerance requirements. It are likely to have substantial fault tolerance requirements. It
is worth noting that because SIP is message oriented, and not is worth noting that because SIP is message oriented, and not
stream oriented, the existing SRV (Service Selection) procedures stream oriented, the existing SRV (Service Selection) procedures
defined in [4] can accomplish the same goal, even when SIP is run defined in [5] can accomplish the same goal, even when SIP is run
over TCP. In fact, SRV records allow the 'connection' to fail over TCP. In fact, SRV records allow the 'connection' to fail
over to a separate host. Since SIP proxies can run statelessly, over to a separate host. Since SIP proxies can run statelessly,
failover can be accomplished without data synchronization between failover can be accomplished without data synchronization between
the primary and its backups. Thus, the multihoming capabilities the primary and its backups. Thus, the multihoming capabilities
of SCTP provide marginal benefits. of SCTP provide marginal benefits.
It is important to note that most of the benefits of SCTP for SIP It is important to note that most of the benefits of SCTP for SIP
occur under loss conditions. Therefore, under a zero loss condition, occur under loss conditions. Therefore, under a zero loss condition,
SCTP transport of SIP should perform on par with TCP transport. SCTP transport of SIP should perform on par with TCP transport.
Research is needed to evaluate under what loss conditions the Research is needed to evaluate under what loss conditions the
improvements in setup times and throughput will be observed. improvements in setup times and throughput will be observed.
4. Usage of SCTP 4. Transport Parameters
Usage of SCTP requires no additional headers or syntax in SIP. Below A SIP URIs can carry a transport parameter indicating the transport
we show an example of a SIP URL with a transport parameter and an protocol to be used. RFC 3261 defines the value "sctp" for SCTP but
example of a Via header field. In both examples SCTP is the does not define the value for the transport parameter for TLS over
transport protocol. SCTP. Note that the value "tls", defined by RFC 3261, is intended
for TLS over TCP.
Here we define the value "tls-sctp" for the SIP URI transport
parameter to be used for messages to be sent over TLS over SCTP [8].
The updated augmented BNF (Backus-Naur Form) [2] for this parameter
is the following (the original BNF for this parameter can be found in
RFC 3261):
transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls" / "tls-sctp"
/ other-transport)
The following are examples of SIP URIs using "sctp" and "tls-sctp" in
their transport parameters:
sip:Bob.Johnson@example.com;transport=sctp sip:Bob.Johnson@example.com;transport=sctp
sip:Bob.Johnson@example.com;transport=tls-sctp
Via header fields also carry a transport protocol identifier. RFC
3261 defines the value "SCTP" for SCTP but does not define the value
for the transport parameter for TLS over SCTP. Note that the value
"TLS", defined by RFC 3261, is intended for TLS over TCP.
Here we define the value "TLS-SCTP" for the transport part of the Via
header field to be used for requests sent over TLS over SCTP [8].
The updated augmented BNF (Backus-Naur Form) [2] for this parameter
is the following (the original BNF for this parameter can be found in
RFC 3261):
transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
/ other-transport
The following are examples of Via header fields using "SCTP" and
"TLS-SCTP":
Via: SIP/2.0/SCTP ws1234.example.com:5060 Via: SIP/2.0/SCTP ws1234.example.com:5060
Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060
5. SCTP Usage
Rules for sending a request over SCTP are identical to TCP. The only Rules for sending a request over SCTP are identical to TCP. The only
difference is that an SCTP sender has to choose a particular stream difference is that an SCTP sender has to choose a particular stream
within an association in order to send the request (see Section 4.1). within an association in order to send the request (see Section 5.1).
Note that no SCTP identifier needs to be defined for SIP messages. Note that no SCTP identifier needs to be defined for SIP messages.
Therefore, the Payload Protocol Indentifier in SCTP DATA chunks Therefore, the Payload Protocol Indentifier in SCTP DATA chunks
transporting SIP messages MUST be set to zero. transporting SIP messages MUST be set to zero.
The SIP transport layers of both peers are responsible for managing The SIP transport layers of both peers are responsible for managing
the persistent SCTP connection between them. On the sender side the the persistent SCTP connection between them. On the sender side the
core or a client (or server) transaction generates a request (or core or a client (or server) transaction generates a request (or
response) and passes it to the transport layer. The transport sends response) and passes it to the transport layer. The transport sends
the request to the peer's transaction layer. The peer's transaction the request to the peer's transaction layer. The peer's transaction
layer is responsible for delivering the incoming request (or layer is responsible for delivering the incoming request (or
response) to the proper existing server (or client) transaction. If response) to the proper existing server (or client) transaction. If
no server (or client) transaction exists for the incoming message the no server (or client) transaction exists for the incoming message the
transport layer passes the request (or response) to the core, which transport layer passes the request (or response) to the core, which
may decide to construct a new server (or client) transaction. may decide to construct a new server (or client) transaction.
4.1 Mapping of SIP Transactions into SCTP Streams 5.1 Mapping of SIP Transactions into SCTP Streams
SIP transactions need to be mapped into SCTP streams in a way that SIP transactions need to be mapped into SCTP streams in a way that
avoids Head Of the Line (HOL) blocking. Among all the different ways avoids Head Of the Line (HOL) blocking. Among all the different ways
of performing this mapping that fulfil this requirement, we have of performing this mapping that fulfil this requirement, we have
chosen the simplest one; a SIP entity SHOULD send every SIP message chosen the simplest one; a SIP entity SHOULD send every SIP message
(request or response) over stream zero with the unordered flag set. (request or response) over stream zero with the unordered flag set.
On the receiving side, a SIP entity MUST be ready to receive SIP On the receiving side, a SIP entity MUST be ready to receive SIP
messages over any stream. messages over any stream.
In the past, it was proposed to use SCTP stream IDs as lightweight In the past, it was proposed to use SCTP stream IDs as lightweight
SIP transaction identifiers. That proposal was withdrawn because SIP transaction identifiers. That proposal was withdrawn because
SIP now provides (as defined in RFC 3261 [4]) a transaction SIP now provides (as defined in RFC 3261 [5]) a transaction
identifier in the branch parameter of the Via entries. This identifier in the branch parameter of the Via entries. This
transaction identifier, missing in the previous SIP spec [8], transaction identifier, missing in the previous SIP spec [9],
makes it unnecessary to use the SCTP stream IDs to demultiplex SIP makes it unnecessary to use the SCTP stream IDs to demultiplex SIP
traffic. traffic.
SIP has many circumstances in which the use of TLS [2] is required, SIP has many circumstances in which the use of TLS [3] is required,
for instance, for routing a SIPS URI [4]. As defined in RFC 3436 for instance, for routing a SIPS URI [5]. As defined in RFC 3436
[6], TLS running over SCTP MUST NOT use the SCTP unordered delivery [8], TLS running over SCTP MUST NOT use the SCTP unordered delivery
service. Moreover, any SIP use of an extra layer between the service. Moreover, any SIP use of an extra layer between the
transport layer and SIP that requires ordered delivery of messages transport layer and SIP that requires ordered delivery of messages
MUST NOT use the SCTP unordered delivery service. MUST NOT use the SCTP unordered delivery service.
SIP applications that require ordered delivery of messages from the SIP applications that require ordered delivery of messages from the
transport layer (e.g., TLS) SHOULD send SIP messages belonging to the transport layer (e.g., TLS) SHOULD send SIP messages belonging to the
same SIP transaction over the same SCTP stream. Additionally, they same SIP transaction over the same SCTP stream. Additionally, they
SHOULD send messages belonging to different SIP transactions over SHOULD send messages belonging to different SIP transactions over
different SCTP streams, as long as there are enough available different SCTP streams, as long as there are enough available
streams. streams.
skipping to change at page 7, line 13 skipping to change at page 8, line 5
established within one SCTP association. established within one SCTP association.
Note that if both sides of the association follow this Note that if both sides of the association follow this
recommendation, when a request arrives over a particular stream, the recommendation, when a request arrives over a particular stream, the
server is free to return responses over a different stream. This server is free to return responses over a different stream. This
way, both sides manage the available streams in the sending way, both sides manage the available streams in the sending
direction, independently of the streams chosen by the other side to direction, independently of the streams chosen by the other side to
send a particular SIP message. This avoids undesirable collisions send a particular SIP message. This avoids undesirable collisions
when seizing a particular stream. when seizing a particular stream.
5. Locating a SIP Server 6. Locating a SIP Server
The primary issue when sending a request is determining whether the The primary issue when sending a request is determining whether the
next hop server supports SCTP, so that an association can be opened. next hop server supports SCTP, so that an association can be opened.
SIP entities follow normal SIP procedures to discover [5] a server SIP entities follow normal SIP procedures to discover [6] a server
that supports SCTP. that supports SCTP.
6. Security Considerations However, in order to be able to use TLS on top of SCTP, an extra
definition is needed. RFC 3263 defines the NAPTR (Naming Authority
Pointer) [7] service value "SIP+D2S" for SCTP but fails to define a
value for TLS over SCTP. Here we define the NAPTR service value
"SIPS+D2S" for servers that support TLS over SCTP [8].
The security issues raised in RFC 3261 [4] are not worsened by SCTP, 7. Security Considerations
provided the advice in Section 4.1 is followed and SCTP over TLS [6]
is used where TLS would be required in RFC 3261 [4]. So, the
mechanisms described in RFC 3436 [6] MUST be used when SIP runs on
top of TLS [2] and SCTP.
7. IANA Considerations The security issues raised in RFC 3261 [5] are not worsened by SCTP,
provided the advice in Section 5.1 is followed and TLS over SCTP [8]
is used where TLS would be required in RFC 3261 [5] or in RFC 3263
[6]. So, the mechanisms described in RFC 3436 [8] MUST be used when
SIP runs on top of TLS [3] and SCTP.
This document has no IANA considerations. 8. IANA Considerations
8. References This document defines a new value (tls-sctp) for the SIP and SIPS URI
transport parameter. The IANA is requested to add a reference to
this document to the entry of the transport parameter in the
"SIP/SIPS URI Parameters" subregistry, which is located under the
"Session Initiation Protocol (SIP) Parameters" registry. The
reference should appear in double-brackets, as indicated in RFC 3969
[11]. The resulting entry should be:
8.1 Normative References Parameter Name Predefined Values Reference
-------------- ----------------- ---------
transport Yes [RFC3261] [[RFCXXXX]]
This document also defines a new NAPTR service field value
(SIPS+D2S). The IANA is requested to register this value under the
"Registry for the SIP SRV Resource Record Services Field". The
resulting entry should be:
Services Field Protocol Reference
-------------------- -------- ---------
SIPS+D2S SCTP [RFCXXXX]
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
[3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, October
2002.
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
8.2 Informative References 9.2 Informative References
[7] Coene, L., "Stream Control Transmission Protocol Applicability [9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[10] Coene, L., "Stream Control Transmission Protocol Applicability
Statement", RFC 3257, April 2002. Statement", RFC 3257, April 2002.
[8] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, [11] Camarillo, G., "The Internet Assigned Number Authority (IANA)
"SIP: Session Initiation Protocol", RFC 2543, March 1999. Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December
2004.
[9] Camarillo, G., Schulrinne, H. and R. Kantola, "Evaluation of [12] Camarillo, G., Schulrinne, H. and R. Kantola, "Evaluation of
Transport Protocols for the Session Initiation Protocol", IEEE Transport Protocols for the Session Initiation Protocol", IEEE
Network vol. 17, no. 5, 2003. Network vol. 17, no. 5, 2003.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
skipping to change at page 9, line 41 skipping to change at page 11, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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