draft-ietf-tsvwg-addip-sctp-11.txt   draft-ietf-tsvwg-addip-sctp-12.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Ramalho Internet-Draft M. Ramalho
Expires: August 24, 2005 Cisco Systems, Inc. Expires: December 9, 2005 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
February 20, 2005 June 7, 2005
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-11.txt draft-ietf-tsvwg-addip-sctp-12.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
which he or she is aware have been or will be disclosed, and any of of which he or she is aware have been or will be disclosed, and
which he or she become aware will be disclosed, in accordance with any of which he or she becomes aware will be disclosed, in accordance
RFC 3668. 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 24, 2005. This Internet-Draft will expire on December 9, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 38 skipping to change at page 2, line 38
Shortage . . . . . . . . . . . . . . . . . . . . . . . 15 Shortage . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 Error Cause: Request to Delete Source IP Address . . . 16 3.3.3 Error Cause: Request to Delete Source IP Address . . . 16
3.3.4 Error Cause: Association Aborted due to illegal 3.3.4 Error Cause: Association Aborted due to illegal
ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 17 ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 17
3.3.5 Error Cause: Request refused - no authorization. . . . 17 3.3.5 Error Cause: Request refused - no authorization. . . . 17
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 19 4.1 ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 19
4.1.1 Congestion Control of ASCONF Chunks . . . . . . . . . 20 4.1.1 Congestion Control of ASCONF Chunks . . . . . . . . . 20
4.2 Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 21 4.2 Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 21
4.3 General rules for address manipulation . . . . . . . . . . 23 4.3 General rules for address manipulation . . . . . . . . . . 23
4.3.1 A special case for OOTB ABORT chunks . . . . . . . . . 26 4.3.1 A special case for OOTB ABORT chunks . . . . . . . . . 27
4.3.2 A special case for changing an address. . . . . . . . 26 4.3.2 A special case for changing an address. . . . . . . . 27
4.4 Setting of the primary address . . . . . . . . . . . . . . 27 4.4 Setting of the primary address . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
A. Abstract Address Handling . . . . . . . . . . . . . . . . . . 32 A. Abstract Address Handling . . . . . . . . . . . . . . . . . . 34
A.1 General remarks . . . . . . . . . . . . . . . . . . . . . 32 A.1 General remarks . . . . . . . . . . . . . . . . . . . . . 34
A.2 Generalized endpoints . . . . . . . . . . . . . . . . . . 32 A.2 Generalized endpoints . . . . . . . . . . . . . . . . . . 34
A.3 Associations . . . . . . . . . . . . . . . . . . . . . . . 33 A.3 Associations . . . . . . . . . . . . . . . . . . . . . . . 35
A.4 Relationship with RFC 2960 . . . . . . . . . . . . . . . . 33 A.4 Relationship with RFC 2960 . . . . . . . . . . . . . . . . 36
A.5 Rules for address manipulation . . . . . . . . . . . . . . 34 A.5 Rules for address manipulation . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . 37
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.
These extensions enable SCTP to be utilized in the following These extensions enable SCTP to be utilized in the following
applications: applications:
1. For computational or networking platforms that allow 1. For computational or networking platforms that allow addition/
addition/removal of physical interface cards this feature can removal of physical interface cards this feature can provide a
provide a graceful method to add to the interfaces of an existing graceful method to add to the interfaces of an existing
association. For IPv6 this feature allows renumbering of association. For IPv6 this feature allows renumbering of
existing associations. existing associations.
2. This provides a method for an endpoint to request that its peer 2. This provides a method for an endpoint to request that its peer
set its primary destination address. This can be useful when an set its primary destination address. This can be useful when an
address is about to be deleted, or when an endpoint has some address is about to be deleted, or when an endpoint has some
predetermined knowledge about which is the preferred address to predetermined knowledge about which is the preferred address to
receive SCTP packets upon. receive SCTP packets upon.
3. This feature can be used to extend the usability of SCTP without 3. This feature can be used to extend the usability of SCTP without
modifying it by allowing endpoints to exchange some information modifying it by allowing endpoints to exchange some information
during association setup. during association setup.
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
RFC2119 [2]. RFC2119 [2].
skipping to change at page 6, line 45 skipping to change at page 6, line 47
in the ASCONF Chunk are set to one. As defined in RFC2960 [6] in the ASCONF Chunk are set to one. As defined in RFC2960 [6]
section 3.2, setting these upper bits in this manner will cause the section 3.2, setting these upper bits in this manner will cause the
receiver that does not understand this chunk to skip the chunk and receiver that does not understand this chunk to skip the chunk and
continue processing, but report in an Operation Error Chunk using the continue processing, but report in an Operation Error Chunk using the
'Unrecognized Chunk Type' cause of error. 'Unrecognized Chunk Type' cause of error.
3.1.1 Address Configuration Change Chunk (ASCONF) 3.1.1 Address Configuration Change Chunk (ASCONF)
This chunk is used to communicate to the remote endpoint one of the This chunk is used to communicate to the remote endpoint one of the
configuration change requests that MUST be acknowledged. The configuration change requests that MUST be acknowledged. The
information carried in the ASCONF Chunk uses the form of a information carried in the ASCONF Chunk uses the form of a Type-
Type-Length-Value (TLV), as described in "3.2.1 Length-Value (TLV), as described in "3.2.1 Optional/Variable-length
Optional/Variable-length Parameter Format" in RFC2960 [6], for all Parameter Format" in RFC2960 [6], for all variable parameters. This
variable parameters. This chunk MUST be sent in an authenticated way chunk MUST be sent in an authenticated way by using the mechanism
by using the mechanism defined in SCTP-AUTH [7]. If this chunk is defined in SCTP-AUTH [7]. If this chunk is received unauthenticated
received unauthenticated it MUST be silently discarded as described it MUST be silently discarded as described in SCTP-AUTH [7].
in SCTP-AUTH [7].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC1 | Chunk Flags | Chunk Length | | Type = 0xC1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 4 skipping to change at page 8, line 4
Each Address configuration change is represented by a TLV parameter Each Address configuration change is represented by a TLV parameter
as defined in Section 3.2. One or more requests may be present in an as defined in Section 3.2. One or more requests may be present in an
ASCONF Chunk. ASCONF Chunk.
3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK) 3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK)
This chunk is used by the receiver of an ASCONF Chunk to acknowledge This chunk is used by the receiver of an ASCONF Chunk to acknowledge
the reception. It carries zero or more results for any ASCONF the reception. It carries zero or more results for any ASCONF
Parameters that were processed by the receiver. This chunk MUST be Parameters that were processed by the receiver. This chunk MUST be
sent in an authenticated way by using the mechanism defined in sent in an authenticated way by using the mechanism defined in SCTP-
SCTP-AUTH [7]. If this chunk is received unauthenticated it MUST be AUTH [7]. If this chunk is received unauthenticated it MUST be
silently discarded as described in SCTP-AUTH [7]. silently discarded as described in SCTP-AUTH [7].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x80 | Chunk Flags | Chunk Length | | Type = 0x80 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#1 | | ASCONF Parameter Response#1 |
skipping to change at page 12, line 4 skipping to change at page 12, line 4
Error Cause(s): TLV(s) Error Cause(s): TLV(s)
When reporting an error this response parameter is used to wrap one When reporting an error this response parameter is used to wrap one
or more standard error causes normally found within an SCTP or more standard error causes normally found within an SCTP
Operational Error or SCTP Abort (as defined in RFC2960 [6]). The Operational Error or SCTP Abort (as defined in RFC2960 [6]). The
Error Cause(s) follow the format defined in section 3.3.10 of RFC2960 Error Cause(s) follow the format defined in section 3.3.10 of RFC2960
[6]. [6].
Valid Chunk Appearance Valid Chunk Appearance
The Error Cause Indication parameter may only appear in the The Error Cause Indication parameter may only appear in the ASCONF-
ASCONF-ACK chunk type. ACK chunk type.
3.2.4 Set Primary IP Address 3.2.4 Set Primary IP Address
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC004 | Length = Variable | | Type =0xC004 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID | | ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 15 skipping to change at page 14, line 15
protocols. It is envisioned to be used for flow control and other protocols. It is envisioned to be used for flow control and other
adaptation layers that require an indication to be carried in the adaptation layers that require an indication to be carried in the
INIT and INIT-ACK. Each adaptation layer that is defined that wishes INIT and INIT-ACK. Each adaptation layer that is defined that wishes
to use this parameter MUST specify a an adaption code point in an to use this parameter MUST specify a an adaption code point in an
appropriate RFC defining its use and meaning. This parameter SHOULD appropriate RFC defining its use and meaning. This parameter SHOULD
NOT be examined by the receiving SCTP implementation and should be NOT be examined by the receiving SCTP implementation and should be
passed opaquely to the upper layer protocol. passed opaquely to the upper layer protocol.
Valid Chunk Appearance Valid Chunk Appearance
The Adaptation Layer Indication parameter may appear in INIT or The Adaptation Layer Indication parameter may appear in INIT or INIT-
INIT-ACK chunk and SHOULD be passed to the receivers upper layer ACK chunk and SHOULD be passed to the receivers upper layer protocol.
protocol. This parameter MUST NOT appear in a ASCONF chunk. This parameter MUST NOT appear in a ASCONF 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.
skipping to change at page 20, line 40 skipping to change at page 21, line 10
In defining the ASCONF Chunk transfer procedures, it is essential In defining the ASCONF Chunk transfer procedures, it is essential
that these transfers MUST NOT cause congestion within the network. that these transfers MUST NOT cause congestion within the network.
To achieve this, we place these restrictions on the transfer of To achieve this, we place these restrictions on the transfer of
ASCONF Chunks: ASCONF Chunks:
R1) One and only one ASCONF Chunk MAY be in transit and R1) One and only one ASCONF Chunk MAY be in transit and
unacknowledged at any one time. If a sender, after sending an unacknowledged at any one time. If a sender, after sending an
ASCONF chunk, decides it needs to transfer another ASCONF Chunk, ASCONF chunk, decides it needs to transfer another ASCONF Chunk,
it MUST wait until the ASCONF-ACK Chunk returns from the previous it MUST wait until the ASCONF-ACK Chunk returns from the previous
ASCONF Chunk before sending a subsequent ASCONF. Note this ASCONF Chunk before sending a subsequent ASCONF. Note this
restriction binds each side, so at any time two ASCONF may be restriction binds each side, so at any time two ASCONF may be in-
in-transit on any given association (one sent from each endpoint). transit on any given association (one sent from each endpoint).
R2) An ASCONF may be bundled with any other chunk type (except other R2) An ASCONF may be bundled with any other chunk type (except other
ASCONF Chunks). ASCONF Chunks).
R3) An ASCONF-ACK may be bundled with any other chunk type except R3) An ASCONF-ACK may be bundled with any other chunk type except
other ASCONF-ACKs. other ASCONF-ACKs.
R4) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP R4) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP
state except ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED and state except ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED and
SHUTDOWN-SENT. SHUTDOWN-SENT.
R5) An ASCONF MUST NOT be larger than the path MTU of the R5) An ASCONF MUST NOT be larger than the path MTU of the
destination. destination.
R6) An ASCONF-ACK SHOULD not be larger than the path MTU. In some R6) An ASCONF-ACK SHOULD not be larger than the path MTU. In some
circumstances an ASCONF-ACK may exceed the path MTU and in such a circumstances an ASCONF-ACK may exceed the path MTU and in such a
case IP fragmentation should be used to transmit the chunk. case IP fragmentation should be used to transmit the chunk.
If the sender of an ASCONF Chunk receives an Operational Error If the sender of an ASCONF Chunk receives an Operational Error
indicating that the ASCONF chunk type is not understood, then the indicating that the ASCONF chunk type is not understood, then the
sender MUST NOT send subsequent ASCONF Chunks to the peer. The sender MUST NOT send subsequent ASCONF Chunks to the peer. The
skipping to change at page 21, line 27 skipping to change at page 21, line 48
When an endpoint receives an ASCONF Chunk from the remote peer When an endpoint receives an ASCONF Chunk from the remote peer
special procedures MAY be needed to identify the association the special procedures MAY be needed to identify the association the
ASCONF Chunk is associated with. To properly find the association ASCONF Chunk is associated with. To properly find the association
the following procedures should be followed: the following procedures should be followed:
L1) Use the source address and port number of the sender to attempt L1) Use the source address and port number of the sender to attempt
to identify the association (i.e. use the same method defined in to identify the association (i.e. use the same method defined in
RFC2960 [6] used for all other SCTP chunks). If found proceed to RFC2960 [6] used for all other SCTP chunks). If found proceed to
rule L4. rule L4.
L2) If the association is not found, use the address found in the L2) If the association is not found, use the address found in the
Address Parameter TLV combined with the port number found in the Address Parameter TLV combined with the port number found in the
SCTP common header. If found proceed to rule L4. SCTP common header. If found proceed to rule L4.
L3) If neither L1 or L2 locates the association, treat the chunk as L3) If neither L1 or L2 locates the association, treat the chunk as
an Out Of The Blue chunk as defined in RFC2960 [6]. an Out Of The Blue chunk as defined in RFC2960 [6].
L4) Follow the normal rules to validate the SCTP verification tag L4) Follow the normal rules to validate the SCTP verification tag
found in RFC2960 [6]. found in RFC2960 [6].
After identification and verification of the association, the After identification and verification of the association, the
following should be performed to properly process the ASCONF Chunk: following should be performed to properly process the ASCONF Chunk:
C1) Compare the value of the serial number to the value the endpoint C1) Compare the value of the serial number to the value the endpoint
stored in a new association variable 'Peer-Serial-Number'. This stored in a new association variable 'Peer-Serial-Number'. This
value MUST be initialized to the Initial TSN value minus 1. value MUST be initialized to the Initial TSN value minus 1.
C2) If the value found in the serial number is equal to the
('Peer-Serial-Number' + 1), the endpoint MUST: C2) If the value found in the serial number is equal to the ('Peer-
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.
skipping to change at page 29, line 11 skipping to change at page 30, line 11
intercept the association setup. However, if a preconfigured shared intercept the association setup. However, if a preconfigured shared
end-point pair key is used this is not possible. For a more detailed end-point pair key is used this is not possible. For a more detailed
analysis see SCTP-AUTH [7]. analysis see SCTP-AUTH [7].
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 Six parameter types, and o Six parameter types, and
o Three new SCTP error causes.
o Five new SCTP error causes.
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
other available code point with the upper bits set is also
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 available code
point with the upper bit set is also acceptable.
All of the parameter types must come from the range of types where
the upper two bits are set, we recommend 0xC001 - 0xC006, as
specified in this document, but other parameter types can be used as
long as the upper two bits of the type are set to one.
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
ranges of error codes. Any other unassigned values are also
acceptable.
This document also defines a Adaption code point. The adaption code This document also defines a Adaption code point. The adaption code
point is a 32 bit integer that is assigned by IANA through an IETF point is a 32 bit integer that is assigned by IANA through an IETF
Consensus action as defined in RFC2434 [4]. Consensus action as defined in RFC2434 [4].
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,
and Chip Sharp for their invaluable comments. and Chip Sharp for their invaluable comments.
skipping to change at page 30, line 29 skipping to change at page 31, line 29
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] 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.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June [5] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
1999. June 1999.
[6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [6] 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.
[7] Tuexen, M., Stewart, R., Lei, P. and E. Rescorla, "Authenticated [7] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
Chunks for Stream Control Transmission Protocol (SCTP)", "Authenticated Chunks for Stream Control Transmission Protocol
Internet-Draft draft-tuexen-sctp-auth-chunk-03, February 2005. (SCTP)", draft-tuexen-sctp-auth-chunk-03 (work in progress),
February 2005.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
 End of changes. 

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