draft-ietf-tsvwg-addip-sctp-14.txt   draft-ietf-tsvwg-addip-sctp-15.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Ramalho Internet-Draft M. Ramalho
Expires: September 7, 2006 Cisco Systems, Inc. Expires: December 2, 2006 Cisco Systems, Inc.
Q. Xie Q. Xie
Motorola, Inc. Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
P. Conrad P. Conrad
University of Delaware University of Delaware
March 6, 2006 May 31, 2006
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-14.txt draft-ietf-tsvwg-addip-sctp-15.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 September 7, 2006. This Internet-Draft will expire on December 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes extensions to the Stream Control Transmission This document describes extensions to the Stream Control Transmission
Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
address information on an existing association. address information on an existing association.
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3.3.5. Error Cause: Request refused - no authorization. . . . 17 3.3.5. Error Cause: Request refused - no authorization. . . . 17
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18 4.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18
4.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 19 4.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 19
4.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 20 4.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 20
4.3. General rules for address manipulation . . . . . . . . . . 22 4.3. General rules for address manipulation . . . . . . . . . . 22
4.3.1. A special case for OOTB ABORT chunks . . . . . . . . . 25 4.3.1. A special case for OOTB ABORT chunks . . . . . . . . . 25
4.3.2. A special case for changing an address. . . . . . . . 26 4.3.2. A special case for changing an address. . . . . . . . 26
4.4. Setting of the primary address . . . . . . . . . . . . . . 26 4.4. Setting of the primary address . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 28 Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 29
A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 29 A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 29
A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 29 A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 29
A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 29 A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 30
A.4. Relationship with RFC 2960 . . . . . . . . . . . . . . . . 30 A.4. Relationship with RFC 2960 . . . . . . . . . . . . . . . . 31
A.5. Rules for address manipulation . . . . . . . . . . . . . . 31 A.5. Rules for address manipulation . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
To extend the utility and application scenarios of SCTP, this To extend the utility and application scenarios of SCTP, this
document introduces optional extensions that provide SCTP with the document introduces optional extensions that provide SCTP with the
ability to: ability to:
1. reconfigure IP address information on an existing association. 1. reconfigure IP address information on an existing association.
2. set the remote primary path. 2. set the remote primary path.
3. exchange adaptation layer information during association setup. 3. exchange adaptation layer information during association setup.
skipping to change at page 13, line 40 skipping to change at page 13, line 40
Valid Chunk Appearance Valid Chunk Appearance
The Adaptation Layer Indication parameter may appear in INIT or INIT- The Adaptation Layer Indication parameter may appear in INIT or INIT-
ACK chunk and SHOULD be passed to the receivers upper layer protocol. ACK chunk and SHOULD be passed to the receivers upper layer protocol.
This parameter MUST NOT appear in a ASCONF chunk. This parameter MUST NOT appear in a ASCONF chunk.
3.2.7. Supported Extensions Parameter 3.2.7. Supported Extensions Parameter
This parameter is used at startup to identify any additional This parameter is used at startup to identify any additional
extensions that the sender supports. extensions that the sender supports. The sender MUST support both
the sending and the receiving of any chunk types listed within the
Supported Extensions Parameter.
0 1 2 3 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 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 = 0x8008 | Parameter Length | | Parameter Type = 0x8008 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 | | CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 29 skipping to change at page 14, line 29
for IANA is 0x8008. for IANA is 0x8008.
Parameter Type Length This field holds the length of the parameter, Parameter Type Length This field holds the length of the parameter,
including the Parameter Type, Parameter Length and any addition including the Parameter Type, Parameter Length and any addition
supported extensions. Note the length MUST NOT include any supported extensions. Note the length MUST NOT include any
padding. padding.
CHUNK TYPE X This field(s) hold the chunk type of any SCTP CHUNK TYPE X This field(s) hold the chunk type of any SCTP
extension(s) that are currently supported by the sending SCTP. extension(s) that are currently supported by the sending SCTP.
Multiple chunk types may be defined listing each additional Multiple chunk types may be defined listing each additional
feature that the sender supports. The sender MUST NOT include feature that the sender supports. The sender MUST NOT include
multiple Supported Extensions Parameter within any chunk. multiple Supported Extensions Parameter within any chunk.
Parameter Appearence This parameter may appear in the INIT or INIT- Parameter Appearance This parameter may appear in the INIT or INIT-
ACK chunk. This parameter MUST NOT appear in any other chunk. ACK chunk. This parameter MUST NOT appear in any other chunk.
3.3. New Error Causes 3.3. New Error Causes
Five new Error Causes are added to the SCTP Operational Errors, Five new Error Causes are added to the SCTP Operational Errors,
primarily for use in the ASCONF-ACK chunk. primarily for use in the ASCONF-ACK chunk.
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
0x0100 Request to Delete Last Remaining IP Address. 0x0100 Request to Delete Last Remaining IP Address.
0x0101 Operation Refused Due to Resource Shortage. 0x0101 Operation Refused Due to Resource Shortage.
0x0102 Request to Delete Source IP Address. 0x0102 Request to Delete Source IP Address.
0x0103 Association Aborted due to illegal ASCONF-ACK 0x0103 Association Aborted due to illegal ASCONF-ACK
0x0104 Request refused - no authorization. 0x0104 Request refused - no authorization.
Table 4: New Error Causes Table 5: New Error Causes
3.3.1. Error Cause: Request to Delete Last Remaining IP Address 3.3.1. Error Cause: Request to Delete Last Remaining IP Address
Cause of error Cause of error
Request to Delete Last Remaining IP address: The receiver of this Request to Delete Last Remaining IP address: The receiver of this
error sent a request to delete the last IP address from its error sent a request to delete the last IP address from its
association with its peer. This error indicates that the request is association with its peer. This error indicates that the request is
rejected. rejected.
0 1 2 3 0 1 2 3
skipping to change at page 21, line 15 skipping to change at page 21, line 15
C2) If the value found in the serial number is equal to the ('Peer- C2) If the value found in the serial number is equal to the ('Peer-
Serial-Number' + 1), the endpoint MUST: Serial-Number' + 1), the endpoint MUST:
V1) Process the TLVs contained within the Chunk performing the V1) Process the TLVs contained within the Chunk performing the
appropriate actions as indicated by each TLV type. The TLVs appropriate actions as indicated by each TLV type. The TLVs
MUST be processed in order within the Chunk. For example, if MUST be processed in order within the Chunk. For example, if
the sender puts 3 TLVs in one chunk, the first TLV (the one the sender puts 3 TLVs in one chunk, the first TLV (the one
closest to the Chunk Header) in the Chunk MUST be processed closest to the Chunk Header) in the Chunk MUST be processed
first. The next TLV in the chunk (the middle one) MUST be first. The next TLV in the chunk (the middle one) MUST be
processed second and finally the last TLV in the Chunk MUST be processed second and finally the last TLV in the Chunk MUST be
processed last. processed last. If the association was found via L2, the first
parameter MUST be an Add IP address parameter for the source
address of the packet. If it is not the case the ASCONF is
silently discarded. Please note that this new address can not
be deleted by a later parameter in the chunk because it is the
source address of the packet.
V2) In processing the chunk, the receiver should build a response V2) In processing the chunk, the receiver should build a response
message with the appropriate error TLVs, as specified in the message with the appropriate error TLVs, as specified in the
Parameter type bits for any ASCONF Parameter it does not Parameter type bits for any ASCONF Parameter it does not
understand. To indicate an unrecognized parameter, cause type understand. To indicate an unrecognized parameter, cause type
8 as defined in the ERROR in 3.3.10.8 of RFC2960 [RFC2960] 8 as defined in the ERROR in 3.3.10.8 of RFC2960 [RFC2960]
should be used. The endpoint may also use the response to should be used. The endpoint may also use the response to
carry rejections for other reasons such as resource shortages carry rejections for other reasons such as resource shortages
etc, using the Error Cause TLV and an appropriate error etc, using the Error Cause TLV and an appropriate error
condition. condition.
Note: a positive response is implied if no error is indicated Note: a positive response is implied if no error is indicated
skipping to change at page 22, line 42 skipping to change at page 22, line 45
outstanding the endpoint MUST ABORT the association. Note that a outstanding the endpoint MUST ABORT the association. Note that a
sequence number is greater than if it is no more than 2^^31-1 sequence number is greater than if it is no more than 2^^31-1
larger than the current sequence number (using serial arithmetic). larger than the current sequence number (using serial arithmetic).
D1) When adding an IP address to an association, the IP address is D1) When adding an IP address to an association, the IP address is
NOT considered fully added to the association until the ASCONF-ACK NOT considered fully added to the association until the ASCONF-ACK
arrives. This means that until such time as the ASCONF containing arrives. This means that until such time as the ASCONF containing
the add is acknowledged the sender MUST NOT use the new IP address the add is acknowledged the sender MUST NOT use the new IP address
as a source for ANY SCTP packet except on carrying an ASCONF as a source for ANY SCTP packet except on carrying an ASCONF
chunk. The receiver of the add IP address request may use the chunk. The receiver of the add IP address request may use the
address as a destination immediately. The receiver MUST use the address as a destination immediately. The receiver MUST use the
address verification procedure for the added address before using path verification procedure for the added address before using
that address. that address. The receiver MUST NOT send packets to the new
address except for the corresponding ASCONF-ACK chunk or HEARTBEAT
chunks for path verification before the new path is verified. If
the ASCONF-ACK is sent to the new address it MAY be bundled with
the HEARTBEAT chunk for path verification.
D2) After the ASCONF-ACK of an IP address add arrives, the endpoint D2) After the ASCONF-ACK of an IP address add arrives, the endpoint
MAY begin using the added IP address as a source address for any MAY begin using the added IP address as a source address for any
type of SCTP chunk. type of SCTP chunk.
D3a) If an endpoint receives an Error Cause TLV indicating that the D3a) If an endpoint receives an Error Cause TLV indicating that the
IP address Add or IP address Deletion parameters was not IP address Add or IP address Deletion parameters was not
understood, the endpoint MUST consider the operation failed and understood, the endpoint MUST consider the operation failed and
MUST NOT attempt to send any subsequent Add or Delete requests to MUST NOT attempt to send any subsequent Add or Delete requests to
the peer. the peer.
D3b) If an endpoint receives an Error Cause TLV indicating that the D3b) If an endpoint receives an Error Cause TLV indicating that the
IP address Set Primary IP Address parameter was not understood, IP address Set Primary IP Address parameter was not understood,
the endpoint MUST consider the operation failed and MUST NOT the endpoint MUST consider the operation failed and MUST NOT
attempt to send any subsequent Set Primary IP Address requests to attempt to send any subsequent Set Primary IP Address requests to
the peer. the peer.
D4) When deleting an IP address from an association, the IP address D4) When deleting an IP address from an association, the IP address
MUST be considered a valid destination address for the reception MUST be considered a valid destination address for the reception
of SCTP packets until the ASCONF-ACK arrives and MUST NOT be used of SCTP packets until the ASCONF-ACK arrives and MUST NOT be used
as a source address for any subsequent packets. This means that as a source address for any subsequent packets. This means that
any datagrams that arrive before the ASCONF-ACK destined to the IP any datagrams that arrive before the ASCONF-ACK destined to the IP
skipping to change at page 27, line 7 skipping to change at page 27, line 19
The request to set an address as the primary path is an option the The request to set an address as the primary path is an option the
receiver SHOULD perform. It is considered advice to the receiver of receiver SHOULD perform. It is considered advice to the receiver of
the best destination address to use in sending SCTP packets (in the the best destination address to use in sending SCTP packets (in the
requesters view). If a request arrives that asks the receiver to set requesters view). If a request arrives that asks the receiver to set
an address as primary that does not exist, the receiver should NOT an address as primary that does not exist, the receiver should NOT
honor the request, leaving its existing primary address unchanged. honor the request, leaving its existing primary address unchanged.
5. Security Considerations 5. Security Considerations
The ADD/DELETE of an IP address to an existing association does The addition and or deletion of an IP address to an existing
provide an additional mechanism by which existing associations can be association does provide an additional mechanism by which existing
hijacked. associations can be hijacked. Therefore this document requires the
use of the authentication mechanism defined in SCTP-AUTH [I-D.ietf-
tsvwg-sctp-auth] to limit the ability of an attacker to hijack an
association.
This document requires the use of the authentication mechanism Hijacking an association by using the addition and deletion of an IP
defined in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] to limit the ability address is only possible for an attacker who is able to intercept the
of an attacker to hijack an association. Hijacking an association by initial two packets of the association setup when the SCTP-AUTH
using ADD/DELETE of an IP address is only possible for an attacker extension is used without pre-shared keys.. If such a threat is
who is able to intercept the association setup. However, if a considered a possibility, then the SCTP-AUTH [I-D.ietf-tsvwg-sctp-
preconfigured shared end-point pair key is used this is not possible. auth] extension MUST be used with a preconfigured shared end-point
For a more detailed analysis see SCTP-AUTH [I-D.ietf-tsvwg-sctp- pair key to mitigate this threat. For a more detailed analysis see
auth]. SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth].
If an SCTP endpoint that supports this extension receives an INIT
that indicates that the peer supports the ASCONF extension but does
NOT support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] extension, the
receiver of such an INIT MUST send an ABORT in response to such an
INIT. Note that an implementation is allowed to silently discard
such an INIT as an option as well but under NO circumstance is an
implementation allowed to proceed with the association setup by
sending an INIT-ACK in response.
An implementation that receives an INIT-ACK that indicates that the
peer does not support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]
extension MUST NOT send the COOKIE-ECHO to establish the association.
Instead the implementation MUST discard the INIT-ACK and report to
the upper layer user that an association cannot be established
destroying the TCB.
6. IANA considerations 6. IANA considerations
This document defines the following new SCTP parameters, chunks and This document defines the following new SCTP parameters, chunks and
errors: errors:
o Two new chunk types, o Two new chunk types,
o Seven parameter types, and o Seven parameter types, and
o Five new SCTP error causes. o Five new SCTP error causes.
One of the two new chunk types must come from the range of chunk One of the two new chunk types must come from the range of chunk
types where the upper two bits are one, we recommend 0xC1 but any types where the upper two bits are one, we recommend 0xC1 but any
other available code point with the upper bits set is also other available code point with the upper bits set is also
acceptable. acceptable. The second chunk type must come from the range where
only the upper bit is set to one. We recommend 0x80 but any other
The second chunk type must come from the range where only the upper available code point with the upper bit set is also acceptable. The
bit is set to one. We recommend 0x80 but any other available code suggested chunk types are listed in Table 1.
point with the upper bit set is also acceptable.
All but one of the parameter types must come from the range of types All but one of the parameter types must come from the range of types
where the upper two bits are set, we recommend 0xC001 - 0xC006, as where the upper two bits are set, we recommend 0xC001 - 0xC006, as
specified in this document. The other parameter type must come from specified in this document. The other parameter type must come from
the 0x8000 range, we recommend 0x8008. Note that for any of these the 0x8000 range, we recommend 0x8008. Note that for any of these
values a different unique parameter type may be assigned by IANA as values a different unique parameter type may be assigned by IANA as
long as the upper bits correspond to the ones specified in this long as the upper bits correspond to the ones specified in this
document. document. The suggested parameter types are listed in Table 2, Table
3, and Table 4.
The five new error causes can be any value, in this document we have The five new error causes can be any value, in this document we have
used 0x0100-0x0104 in an attempt to seperate these from the common used 0x0100-0x0104 in an attempt to separate these from the common
ranges of error codes. Any other unassigned values are also ranges of error codes. Any other unassigned values are also
acceptable. acceptable. The suggested error causes are listed in Table 5.
This document also defines a Adaptation code point. The adaptation This document also defines a Adaptation code point. The adaptation
code point is a 32 bit integer that is assigned by IANA through an code point is a 32 bit integer that is assigned by IANA through an
IETF Consensus action as defined in RFC2434 [RFC2434]. IETF Consensus action as defined in RFC2434 [RFC2434].
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Jon Berger, Greg Kendall, Seok Koh, Peter The authors wish to thank Jon Berger, Greg Kendall, Seok Koh, Peter
Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose, Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose,
Chip Sharp, and Irene Ruengeler for their invaluable comments. Chip Sharp, and Irene Ruengeler for their invaluable comments.
skipping to change at page 28, line 43 skipping to change at page 29, line 31
June 1999. June 1999.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[I-D.ietf-tsvwg-sctp-auth] [I-D.ietf-tsvwg-sctp-auth]
Tuexen, M., "Authenticated Chunks for Stream Control Tuexen, M., "Authenticated Chunks for Stream Control
Transmission Protocol (SCTP)", Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctp-auth-01 (work in progress), draft-ietf-tsvwg-sctp-auth-02 (work in progress),
October 2005. March 2006.
Appendix A. Abstract Address Handling Appendix A. Abstract Address Handling
A.1. General remarks A.1. General remarks
The following text provides a working definition of the endpoint The following text provides a working definition of the endpoint
notion to discuss address reconfiguration. It is not intended to notion to discuss address reconfiguration. It is not intended to
restrict implementations in any way, its goal is to provide as set of restrict implementations in any way, its goal is to provide as set of
definitions only. Using these definitions should make a discussion definitions only. Using these definitions should make a discussion
about address issues easier. about address issues easier.
 End of changes. 21 change blocks. 
39 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/