Network Working Group R. Stewart Internet-Draft P. Lei Expires: February 27, 2006 Cisco Systems, Inc. M. Tuexen Muenster Univ. of Applied Sciences August 26, 2005 Stream Control Transmission Protocol (SCTP) Stream Reset draft-stewart-sctpstrrst-00.txt Status of this Memo By submitting this Internet-Draft, each 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Many applications that desire to use SCTP have requested the ability to "reset" a stream. The intention of resetting a stream is to start the numbering sequence of the stream back at 'zero' with a corresponding notification to the upper layer that this act as been performed. The applications that have requested this feature normally desire it so that they can "re-use" streams for different Stewart, et al. Expires February 27, 2006 [Page 1] Internet-Draft SCTP Stream Reset August 2005 purposes but still utilize the stream sequence number for the application to track the message flows. Thus, without this feature, a new use on an old stream would result in message numbers larger than expected without a protocol mechanism to "start the streams back at zero". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. STREAM RESET Chunk . . . . . . . . . . . . . . . . . . . . 3 3.2. New Parameters . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Stream Reset Request Parameter . . . . . . . . . . . . 4 3.2.2. Stream Reset Response Parameter . . . . . . . . . . . 5 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Sender side procedures for the Stream Reset Chunk . . . . 7 4.1.1. Sender side procedures for a user requested Stream Reset Request Parameter . . . . . . . . . . . . . . . 7 4.1.2. Sender side procedures for a peer requested Stream Reset Request Parameter . . . . . . . . . . . . . . . 8 4.1.3. Sender side procedures for the Stream Reset Response Parameter . . . . . . . . . . . . . . . . . . 8 4.2. Receiver side procedures for the Stream Reset Chunk . . . 9 4.2.1. Receiver side procedures for the Stream Reset Request Parameter . . . . . . . . . . . . . . . . . . 9 4.2.2. Receiver side procedures for the Stream Reset Response Parameter . . . . . . . . . . . . . . . . . . 10 4.3. Various Examples of the Stream Reset procedures . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Stewart, et al. Expires February 27, 2006 [Page 2] Internet-Draft SCTP Stream Reset August 2005 1. Introduction Many applications that desire to use RFC2960 [5] have requested the ability to "reset" a stream. The intention of resetting a stream is to start the numbering sequence of the stream back at 'zero' with a corresponding notification to the upper layer that this act as been performed. The applications that have requested this feature normally desire it so that they can "re-use" streams for different purposes but still utilize the stream sequence number for the application to track the message flows. Thus, without this feature, a new use on an old stream would result in message numbers larger than expected without a protocol mechanism to "start the streams back at zero". [ Editors note: We probably need to add more text here ] 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [4]. 3. Data Formats This section examines all new data formats defined by this document. All transported integer numbers are in "network byte order" a.k.a., Big Endian, unless otherwise noted. 3.1. STREAM RESET Chunk This document adds one new chunk type to SCTP. The suggested value for this chunk is 0x82 hex or 130 decimal. The range selected by IANA must have the upper bit (or ignore big) set and the next to highest bit (or the report bit) cleared. The chunk has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x82 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Reset Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart, et al. Expires February 27, 2006 [Page 3] Internet-Draft SCTP Stream Reset August 2005 Chunk Type This field holds the IANA defined chunk type for the STREAM RESET chunk. Chunk Flags This field is set to 0 by the sender and ignored by the receiver. Chunk Length This field holds the length of the chunk, including the Chunk Type, Chunk Flags and Chunk Length. Stream Reset Parameter This field holds exactly one and only one Stream Reset Request Parameter or Stream Reset Response Parameter. Note each STREAM RESET chunk holds one and only one parameter. A STREAM RESET chunk MUST NOT have multiple parameters contained within it. This rule is made to simplify stream reset processing. Note also that a sender may only have two STREAM RESET chunks in flight at any one single time. One being a STREAM RESET holding a request parameter, and optionally a second being a STREAM RESET holding a response parameter. 3.2. New Parameters This section identifies two new parameters, their formats, and in what chunk type these parameters may appear. 3.2.1. Stream Reset Request Parameter This parameter is used by the sender to request a stream, a list of streams or all streams to be reset. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 0x000d | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |R|Y| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Reset Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Number 1 (optional) | Stream Number 2 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ...... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Number N-1 (optional) | Stream Number N (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart, et al. Expires February 27, 2006 [Page 4] Internet-Draft SCTP Stream Reset August 2005 Parameter Type - This field holds the IANA defined parameter type for Stream Reset Request Parameter. The suggested value of this field for IANA is 0x000d. Parameter Length - This field holds the length of the parameter. Y bit - The 'Y' Bit, when set to '1' indicates that the receiver is requested to reset the stream sequence numbers it is sending. If the 'Y' bit is '0' then this message requests no action on the receivers sending stream sequence numbers. R bit - The 'R' bit, if set to '1', requests that the receiver send a stream reset request to the sender, asking to reset its sending stream sequence numbers. If the 'R' bit is clear, then no reciprocal reset request is asked for. Stream Reset Sequence Number - This field(s) hold a 32 bit unsigned integer. The value is a monotonically increasing number that is initialized to the same value as the Initial TSN number. Stream Number N - This optional field, if included, is used to indicates specific streams that are to be reset. If no streams are listed, then ALL streams are to be reset. Parameter Appearance - This parameter can appear in a STREAM RESET chunk. This parameter MUST NOT appear in any other chunk type. Note also that only ONE Stream Reset Parameter SHOULD appear in any single Stream Reset Chunk. However a sender MAY place a 'Stream Reset Parameter' and a 'Stream Reset Response Parameter' in separate STREAM RESET chunks, bundled together in one packet. 3.2.2. Stream Reset Response Parameter This parameter is used by the receiver of a stream reset request parameter to respond to the stream reset request. Stewart, et al. Expires February 27, 2006 [Page 5] Internet-Draft SCTP Stream Reset August 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 0x000e | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |D|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Reset Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Unassigned TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative Acknowledgment Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Number 1 (optional) | Stream Number 2 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ...... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Number N-1 (optional) | Stream Number N (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter Type - This field holds the IANA defined parameter type for Stream Reset Response Parameter. The suggested value of this field for IANA is 0x000e. Parameter Type Length - This field holds the length of the parameter. P bit - The 'P' Bit, when set to '1', indicates that the sender of the stream reset request has performed the stream reset that was requested. D bit - The 'D' bit, if set to '1', indicates that the stream reset that was requested is denied. - These two bits are mutually exclusive. A response parameter MUST have only one of these two bits set and MUST NOT have both of these two bits set. Note that both bits MAY be set to 0. Stream Reset Sequence Number This field(s) hold a 32 bit unsigned integer. The value is copied from the Stream Reset Request parameter and is used by the receiver to tie the request to the response. Next Unassigned TSN This value holds the NEXT TSN that the sender will assign for a new data chunk. This value is sometimes called SND.NXT. Stewart, et al. Expires February 27, 2006 [Page 6] Internet-Draft SCTP Stream Reset August 2005 Cumulative Acknowledgement Point This value holds the cumulative TSN that the sender has acknowledged. In other words, this value is the same one that will be placed in the next outgoing SACK. Stream Number N These fields are filled with the stream numbers that were RESET. If no stream numbers are listed ALL streams were reset. Parameter Appearance This parameter can appear in a STREAM RESET chunk. This parameter MUST NOT appear in any other chunk type. 4. Procedures This section defines the procedures used by both the sender and receiver of a stream reset. We also give various example stream reset scenarios. 4.1. Sender side procedures for the Stream Reset Chunk This section describes the procedures related to the sending of Stream Reset Chunks. A Stream Reset Chunk is a composition of a Tag Length Value (TLV) parameters. A single Stream Reset Chunk normally carries either a 'Stream Reset Request Parameter', or a 'Stream Reset Response Parameter'. 4.1.1. Sender side procedures for a user requested Stream Reset Request Parameter On occasion an SCTP sender will request a reset for all of its streams, a list of streams, or a single stream by its upper layer. When such a request is made the SCTP sender MUST determine if the request is: A1) To be made to the local sender side streams (in other words, the outgoing streams sequence numbers of the sender of this message). In such a case the R bit MUST be set to '1' and the Y bit MUST be set to '0' in the outgoing Stream Reset Request. A2) To be made to the peer's sender side streams (i.e. the incoming stream sequence numbers of the sender of this message). In such a case the sender MUST set the R bit to '0' and set the Y bit to '1' in the outgoing Stream Reset Request. A3) To be made to both the local and the remote peer streams sequence numbers. In such a case the sender MUST set the R bit AND the Y bit to '1'. Stewart, et al. Expires February 27, 2006 [Page 7] Internet-Draft SCTP Stream Reset August 2005 Next the sender should assign the next stream reset sequence number. After assigning the sequence number to the Stream Reset Request the number MUST be incremented by '1'. Finally if a list of streams is provided these should be appended to the Stream Reset Request. Once the parameter is assembled it MUST be placed inside a Stream Reset Chunk. One and only one Stream Reset Request SHOULD be placed in a Stream Reset Chunk. A sender MUST NOT place more than one Stream Reset Request Parameter into a Stream Reset Chunk and a sender MUST NOT have more than one Stream Reset Request outstanding at any one time. Note that if the sender has a Stream Reset Response it MAY be included in a separate outgoing Stream Reset Chunk. After packaging the Stream Reset Chunk and sending it to the peer the sender MUST start a 'Stream Reset Timer'. This timer MUST use the same value as SCTP's Data transmission timer (i.e. the RTO timer) and MUST use exponential backoff doubling the value at every expiration. If the timer does expire, besides doubling the value, the sender MUST retransmit the Stream Reset Chunk, increment the appropriate error counts (both for the association and the destination), and do threshold management possibly destroying the association if SCTP retransmission thresholds are surpassed. 4.1.2. Sender side procedures for a peer requested Stream Reset Request Parameter When a Stream Reset Request Parameter arrives from a peer and has the 'R' bit set to 1, a automatic Stream Reset Request MUST be generated if the response to the request will have the P bit set to 1. In such a case the sender MUST compose the Stream Reset Request Parameter in the following way: B1) The R bit MUST be set to '0'. B3) The Y bit MUST be set to '1'. B4) The list of streams MUST be copied from the incoming Stream Reset Request that is causing this request to be generated if one is attached. B5) An outgoing stream reset sequence number must be assigned using the same method as described previously in Section 4.1.1. 4.1.3. Sender side procedures for the Stream Reset Response Parameter When an implementation receives a Stream Reset Request it MUST respond with a Stream Reset Response in the following manner: Stewart, et al. Expires February 27, 2006 [Page 8] Internet-Draft SCTP Stream Reset August 2005 C1) The implementation MUST set either the P bit or the D bit to '1'. The P bit MUST only be set if the operation was performed. The D bit MUST only be set if the operation is refused. If no operation was requested (the Y bit was set to 0) then both the P and D bit MUST be set to 0. C2) If the P bit is set to 1 and the R bit was set on the incoming request, a stream reset request must be generated as defined in Section 4.1.2. C3) The Stream Sequence number is copied from the Stream Sequence field of the incoming request. C4) The Next Unassigned TSN MUST be set to the next TSN that will be assigned. Note this is NOT necessarily the next TSN that will be transmitted. C5) The Cumulative Acknowledgment Point MUST be set to the same value that would be placed in any outgoing SACK. C6) Any Stream Number's MUST be copied from the Stream Reset Request Parameter to the outgoing Stream Reset Response. [Editors note: The above may be redundant with the next section and we may want to remove it, I am not sure and must reread this carefully since it is tricky to get the synchronization right and this may be why things appear to be double listed. ] 4.2. Receiver side procedures for the Stream Reset Chunk Upon reception of a Stream Reset Chunk each parameter within it should be processed as described in the following sections. 4.2.1. Receiver side procedures for the Stream Reset Request Parameter When a Stream Reset Request arrives the receiver MUST always respond with a stream reset response. Its response MUST either indicate that the operation was performed with the P bit set to '1' and the D bit set to '0', that the operation was denied with the D bit set to '1' and the P bit set to '0', or that no operation was performed (The Y bit in the request was '0') by setting the P and D bit to '0'. The decision to deny a stream reset request is an administrative decision and may be user configurable even after the association has formed. If for whatever reason the endpoint does NOT wish to reset any streams it MUST send a stream reset response as described in Section 4.1.3 setting the D bit to '1' and take no further action. Stewart, et al. Expires February 27, 2006 [Page 9] Internet-Draft SCTP Stream Reset August 2005 In the case that the endpoint is willing to perform a stream reset the following steps SHOULD be followed after sending a stream reset response. Note that if the Y bit is set to '0' in the request then the response SHOULD have both P and D bit set to '0'. If the Y bit is set to '1' then the P bit MUST be set to '1'. D1) If the R bit is set, a stream reset request MUST be formulated as described in Section 4.1.2 and sent to the peer. This request SHOULD be held and sent with the Stream Reset Response generated by processing the incoming request. D2) If the Y bit is set to 0 no action is performed on the local streams and processing of this parameter is complete (no further steps are taken). D3) If no stream number are listed in the parameter, then all outgoing streams MUST be reset to '0'. If specific stream number are listed, then only these specific streams MUST be reset to '0' and all other non-listed streams remain unchanged. 4.2.2. Receiver side procedures for the Stream Reset Response Parameter On receipt of a Stream Reset Response Parameter the following MUST be performed: E1) Compare the Stream Reset Sequence Number to the sending stream reset sequence number. If the sequence numbers DO NOT match silently discard this response. If the sequence numbers DO match, increment the sending stream reset sequence number by 1 and continue processing this response with steps E2 - E4. E2) Stop the Stream Reset Timer, if one is running. E3) Examine the Next Unassigned TSN number. If the next unassigned TSN number is one greater than the Cumulative Ack point that the local endpoint is sending to the peer then all TSN's in flight are accounted for. Perform the following steps: E3.1) If no streams are listed in the incoming parameter then reset all incoming stream sequence numbers to next expect stream sequence '0'. E3.2) If the specific streams are listed in the incoming parameter then for each stream listed in the Stream Number fields, reset the next expected incoming stream number to 0. Stewart, et al. Expires February 27, 2006 [Page 10] Internet-Draft SCTP Stream Reset August 2005 E3.3) Optionally an Upper Layer Notification SHOULD be sent to inform the local endpoint that the streams have been reset. E3.4) When all streams effected have been reset the processing for this parameter is complete. E4) If the Next Unassigned TSN number is greater than the cumulative acknowledgment point by 1, then the endpoint must enter "deferred reset processing". In this mode, any TSN number for the effected streams MUST be queued locally and held until the Cumulative Acknowledgment point reaches one less then the 'Next Unassigned TSN number'. When the Cumulative Acknowledgment point reaches 1 less than the Next Unassigned TSN number then steps E3.1 - E3.3 MUST be followed. After which all queued chunks should be de- queued and processed in the normal manner. Note that the effect of deferred reset processing is that each receiving side will synchronize its expected stream sequence numbers at the precise time that the peer reset its sending sequence numbers. This allows the receiver to always stay in correct sequence with its peer's stream sequence numbers. 4.3. Various Examples of the Stream Reset procedures The following examples illustrates an Endpoint A resetting all streams in both directions. E-A E-Z -------[STR_RESET(REQ:Y=1,R=1)]-------------------> <---[STR_RESET (RESP:P=1,D=0)STR_RESET(REQ:Y=1,R=0)]- -------[STR_RESET(RESP:P=1,D=0)]--------------------------> The following example illustrates an Endpoint A resetting stream 1 and 2 for just its outgoing streams. E-A E-Z -------[STR_RESET(REQ:Y=0,R=1)1,2]------------------> <-[STR_RESET({RESP:P=0,D=0}1,2)STR_RESET({REQ:Y=1,R=0}1,2)]-- ------[STR_RESET(RESP:P=1,D=0)1,2]---------------------> Stewart, et al. Expires February 27, 2006 [Page 11] Internet-Draft SCTP Stream Reset August 2005 The following example illustrates an Endpoint A resetting stream 1 and 2 for just its incoming streams. E-A E-Z ------[STR_RESET(REQ:Y=1,R=0)1,2]--------> <-----[STR_RESET(RESP:P=1,D=0)1,2]------- 5. Security Considerations Having the ability to reset a stream should not pose any additional security risk to SCTP. An attacker that can successfully inject a stream reset would also be able to inject data or other malicious information into an association such as an ABORT. 6. Iana Considerations This document defines one new chunk type and two new parameter types. This document recommends the values of 0x82 for the chunk type and 0x000d and 0x000e for the new parameter types. However IANA may assign any free chunk or parameter type as long it is from the same chunk or parameter pool. In the case of the chunk, it MUST be from the pool of chunks with the upper two bits set to '10'. In the case of the parameters, it MUST be from the pool whose upper bits are set to '00'. 7. Normative References [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, Stewart, et al. Expires February 27, 2006 [Page 12] Internet-Draft SCTP Stream Reset August 2005 "Stream Control Transmission Protocol", RFC 2960, October 2000. Stewart, et al. Expires February 27, 2006 [Page 13] Internet-Draft SCTP Stream Reset August 2005 Authors' Addresses Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA Phone: Email: rrs@cisco.com Peter Lei Cisco Systems, Inc. 8735 West Higgins Road Suite 300 Chicago, IL 60631 USA Phone: Email: peterlei@cisco.com Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany Email: tuexen@fh-muenster.de Stewart, et al. Expires February 27, 2006 [Page 14] Internet-Draft SCTP Stream Reset August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stewart, et al. Expires February 27, 2006 [Page 15]