draft-ietf-tsvwg-addip-sctp-17.txt   draft-ietf-tsvwg-addip-sctp-18.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Q. Xie Intended status: Standards Track Q. Xie
Expires: June 1, 2007 Motorola, Inc. Expires: August 30, 2007 Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
S. Maruyama S. Maruyama
M. Kozuka M. Kozuka
Kyoto University Kyoto University
November 28, 2006 February 26, 2007
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-17.txt draft-ietf-tsvwg-addip-sctp-18.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 June 1, 2007. This Internet-Draft will expire on August 30, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Additional Chunks and Parameters . . . . . . . . . . . . . . . 4 3. Serial Number Arithmetic . . . . . . . . . . . . . . . . . . . 5
3.1. New Chunk Types . . . . . . . . . . . . . . . . . . . . . 5 4. Additional Chunks and Parameters . . . . . . . . . . . . . . . 5
3.1.1. Address Configuration Change Chunk (ASCONF) . . . . . 5 4.1. New Chunk Types . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Address Configuration Acknowledgment Chunk 4.1.1. Address Configuration Change Chunk (ASCONF) . . . . . 6
4.1.2. Address Configuration Acknowledgment Chunk
(ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 7 (ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 7
3.2. New Parameter Types . . . . . . . . . . . . . . . . . . . 7 4.2. New Parameter Types . . . . . . . . . . . . . . . . . . . 8
3.2.1. Add IP Address . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Add IP Address . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Delete IP Address . . . . . . . . . . . . . . . . . . 9 4.2.2. Delete IP Address . . . . . . . . . . . . . . . . . . 10
3.2.3. Error Cause Indication . . . . . . . . . . . . . . . . 10 4.2.3. Error Cause Indication . . . . . . . . . . . . . . . . 11
3.2.4. Set Primary IP Address . . . . . . . . . . . . . . . . 11 4.2.4. Set Primary IP Address . . . . . . . . . . . . . . . . 12
3.2.5. Success Indication . . . . . . . . . . . . . . . . . . 12 4.2.5. Success Indication . . . . . . . . . . . . . . . . . . 13
3.2.6. Adaptation Layer Indication . . . . . . . . . . . . . 13 4.2.6. Adaptation Layer Indication . . . . . . . . . . . . . 14
3.2.7. Supported Extensions Parameter . . . . . . . . . . . . 13 4.3. New Error Causes . . . . . . . . . . . . . . . . . . . . . 14
3.3. New Error Causes . . . . . . . . . . . . . . . . . . . . . 14 4.3.1. Error Cause: Request to Delete Last Remaining IP
3.3.1. Error Cause: Request to Delete Last Remaining IP
Address . . . . . . . . . . . . . . . . . . . . . . . 15 Address . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2. Error Cause: Operation Refused Due to Resource 4.3.2. Error Cause: Operation Refused Due to Resource
Shortage . . . . . . . . . . . . . . . . . . . . . . . 15 Shortage . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3. Error Cause: Request to Delete Source IP Address . . . 16 4.3.3. Error Cause: Request to Delete Source IP Address . . . 16
3.3.4. Error Cause: Association Aborted due to illegal 4.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 4.3.5. Error Cause: Request refused - no authorization. . . . 17
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18 5.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18
4.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 20 5.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 20
4.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 21 5.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 21
4.3. General rules for address manipulation . . . . . . . . . . 23 5.3. General rules for address manipulation . . . . . . . . . . 23
4.3.1. A special case for OOTB ABORT Chunks . . . . . . . . . 27 5.3.1. A special case for OOTB ABORT Chunks . . . . . . . . . 27
4.3.2. A special case for changing an address. . . . . . . . 27 5.3.2. A special case for changing an address. . . . . . . . 27
4.4. Setting of the primary address . . . . . . . . . . . . . . 28 5.4. Setting of the primary address . . . . . . . . . . . . . . 28
4.5. Bundling of multiple ASCONFs . . . . . . . . . . . . . . . 28 5.5. Bundling of multiple ASCONFs . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 31 Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 32
A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 31 A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 32
A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 31 A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 32
A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 32 A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 33
A.4. Relationship with RFC 2960 . . . . . . . . . . . . . . . . 33 A.4. Relationship with RFC 2960 . . . . . . . . . . . . . . . . 34
A.5. Rules for address manipulation . . . . . . . . . . . . . . 33 A.5. Rules for address manipulation . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
To extend the utility and application scenarios of SCTP, this A local host may have multiple points of attachment to the Internet,
document introduces optional extensions that provide SCTP with the giving it a degree of fault tolerance from hardware failures. SCTP
ability to: was developed to take full advantage of such a multi-homed host to
provide a fast failover and association survivability in the face of
such hardware failures. However, many modern computers allow for the
dynamic addition and deletion of network cards (sometimes termed a
hot-pluggable interface). Complicate this with the ability of a
provider, in IPv6, to dynamically renumber a network, and there still
is a gap between full fault tolerance and the currently defined SCTP
protocol. No matter if a card is added or an interface is
renumbered, in order to take advantage of this new configuration, the
transport association must be restarted. For many fault tolerant
applications this restart is considered an outage and is undesirable.
1. reconfigure IP address information on an existing association. This document describes an extension to SCTP to attempt to correct
2. set the remote primary path. this problem for the more demanding fault tolerant application. This
3. exchange adaptation layer information during association setup. extension will allow an SCTP stack to:
These extensions enable SCTP to be utilized in the following o Dynamically add an IP Addresses to an association.
applications: o Dynamically delete an IP Addresses from an association.
o Request to set the primary address the peer will use when sending
to an endpoint.
1. For computational or networking platforms that allow addition/ The dynamic addition and subtraction of IP addresses allows an SCTP
removal of physical interface cards this feature can provide a association to continue to function through host and network
graceful method to add to the interfaces of an existing reconfigurations. These changes, brought on by provider or user
association. For IPv6 this feature allows renumbering of action, may mean that the peer would be better served by using the
existing associations. newly added address, however this information may only be known by
2. This provides a method for an endpoint to request that its peer the endpoint that had the reconfiguration occur. In such a case this
set its primary destination address. This can be useful when an extension allows the local endpoint to advise the peer as to what it
address is about to be deleted, or when an endpoint has some thinks is the better primary address that the peer should be using.
predetermined knowledge about which is the preferred address to
receive SCTP packets upon. One last thing this extension adds is a small 32 bit integer, called
3. This feature can be used to extend the usability of SCTP without an adaptation indication, that can be exchanged at startup. This is
modifying it by allowing endpoints to exchange some information useful for applications where there is one or more specific layers
during association setup. below the application, yet still above SCTP. In such a case the
exchange of this indication can allow the proper layer to be enabled
below the application.
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
they appear in this document, are to be interpreted as described in document are to be interpreted as described in RFC2119 [RFC2119].
RFC2119 [RFC2119].
3. Additional Chunks and Parameters 3. Serial Number Arithmetic
It is essential to remember that the actual ASCONF Sequence Number
space is finite, though very large. This space ranges from 0 to
2**32 - 1. Since the space is finite, all arithmetic dealing with
ASCONF Sequence Numbers MUST be performed modulo 2**32. This
unsigned arithmetic preserves the relationship of sequence numbers as
they cycle from 2**32 - 1 to 0 again. There are some subtleties to
computer modulo arithmetic, so great care should be taken in
programming the comparison of such values. When referring to ASCONF
Sequence Numbers, the symbol "=<" means "less than or equal"(modulo
2**32).
Comparisons and arithmetic on ASCONF sequence numbers in this
document SHOULD use Serial Number Arithmetic as defined in [RFC1982]
where SERIAL_BITS = 32.
ASCONF Sequence Numbers wrap around when they reach 2**32 - 1. That
is, the next ASCONF Sequence Number an ASCONF chunk MUST use after
transmitting ASCONF Sequence Number = 2*32 - 1 is TSN = 0.
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document uses normal
arithmetic.
4. Additional Chunks and Parameters
This section describes the addition of two new chunks and, seven new This section describes the addition of two new chunks and, seven new
parameters to allow: parameters to allow:
o Dynamic addition of IP Addresses to an association. o Dynamic addition of IP Addresses to an association.
o Dynamic deletion of IP Addresses from an association. o Dynamic deletion of IP Addresses from an association.
o A request to set the primary address the peer will use when o A request to set the primary address the peer will use when
sending to an endpoint. sending to an endpoint.
Additionally, this section describes three new error causes that Additionally, this section describes three new error causes that
support these new chunks and parameters. support these new chunks and parameters.
3.1. New Chunk Types 4.1. New Chunk Types
This section defines two new chunk types that will be used to This section defines two new chunk types that will be used to
transfer the control information reliably. Table 1 illustrates the transfer the control information reliably. Table 1 illustrates the
two new chunk types. two new chunk types.
Chunk Type Chunk Name Chunk Type Chunk Name
-------------------------------------------------------------- --------------------------------------------------------------
0xC1 Address Configuration Change Chunk (ASCONF) 0xC1 Address Configuration Change Chunk (ASCONF)
0x80 Address Configuration Acknowledgment (ASCONF-ACK) 0x80 Address Configuration Acknowledgment (ASCONF-ACK)
Table 1: Address Configuration Chunks Table 1: Address Configuration Chunks
It should be noted that the ASCONF Chunk format requires the receiver 4.1.1. Address Configuration Change Chunk (ASCONF)
to report to the sender if it does not understand the ASCONF Chunk.
This is accomplished by setting the upper bits in the chunk type as
described in RFC2960 [RFC2960] section 3.2. Note: that the upper two
bits in the ASCONF Chunk are set to one. As defined in RFC2960
[RFC2960] 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 continue processing, but report in an Operation Error Chunk
using the 'Unrecognized Chunk Type' cause of error.
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 Type- information carried in the ASCONF Chunk uses the form of a Type-
Length-Value (TLV), as described in "3.2.1 Optional/Variable-length Length-Value (TLV), as described in "3.2.1 Optional/Variable-length
Parameter Format" in RFC2960 [RFC2960], for all variable parameters. Parameter Format" in RFC2960 [RFC2960], for all variable parameters.
This chunk MUST be sent in an authenticated way by using the This chunk MUST be sent in an authenticated way by using the
mechanism defined in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]. If this mechanism defined in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]. If this
chunk is received unauthenticated it MUST be silently discarded as chunk is received unauthenticated it MUST be silently discarded as
described in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]. described in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth].
skipping to change at page 6, line 29 skipping to change at page 6, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #N | | ASCONF Parameter #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serial Number : 32 bits (unsigned integer) Serial Number : 32 bits (unsigned integer)
This value represents a Serial Number for the ASCONF Chunk. The This value represents a Serial Number for the ASCONF Chunk. The
valid range of Serial Number is from 0 to 4294967295 (2**32 - 1). valid range of Serial Number is from 0 to 4294967295 (2**32 - 1).
Serial Numbers wrap back to 0 after reaching 4294967295. Serial Numbers wrap back to 0 after reaching 4294967295.
Address Parameter : 8 or 20 bytes (depending on type) Address Parameter : 8 or 20 bytes (depending on the address type)
This field contains an address parameter, either IPv6 or IPv4, from This field contains an address parameter, either IPv6 or IPv4, from
RFC2960 [RFC2960]. The address is an address of the sender of the RFC2960 [RFC2960]. The address is an address of the sender of the
ASCONF Chunk, the address MUST be considered part of the association ASCONF Chunk, the address MUST be considered part of the association
by the peer endpoint (the receiver of the ASCONF Chunk). This field by the peer endpoint (the receiver of the ASCONF Chunk). This field
may be used by the receiver of the ASCONF to help in finding the may be used by the receiver of the ASCONF to help in finding the
association. If the address 0.0.0.0 or ::0 is provided the receiver association. If the address 0.0.0.0 or ::0 is provided the receiver
MAY lookup the association by other information provided in the MAY lookup the association by other information provided in the
packet. This parameter MUST be present in every ASCONF message i.e. packet. This parameter MUST be present in every ASCONF message i.e.
it is a mandatory TLV parameter. it is a mandatory TLV parameter.
Note: the host name address parameter is NOT allowed and MUST be Note: the host name address MUST NOT be sent and MUST be ignored if
ignored if received in any ASCONF message. received in any ASCONF message.
It should be noted that the ASCONF Chunk format requires the receiver
to report to the sender if it does not understand the ASCONF Chunk.
This is accomplished by setting the upper bits in the chunk type as
described in RFC2960 [RFC2960] section 3.2. Note: that the upper two
bits in the ASCONF Chunk are set to one. As defined in RFC2960
[RFC2960] section 3.2, when setting these upper bits in this manner
the receiver that does not understand this chunk MUST skip the chunk
and continue processing, and report in an Operation Error Chunk using
the 'Unrecognized Chunk Type' cause of error. This will NOT abort
the association but indicates to the sender that it MUST not send any
further ASCONF chunks.
ASCONF Parameter: TLV format ASCONF Parameter: TLV format
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 4.2. One or more requests may be present in an
ASCONF Chunk. ASCONF Chunk.
3.1.2. Address Configuration Acknowledgment Chunk (ASCONF-ACK) 4.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 SCTP- sent in an authenticated way by using the mechanism defined in SCTP-
AUTH [I-D.ietf-tsvwg-sctp-auth]. If this chunk is received AUTH [I-D.ietf-tsvwg-sctp-auth]. If this chunk is received
unauthenticated it MUST be silently discarded as described in SCTP- unauthenticated it MUST be silently discarded as described in SCTP-
AUTH [I-D.ietf-tsvwg-sctp-auth]. AUTH [I-D.ietf-tsvwg-sctp-auth].
0 1 2 3 0 1 2 3
skipping to change at page 7, line 46 skipping to change at page 8, line 36
ASCONF Parameter Response : TLV format ASCONF Parameter Response : TLV format
The ASCONF Parameter Response is used in the ASCONF-ACK to report The ASCONF Parameter Response is used in the ASCONF-ACK to report
status of ASCONF processing. By default, if a responding endpoint status of ASCONF processing. By default, if a responding endpoint
does not include any Error Cause, a success is indicated. Thus a does not include any Error Cause, a success is indicated. Thus a
sender of an ASCONF-ACK MAY indicate complete success of all TLVs in sender of an ASCONF-ACK MAY indicate complete success of all TLVs in
an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length
(set to 8) and the Serial Number. (set to 8) and the Serial Number.
3.2. New Parameter Types 4.2. New Parameter Types
The seven new parameters added follow the format defined in section The seven new parameters added follow the format defined in section
3.2.1 of RFC2960 [RFC2960]. Table 2, 3 and 4 describes the 3.2.1 of RFC2960 [RFC2960]. Table 2, 3 and 4 describes the
parameters. parameters.
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
Set Primary Address 0xC004 Set Primary Address 0xC004
Adaptation Layer Indication 0xC006 Adaptation Layer Indication 0xC006
Supported Extensions 0x8008
Table 2: Parameters that can be used in INIT/INIT-ACK chunk Table 2: Parameters that can be used in INIT/INIT-ACK chunk
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
Add IP Address 0xC001 Add IP Address 0xC001
Delete IP Address 0xC002 Delete IP Address 0xC002
Set Primary Address 0xC004 Set Primary Address 0xC004
Table 3: Parameters used in ASCONF Parameter Table 3: Parameters used in ASCONF Parameter
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
skipping to change at page 8, line 31 skipping to change at page 9, line 22
Address Configuration Parameters Parameter Type Address Configuration Parameters Parameter Type
------------------------------------------------- -------------------------------------------------
Error Cause Indication 0xC003 Error Cause Indication 0xC003
Success Indication 0xC005 Success Indication 0xC005
Table 4: Parameters used in ASCONF Parameter Response Table 4: Parameters used in ASCONF Parameter Response
Any parameter that appears where it is not allowed (for example a Any parameter that appears where it is not allowed (for example a
0xC002 parameter appearing within an INIT or INIT-ACK) MAY be 0xC002 parameter appearing within an INIT or INIT-ACK) MAY be
responded to with an ABORT by the receiver of the invalid parameter. responded to with an ABORT by the receiver of the invalid parameter.
If the receiver chooses NOT to abort, the parameter MUST be ignored.
A robust implementation SHOULD ignore the parameter and leave the
association intact.
3.2.1. Add IP Address 4.2.1. Add 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 = 0xC001 | Length = Variable | | Type = 0xC001 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID | | ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits ASCONF-Request Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. It is in host byte order and is only meaningful request parameter. The receiver of the ASCONF Chunk will copy this
to the sender. The receiver of the ASCONF Chunk will copy this 32 32 bit value into the ASCONF Response Correlation ID field of the
bit value into the ASCONF Response Correlation ID field of the
ASCONF-ACK response parameter. The sender of the ASCONF can use this ASCONF-ACK response parameter. The sender of the ASCONF can use this
same value in the ASCONF-ACK to find which request the response is same value in the ASCONF-ACK to find which request the response is
for. for. Note that the receiver MUST NOT change this 32 bit value.
Address Parameter: TLV Address Parameter: TLV
This field contains an IPv4 or IPv6 address parameter as described in This field contains an IPv4 or IPv6 address parameter as described in
3.3.2.1 of RFC2960 [RFC2960]. The complete TLV is wrapped within 3.3.2.1 of RFC2960 [RFC2960]. The complete TLV is wrapped within
this parameter. It informs the receiver that the address specified this parameter. It informs the receiver that the address specified
is to be added to the existing association. This parameter MUST NOT is to be added to the existing association. This parameter MUST NOT
contain a broadcast or multicast address. If the address 0.0.0.0 or contain a broadcast or multicast address. If the address 0.0.0.0 or
::0 is provided, the source address of the packet MUST be added. ::0 is provided, the source address of the packet MUST be added.
An example TLV requesting that the IPv4 address 10.1.1.1 be added to An example TLV requesting that the IPv4 address 192.0.2.1 be added to
the association would look as follows: the association would look as follows:
+--------------------------------+ +--------------------------------+
| Type=0xC001 | Length = 16 | | Type=0xC001 | Length = 16 |
+--------------------------------+ +--------------------------------+
| C-ID = 0x01023474 | | C-ID = 0x01023474 |
+--------------------------------+ +--------------------------------+
| Type=5 | Length = 8 | | Type=5 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0a010101 | | Value=0xC0000201 |
+----------------+---------------+ +----------------+---------------+
Valid Chunk Appearance Valid Chunk Appearance
The Add IP Address parameter may only appear in the ASCONF Chunk The Add IP Address parameter may only appear in the ASCONF Chunk
type. type.
3.2.2. Delete IP Address 4.2.2. Delete 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 =0xC002 | Length = Variable | | Type =0xC002 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID | | ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits ASCONF-Request Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. It is in host byte order and is only meaningful request parameter. The receiver of the ASCONF Chunk will copy this
to the sender. The receiver of the ASCONF Chunk will copy this 32 32 bit value into the ASCONF Response Correlation ID field of the
bit value into the ASCONF Response Correlation ID field of the
ASCONF-ACK response parameter. The sender of the ASCONF can use this ASCONF-ACK response parameter. The sender of the ASCONF can use this
same value in the ASCONF-ACK to find which request the response is same value in the ASCONF-ACK to find which request the response is
for. for. Note that the receiver MUST NOT change this 32 bit value.
Address Parameter: TLV Address Parameter: TLV
This field contains an IPv4 or IPv6 address parameter as described in This field contains an IPv4 or IPv6 address parameter as described in
3.3.2.1 of RFC2960 [RFC2960]. The complete TLV is wrapped within 3.3.2.1 of RFC2960 [RFC2960]. The complete TLV is wrapped within
this parameter. It informs the receiver that the address specified this parameter. It informs the receiver that the address specified
is to be removed from the existing association. This parameter MUST is to be removed from the existing association. This parameter MUST
NOT contain a broadcast or multicast address. If the address 0.0.0.0 NOT contain a broadcast or multicast address. If the address 0.0.0.0
or ::0 is provided, all addresses of the peer except the source or ::0 is provided, all addresses of the peer except the source
address of the packet MUST be deleted. address of the packet MUST be deleted.
An example TLV deleting the IPv4 address 10.1.1.1 from an existing An example TLV deleting the IPv4 address 192.0.2.1 from an existing
association would look as follows: association would look as follows:
+--------------------------------+ +--------------------------------+
| Type=0xC002 | Length = 16 | | Type=0xC002 | Length = 16 |
+--------------------------------+ +--------------------------------+
| C-ID = 0x01023476 | | C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Type=5 | Length = 8 | | Type=5 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0a010101 | | Value=0xC0000201 |
+----------------+---------------+ +----------------+---------------+
Valid Chunk Appearance Valid Chunk Appearance
The Delete IP Address parameter may only appear in the ASCONF Chunk The Delete IP Address parameter may only appear in the ASCONF Chunk
type. type.
3.2.3. Error Cause Indication 4.2.3. Error Cause Indication
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 = 0xC003 | Length = Variable | | Type = 0xC003 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID | | ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Cause(s) or Return Info on Success | | Error Cause(s) or Return Info on Success |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Response Correlation ID: 32 bits ASCONF-Response Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. The receiver of the ASCONF Chunk will copy this request parameter. The receiver of the ASCONF Chunk will copy this
32 bit value from the ASCONF-Request Correlation ID into the ASCONF 32 bit value from the ASCONF-Request Correlation ID into the ASCONF
Response Correlation ID field so the peer can easily correlate the Response Correlation ID field so the peer can easily correlate the
request to this response. request to this response. Note that the receiver MUST NOT change
this 32 bit value.
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 [RFC2960]). Operational Error or SCTP Abort (as defined in RFC2960 [RFC2960]).
The Error Cause(s) follow the format defined in section 3.3.10 of The Error Cause(s) follow the format defined in section 3.3.10 of
RFC2960 [RFC2960]. RFC2960 [RFC2960].
Valid Chunk Appearance Valid Chunk Appearance
The Error Cause Indication parameter may only appear in the ASCONF- The Error Cause Indication parameter may only appear in the ASCONF-
ACK Chunk type. ACK Chunk type.
skipping to change at page 11, line 22 skipping to change at page 12, line 15
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 [RFC2960]). Operational Error or SCTP Abort (as defined in RFC2960 [RFC2960]).
The Error Cause(s) follow the format defined in section 3.3.10 of The Error Cause(s) follow the format defined in section 3.3.10 of
RFC2960 [RFC2960]. RFC2960 [RFC2960].
Valid Chunk Appearance Valid Chunk Appearance
The Error Cause Indication parameter may only appear in the ASCONF- The Error Cause Indication parameter may only appear in the ASCONF-
ACK Chunk type. ACK Chunk type.
3.2.4. Set Primary IP Address 4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits ASCONF-Request Correlation ID: 32 bits
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. It is in host byte order and is only meaningful request parameter. The receiver of the ASCONF Chunk will copy this
to the sender. The receiver of the ASCONF Chunk will copy this 32 32 bit value into the ASCONF Response Correlation ID field of the
bit value into the ASCONF Response Correlation ID field of the
ASCONF-ACK response parameter. The sender of the ASCONF can use this ASCONF-ACK response parameter. The sender of the ASCONF can use this
same value in the ASCONF-ACK to find which request the response is same value in the ASCONF-ACK to find which request the response is
for. for. Note that the receiver MUST NOT change this 32 bit value.
Address Parameter: TLV Address Parameter: TLV
This field contains an IPv4 or IPv6 address parameter as described in This field contains an IPv4 or IPv6 address parameter as described in
3.3.2.1 of RFC2960 [RFC2960]. The complete TLV is wrapped within 3.3.2.1 of RFC2960 [RFC2960]. The complete TLV is wrapped within
this parameter. It requests the receiver to mark the specified this parameter. It requests the receiver to mark the specified
address as the primary address to send data to (see section 5.1.2 of address as the primary address to send data to (see section 5.1.2 of
RFC2960 [RFC2960]). The receiver MAY mark this as its primary upon RFC2960 [RFC2960]). The receiver MAY mark this as its primary upon
receiving this request. If the address 0.0.0.0 or ::0 is provided, receiving this request. If the address 0.0.0.0 or ::0 is provided,
the receiver MAY mark the source address of the packet as its the receiver MAY mark the source address of the packet as its
primary. primary.
An example TLV requesting that the IPv4 address 10.1.1.1 be made the An example TLV requesting that the IPv4 address 192.0.2.1 be made the
primary destination address would look as follows: primary destination address would look as follows:
+--------------------------------+ +--------------------------------+
| Type=0xC004 | Length = 16 | | Type=0xC004 | Length = 16 |
+--------------------------------+ +--------------------------------+
| C-ID = 0x01023479 | | C-ID = 0x01023479 |
+--------------------------------+ +--------------------------------+
| Type=5 | Length = 8 | | Type=5 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0a010101 | | Value=0xC0000201 |
+----------------+---------------+ +----------------+---------------+
Valid Chunk Appearance Valid Chunk Appearance
The Set Primary IP Address parameter may appear in the ASCONF Chunk, The Set Primary IP Address parameter may appear in the ASCONF Chunk,
the INIT, or the INIT-ACK chunk type. The inclusion of this the INIT, or the INIT-ACK chunk type. The inclusion of this
parameter in the INIT or INIT-ACK can be used to indicate an initial parameter in the INIT or INIT-ACK can be used to indicate an initial
preference of primary address. preference of primary address.
3.2.5. Success Indication 4.2.5. Success Indication
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 = 0xC005 | Length = 8 | | Type = 0xC005 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID | | ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
By default if a responding endpoint does not report an error for any By default if a responding endpoint does not report an error for any
skipping to change at page 13, line 12 skipping to change at page 14, line 6
request parameter. The receiver of the ASCONF Chunk will copy this request parameter. The receiver of the ASCONF Chunk will copy this
32 bit value from the ASCONF-Request Correlation ID into the ASCONF 32 bit value from the ASCONF-Request Correlation ID into the ASCONF
Response Correlation ID field so the peer can easily correlate the Response Correlation ID field so the peer can easily correlate the
request to this response. request to this response.
Valid Chunk Appearance Valid Chunk Appearance
The Success Indication parameter may only appear in the ASCONF-ACK The Success Indication parameter may only appear in the ASCONF-ACK
chunk type. chunk type.
3.2.6. Adaptation Layer Indication 4.2.6. Adaptation Layer Indication
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 =0xC006 | Length = 8 | | Type =0xC006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Code point | | Adaptation Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is specified for the communication of peer upper layer This parameter is specified for the communication of peer upper layer
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 adaptation code point in an to use this parameter MUST specify a an adaptation 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.
Note: that this parameter is not used in either the addition or
deletion of addresses but is for the convience of the upper layer.
This document includes this parameter to minimize the number of SCTP
documents.
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 an ASCONF Chunk. based upon the upper layer protocol configuration of the SCTP stack.
This parameter MUST NOT be sent in any other chunks and if it is
3.2.7. Supported Extensions Parameter received in another chunk it MUST be ignored.
This parameter is used at startup to identify any additional
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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE N | PAD | PAD | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type This field holds the IANA defined parameter type for
Supported Extensions Parameter. The suggested value of this field
for IANA is 0x8008.
Parameter Type Length This field holds the length of the parameter,
including the Parameter Type, Parameter Length and any addition
supported extensions. Note: the length MUST NOT include any
padding.
CHUNK TYPE X This field(s) hold the chunk type of any SCTP
extension(s) that are currently supported by the sending SCTP.
Multiple chunk types may be defined listing each additional
feature that the sender supports. The sender MUST NOT include
multiple Supported Extensions Parameter within any chunk.
Parameter Appearance This parameter may appear in the INIT or INIT-
ACK chunk. This parameter MUST NOT appear in any other chunk.
3.3. New Error Causes 4.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 5: New Error Causes Table 5: New Error Causes
3.3.1. Error Cause: Request to Delete Last Remaining IP Address 4.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
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
skipping to change at page 15, line 39 skipping to change at page 15, line 41
| C-ID = 0x01023476 | | C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Cause=0x0100 | Length = 20 | | Cause=0x0100 | Length = 20 |
+----------------+---------------+ +----------------+---------------+
| Type= 0xC002 | Length = 16 | | Type= 0xC002 | Length = 16 |
+----------------+---------------+ +----------------+---------------+
| C-ID = 0x01023476 | | C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Type=0x0005 | Length = 8 | | Type=0x0005 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0A010101 | | Value=0xC0000201 |
+----------------+---------------+ +----------------+---------------+
3.3.2. Error Cause: Operation Refused Due to Resource Shortage 4.3.2. Error Cause: Operation Refused Due to Resource Shortage
Cause of error Cause of error
This error cause is used to report a failure by the receiver to This error cause is used to report a failure by the receiver to
perform the requested operation due to a lack of resources. The perform the requested operation due to a lack of resources. The
entire TLV that is refused is copied from the ASCONF into the error entire TLV that is refused is copied from the ASCONF into the error
cause. cause.
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
skipping to change at page 16, line 30 skipping to change at page 16, line 30
| C-ID = 0x01023474 | | C-ID = 0x01023474 |
+--------------------------------+ +--------------------------------+
| Cause=0x0101 | Length = 20 | | Cause=0x0101 | Length = 20 |
+----------------+---------------+ +----------------+---------------+
| Type=0xC001 | Length = 16 | | Type=0xC001 | Length = 16 |
+--------------------------------+ +--------------------------------+
| C-ID = 0x01023474 | | C-ID = 0x01023474 |
+--------------------------------+ +--------------------------------+
| Type=0x0005 | Length = 8 | | Type=0x0005 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0A010101 | | Value=0xC0000201 |
+----------------+---------------+ +----------------+---------------+
3.3.3. Error Cause: Request to Delete Source IP Address 4.3.3. Error Cause: Request to Delete Source IP Address
Cause of error Cause of error
Request to Delete Source IP Address: The receiver of this error sent Request to Delete Source IP Address: The receiver of this error sent
a request to delete the source IP address of the ASCONF message. a request to delete the source IP address of the ASCONF message.
This error indicates that the request is rejected. This error indicates that the request is rejected.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 18 skipping to change at page 17, line 18
| C-ID = 0x01023476 | | C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Cause=0x0102 | Length = 20 | | Cause=0x0102 | Length = 20 |
+----------------+---------------+ +----------------+---------------+
| Type=0xC002 | Length = 16 | | Type=0xC002 | Length = 16 |
+----------------+---------------+ +----------------+---------------+
| C-ID = 0x01023476 | | C-ID = 0x01023476 |
+--------------------------------+ +--------------------------------+
| Type=0x0005 | Length = 8 | | Type=0x0005 | Length = 8 |
+----------------+---------------+ +----------------+---------------+
| Value=0x0A010101 | | Value=0xC0000201 |
+----------------+---------------+ +----------------+---------------+
IMPLEMENTATION NOTE: It is unlikely that an endpoint would source a IMPLEMENTATION NOTE: It is unlikely that an endpoint would source a
packet from the address being deleted, unless the endpoint does not packet from the address being deleted, unless the endpoint does not
do proper source address selection. do proper source address selection.
3.3.4. Error Cause: Association Aborted due to illegal ASCONF-ACK 4.3.4. Error Cause: Association Aborted due to illegal ASCONF-ACK
This error is to be included in an ABORT that is generated due to the This error is to be included in an ABORT that is generated due to the
reception of an ASCONF-ACK that was not expected but is larger than reception of an ASCONF-ACK that was not expected but is larger than
the current sequence number (see Section 4.3 Rule D0 ). Note: that a the current sequence number (see Section 5.3 Rule F0 ). Note: that a
sequence number is larger than the last acked sequence number if it sequence number is larger than the last ACKed sequence number if it
is either the next sequence or no more than 2^^31-1 greater than the is either the next sequence or no more than 2^^31-1 greater than the
current sequence number. current sequence number. Sequence numbers smaller than the last
acked sequence number are silently ignored.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x0103 | Cause Length=4 | | Cause Code=0x0103 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.5. Error Cause: Request refused - no authorization. 4.3.5. Error Cause: Request refused - no authorization.
Cause of error Cause of error
This error cause may be included to reject a request based on local This error cause may be included to reject a request based on local
security policies. security policies.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x0104 | Cause Length=Variable | | Cause Code=0x0104 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF / \ TLV-Copied-From-ASCONF /
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Procedures 5. Procedures
This section will lay out the specific procedures for address This section will lay out the specific procedures for address
configuration change chunk type and its processing. configuration change chunk type and its processing.
4.1. ASCONF Chunk Procedures 5.1. ASCONF Chunk Procedures
When an endpoint has an ASCONF signaled change to be sent to the When an endpoint has an ASCONF signaled change to be sent to the
remote endpoint it should do the following: remote endpoint it MUST do the following:
A1) Create an ASCONF Chunk as defined in Section 3.1.1. The chunk A1) Create an ASCONF Chunk as defined in Section 4.1.1. The chunk
should contain all of the TLV(s) of information necessary to be MUST contain all of the TLV(s) of information necessary to be sent
sent to the remote endpoint, and unique correlation identities for to the remote endpoint, and unique correlation identities for each
each request. request.
A2) A serial number should be assigned to the Chunk. The serial A2) A serial number MUST be assigned to the Chunk. The serial
number should be a monotonically increasing number. The serial number MUST be larger by one. The serial number MUST be
number MUST be initialized at the start of the association to the initialized at the start of the association to the same value as
same value as the Initial TSN and every time a new ASCONF Chunk is the Initial TSN and every time a new ASCONF Chunk is created it
created it is incremented by one after assigning the serial number MUST be incremented by one after assigning the serial number to
to the newly created chunk . the newly created chunk .
A3) If no SCTP packet with one or more ASCONF Chunk(s) is A3) If no SCTP packet with one or more ASCONF Chunk(s) is
outstanding (un-acknowledged) with the remote peer, send the outstanding (un-acknowledged) with the remote peer, send the
chunk. chunk.
A4) Start a T-4 RTO timer, using the RTO value of the selected A4) The sender MUST Start a T-4 RTO timer, using the RTO value of
destination address (normally the primary path; see RFC2960 the selected destination address (normally the primary path; see
[RFC2960] section 6.4 for details). RFC2960 [RFC2960] section 6.4 for details).
A5) When the ASCONF-ACK that acknowledges the serial number last A5) When the ASCONF-ACK that acknowledges the serial number last
sent arrives, stop the T-4 RTO timer, and clear the appropriate sent arrives, the sender MUST stop the T-4 RTO timer, and clear
association and destination error counters as defined in RFC2960 the appropriate association and destination error counters as
[RFC2960] section 8.1 and 8.2. defined in RFC2960 [RFC2960] section 8.1 and 8.2.
A6) Process all of the TLVs within the ASCONF-ACK(s) to find out A6) The endpoint MUST process all of the TLVs within the ASCONF-
particular status information returned to the various requests ACK(s) to find out particular status information returned to the
that were sent. Use the Correlation IDs to correlate the request various requests that were sent. Use the Correlation IDs to
and the responses. correlate the request and the responses.
A7) If an error response is received for a TLV parameter, all TLVs A7) If an error response is received for a TLV parameter, all TLVs
with no response before the failed TLV are considered successful with no response before the failed TLV are considered successful
if not reported. All TLVs after the failed response are if not reported. All TLVs after the failed response are
considered unsuccessful unless a specific success indication is considered unsuccessful unless a specific success indication is
present for the parameter. present for the parameter.
A8) If there is no response(s) to specific TLV parameter(s), and no A8) If there is no response(s) to specific TLV parameter(s), and no
failures are indicated, then all request(s) are considered failures are indicated, then all request(s) are considered
successful. successful.
A9) If the peer responds to an ASCONF with an ERROR chunk reporting A9) If the peer responds to an ASCONF with an ERROR chunk reporting
that it did not recognize the ASCONF Chunk type, the sender of the that it did not recognize the ASCONF Chunk type, the sender of the
ASCONF MUST NOT send any further ASCONF Chunks and MUST stop its ASCONF MUST NOT send any further ASCONF Chunks and MUST stop its
T-4 timer. T-4 timer.
If the T-4 RTO timer expires the endpoint should do the following: If the T-4 RTO timer expires the endpoint MUST do the following:
B1) Increment the error counters and perform path failure detection B1) Increment the error counters and perform path failure detection
on the appropriate destination address as defined in RFC2960 on the appropriate destination address as defined in RFC2960
[RFC2960] section 8.1 and 8.2. [RFC2960] section 8.1 and 8.2.
B2) Increment the association error counters and perform endpoint B2) Increment the association error counters and perform endpoint
failure detection on the association as defined in RFC2960 failure detection on the association as defined in RFC2960
[RFC2960] section 8.1 and 8.2. [RFC2960] section 8.1 and 8.2.
B3) Back-off the destination address RTO value to which the ASCONF B3) Back-off the destination address RTO value to which the ASCONF
chunk was sent by doubling the RTO timer value. chunk was sent by doubling the RTO timer value.
Note: The RTO value is used in the setting of all timer types for Note: The RTO value is used in the setting of all timer types for
SCTP. Each destination address has a single RTO estimate. SCTP. Each destination address has a single RTO estimate.
B4) Re-transmit the ASCONF Chunk last sent and if possible choose an B4) Re-transmit the ASCONF Chunk last sent and if possible choose an
alternate destination address (please refer to RFC2960 [RFC2960] alternate destination address (please refer to RFC2960 [RFC2960]
section 6.4.1). An endpoint MUST NOT add new parameters to this section 6.4.1). An endpoint MUST NOT add new parameters to this
chunk, it MUST be the same (including its serial number) as the chunk, it MUST be the same (including its serial number) as the
last ASCONF sent. An endpoint can, however, bundle an additional last ASCONF sent. An endpoint MAY, however, bundle an additional
ASCONF with new ASCONF parameters with the next sequence number. ASCONF with new ASCONF parameters with the next sequence number.
For details see Section 4.5 For details see Section 5.5
B5) Restart the T-4 RTO timer. Note: that if a different B5) Restart the T-4 RTO timer. Note: that if a different
destination is selected, then the RTO used will be that of the new destination is selected, then the RTO used will be that of the new
destination address. destination address.
Note: the total number of re-transmissions is limited by B2 above. Note: the total number of re-transmissions is limited by B2 above.
If the maximum is reached, the association will fail and enter into If the maximum is reached, the association will fail and enter into
the CLOSED state (see RFC2960 [RFC2960] section 6.4.1 for details). the CLOSED state (see RFC2960 [RFC2960] section 6.4.1 for details).
4.1.1. Congestion Control of ASCONF Chunks 5.1.1. Congestion Control of ASCONF Chunks
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:
C1) One and only one SCTP packet holding ASCONF Chunk(s) MAY be in C1) One and only one SCTP packet holding ASCONF Chunk(s) MAY be in
transit and unacknowledged at any one time. If a sender, after transit and unacknowledged at any one time. If a sender, after
sending an ASCONF chunk, decides it needs to transfer another sending an ASCONF chunk, decides it needs to transfer another
ASCONF Chunk, it MUST wait until the ASCONF-ACK Chunk returns from ASCONF Chunk, it MUST wait until the ASCONF-ACK Chunk returns from
the previous ASCONF Chunk before sending a subsequent ASCONF. the previous ASCONF Chunk before sending a subsequent ASCONF.
Note: this restriction binds each side, so at any time two ASCONF Note: this restriction binds each side, so at any time two ASCONF
may be in-transit on any given association (one sent from each may be in-transit on any given association (one sent from each
endpoint). However when an ASCONF Chunk is retransmitted due to a endpoint). However when an ASCONF Chunk is retransmitted due to a
time-out, the additional held ASCONF Chunks can be bundled into time-out, the additional held ASCONF Chunks can be bundled into
the retransmission packet as described in Section 4.5. the retransmission packet as described in Section 5.5.
C2) An ASCONF Chunk may be bundled with any other chunk type C2) An ASCONF Chunk may be bundled with any other chunk type
including other ASCONF Chunks. If bundled with other ASCONF including other ASCONF Chunks. If bundled with other ASCONF
Chunks, the chunks MUST appear in sequential order with respect to Chunks, the chunks MUST appear in sequential order with respect to
their Serial Number. their Serial Number.
C3) An ASCONF-ACK Chunk may be bundled with any other chunk type C3) An ASCONF-ACK Chunk may be bundled with any other chunk type
including other ASCONF-ACK Chunks. If bundled with other ASCONF- including other ASCONF-ACK Chunks. If bundled with other ASCONF-
ACK Chunks, the chunks MUST appear in sequential order with ACK Chunks, the chunks MUST appear in sequential order with
respect to their Serial Number. respect to their Serial Number.
C4) Both ASCONF and ASCONF-ACK Chunks MUST NOT be sent in any SCTP C4) 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.
C5) An ASCONF Chunk and an ASCONF-ACK Chunk SHOULD not be larger C5) An ASCONF Chunk and an ASCONF-ACK Chunk SHOULD not be larger
than the path MTU. than the path MTU. If the path MTU is unknown, then the path MTU
should be set to a minimal path MTU. The minimum PMTU depends on
the IP version used for transmission, and is the lesser of 576
octets and the first-hop MTU for IPv4 RFC1122 [RFC1122] and 1280
octets for IPv6 RFC2460 [RFC2460].
A ASCONF sender without these restrictions could possibly flood the
network with a large number of seperate address change operations
thus causing network congestion.
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
endpoint should also inform the upper layer application that the peer endpoint should also inform the upper layer application that the peer
endpoint does not support any of the extensions detailed in this endpoint does not support any of the extensions detailed in this
document. document.
4.2. Upon reception of an ASCONF Chunk. 5.2. Upon reception of an ASCONF Chunk.
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:
D1) Use the source address and port number of the sender to attempt D1) 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 [RFC2960] used for all other SCTP Chunks). If found RFC2960 [RFC2960] used for all other SCTP Chunks). If found
proceed to rule D4. proceed to rule D4.
D2) If the association is not found, use the address found in the D2) 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 D4. SCTP common header. If found proceed to rule D4.
skipping to change at page 23, line 26 skipping to change at page 23, line 26
MAY log the event for security purposes. MAY log the event for security purposes.
E6) When all ASCONF Chunks are processed for this SCTP packet, send E6) When all ASCONF Chunks are processed for this SCTP packet, send
back the accumulated single response packet with all of the back the accumulated single response packet with all of the
ASCONF-ACK Chunks. The destination address of the SCTP packet ASCONF-ACK Chunks. The destination address of the SCTP packet
containing the ASCONF-ACK Chunks MUST be the source address of the containing the ASCONF-ACK Chunks MUST be the source address of the
SCTP packet that held the ASCONF Chunks. SCTP packet that held the ASCONF Chunks.
E7) While processing the ASCONF Chunks in the SCTP packet, if the E7) While processing the ASCONF Chunks in the SCTP packet, if the
response packet will exceed the PMTU of the return path, the response packet will exceed the PMTU of the return path, the
receiver MUST stop adding addtional ASCONF-ACK's into the response receiver MUST stop adding additional ASCONF-ACKs into the response
packet but MUST continue to process all of the ASCONF Chunks, packet but MUST continue to process all of the ASCONF Chunks,
saving ASCONF-ACK Chunk responses in its cached copy. The sender saving ASCONF-ACK Chunk responses in its cached copy. The sender
of the ASCONF Chunk will later retransmit the ASCONF Chunks that of the ASCONF Chunk will later retransmit the ASCONF Chunks that
were not responded to, at which time the cached copies of the were not responded to, at which time the cached copies of the
responses that would NOT fit in the PMTU can be sent to the peer. responses that would NOT fit in the PMTU can be sent to the peer.
Note: These rules have been presented with the assumption that the Note: These rules have been presented with the assumption that the
implementation is caching old ASCONF-ACK's in case of loss of SCTP implementation is caching old ASCONF-ACKs in case of loss of SCTP
packets in the ACK path. It is allowable for an implementation to packets in the ACK path. It is allowable for an implementation to
maintain this state in another form it deems appropriate, as long as maintain this state in another form it deems appropriate, as long as
that form results in the same ASCONF-ACK sequences being returned to that form results in the same ASCONF-ACK sequences being returned to
the peer as outlined above. the peer as outlined above.
4.3. General rules for address manipulation 5.3. General rules for address manipulation
When building TLV parameters for the ASCONF Chunk that will add or When building TLV parameters for the ASCONF Chunk that will add or
delete IP addresses the following rules should be applied: delete IP addresses the following rules MUST be applied:
F0) If an endpoint receives an ASCONF-ACK that is greater than or F0) If an endpoint receives an ASCONF-ACK that is greater than or
equal to the next serial number to be used but no ASCONF Chunk is equal to the next serial number to be used but no ASCONF Chunk is
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).
F1) When adding an IP address to an association, the IP address is F1) 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
skipping to change at page 24, line 43 skipping to change at page 24, line 43
the peer. the peer.
F4) When deleting an IP address from an association, the IP address F4) 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
address being deleted MUST be considered part of the current address being deleted MUST be considered part of the current
association. One special consideration is that ABORT Chunks association. One special consideration is that ABORT Chunks
arriving destined to the IP address being deleted MUST be ignored arriving destined to the IP address being deleted MUST be ignored
(see Section 4.3.1 for further details). (see Section 5.3.1 for further details).
F5) An endpoint MUST NOT delete its last remaining IP address from F5) An endpoint MUST NOT delete its last remaining IP address from
an association. In other words if an endpoint is NOT multi-homed an association. In other words if an endpoint is NOT multi-homed
it MUST NOT use the delete IP address without an add IP address it MUST NOT use the delete IP address without an add IP address
preceding the delete parameter in the ASCONF Chunk. Or if an preceding the delete parameter in the ASCONF Chunk. Or if an
endpoint sends multiple requests to delete IP addresses it MUST endpoint sends multiple requests to delete IP addresses it MUST
NOT delete all of the IP addresses that the peer has listed for NOT delete all of the IP addresses that the peer has listed for
the requester. the requester.
F6) An endpoint MUST NOT set an IP header source address for an SCTP F6) An endpoint MUST NOT set an IP header source address for an SCTP
skipping to change at page 27, line 21 skipping to change at page 27, line 21
For the DELETE case, an endpoint MAY respond to the late arriving For the DELETE case, an endpoint MAY respond to the late arriving
DATA packet as an OOTB datagram or it MAY hold the deleting IP DATA packet as an OOTB datagram or it MAY hold the deleting IP
address for a small period of time as still valid. If it treats the address for a small period of time as still valid. If it treats the
DATA packet as an OOTB the peer will silently discard the ABORT DATA packet as an OOTB the peer will silently discard the ABORT
(since by the time the ABORT is sent the peer will have removed the (since by the time the ABORT is sent the peer will have removed the
IP address from this association). If the endpoint elects to hold IP address from this association). If the endpoint elects to hold
the IP address valid for a period of time, it MUST NOT hold it valid the IP address valid for a period of time, it MUST NOT hold it valid
longer than 2 RTO intervals for the destination being removed. longer than 2 RTO intervals for the destination being removed.
4.3.1. A special case for OOTB ABORT Chunks 5.3.1. A special case for OOTB ABORT Chunks
Another case worth mentioning is illustrated below: Another case worth mentioning is illustrated below:
Endpoint-A Endpoint-Z Endpoint-A Endpoint-Z
---------- ---------- ---------- ----------
New DATA:------------\ New DATA:------------\
Source IP:X \ Source IP:X \
\ \
ASCONF-REQ[DEL-IP:X]----\------------------> ASCONF-REQ[DEL-IP:X]----\------------------>
skipping to change at page 27, line 43 skipping to change at page 27, line 43
\ / \ /
\----/-----------> OOTB \----/-----------> OOTB
(Ignored <---------------------/-------------ABORT (Ignored <---------------------/-------------ABORT
by rule D4) / by rule D4) /
<---------------------/ <---------------------/
For this case, during the deletion of an IP address, an Abort MUST be For this case, during the deletion of an IP address, an Abort MUST be
ignored if the destination address of the Abort message is that of a ignored if the destination address of the Abort message is that of a
destination being deleted. destination being deleted.
4.3.2. A special case for changing an address. 5.3.2. A special case for changing an address.
In some instances the sender may only have one IP address in an In some instances the sender may only have one IP address in an
association that is being renumbered. When this occurs, the sender association that is being renumbered. When this occurs, the sender
may not be able to send to the peer the appropriate ADD/DELETE pair may not be able to send to the peer the appropriate ADD/DELETE pair
and use the old address as a source in the IP header. For this and use the old address as a source in the IP header. For this
reason the sender MUST fill in the Address Parameter field with an reason the sender MUST fill in the Address Parameter field with an
address that is part of the association (in this case the one being address that is part of the association (in this case the one being
deleted). This will allow the receiver to locate the association deleted). This will allow the receiver to locate the association
without using the source address found in the IP header. without using the source address found in the IP header.
The receiver of such a chunk MUST always first use the source address The receiver of such a chunk MUST always first use the source address
found in the IP header in looking up the association. The receiver found in the IP header in looking up the association. The receiver
should attempt to use the address found in the Address Bytes field should attempt to use the address found in the Address Bytes field
only if the lookup fails using the source address from the IP header. only if the lookup fails using the source address from the IP header.
The receiver MUST reply to the source address of the packet in this The receiver MUST reply to the source address of the packet in this
case which is the new address that was added by the ASCONF (since the case which is the new address that was added by the ASCONF (since the
old address is no longer a part of the association after processing). old address is no longer a part of the association after processing).
4.4. Setting of the primary address 5.4. Setting of the primary address
A sender of this option may elect to send this combined with a A sender of this option may elect to send this combined with a
deletion or addition of an address. A sender SHOULD only send a set deletion or addition of an address. A sender SHOULD only send a set
primary request to an address that is already considered part of the primary request to an address that is already considered part of the
association. In other words if a sender combines a set primary with association. In other words if a sender combines a set primary with
an add of a new IP address the set primary will be discarded unless an add of a new IP address the set primary will be discarded unless
the add request is to be processed BEFORE the set primary (i.e. it the add request is to be processed BEFORE the set primary (i.e. it
precedes the set primary). precedes the set primary).
A request to set primary MAY also appear in an INIT or INIT-ACK A request to set primary MAY also appear in an INIT or INIT-ACK
chunk. This can give advice to the peer endpoint as to which of its chunk. This can give advice to the peer endpoint as to which of its
addresses the sender of the INIT or INIT-ACK would prefer to be used addresses the sender of the INIT or INIT-ACK would prefer to be used
as the primary address. as the primary address.
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 requester's view). If a request arrives that asks the receiver to
an address as primary that does not exist, the receiver should NOT set an address as primary that does not exist, the receiver should
honor the request, leaving its existing primary address unchanged. NOT honor the request, leaving its existing primary address
unchanged.
4.5. Bundling of multiple ASCONFs 5.5. Bundling of multiple ASCONFs
In the normal case a single ASCONF is sent in a packet and a single In the normal case a single ASCONF is sent in a packet and a single
reply ASCONF-ACK is received. However, in the event of the loss of reply ASCONF-ACK is received. However, in the event of the loss of
an SCTP packet containing either an ASCONF or ASCONF-ACK it is an SCTP packet containing either an ASCONF or ASCONF-ACK it is
allowable for a sender to bundle additional ASCONF's in the allowable for a sender to bundle additional ASCONFs in the
retransmission. In bundling multiple ASCONF's the following rules retransmission. In bundling multiple ASCONFs the following rules
MUST be followed: MUST be followed:
1. Previously transmitted ASCONF Chunks MUST be left unchanged. 1. Previously transmitted ASCONF Chunks MUST be left unchanged.
2. Each SCTP packet containing ASCONF Chunks MUST be bundled 2. Each SCTP packet containing ASCONF Chunks MUST be bundled
starting with the smallest ASCONF Serial Number first in the starting with the smallest ASCONF Serial Number first in the
packet (closest to the Chunk header) and preceeding in sequential packet (closest to the Chunk header) and preceding in sequential
order from lowest to highest ASCONF Serial Number. order from lowest to highest ASCONF Serial Number.
3. All ASCONF's within the packet MUST be adjacent to each other 3. All ASCONFs within the packet MUST be adjacent to each other i.e.
i.e. no other chunk type must seperate the ASCONF's. no other chunk type must separate the ASCONFs.
4. Each new ASCONF's lookup address MUST be populated as if the 4. Each new ASCONFs lookup address MUST be populated as if the
previous ASCONF's had been processed and accepted. previous ASCONFs had been processed and accepted.
5. Security Considerations 6. Security Considerations
The addition and or deletion of an IP address to an existing The addition and or deletion of an IP address to an existing
association does provide an additional mechanism by which existing association does provide an additional mechanism by which existing
associations can be hijacked. Therefore this document requires the associations can be hijacked. Therefore this document requires the
use of the authentication mechanism defined in SCTP-AUTH use of the authentication mechanism defined in SCTP-AUTH
[I-D.ietf-tsvwg-sctp-auth] to limit the ability of an attacker to [I-D.ietf-tsvwg-sctp-auth] to limit the ability of an attacker to
hijack an association. hijack an association.
Hijacking an association by using the addition and deletion of an IP Hijacking an association by using the addition and deletion of an IP
address is only possible for an attacker who is able to intercept the address is only possible for an attacker who is able to intercept the
skipping to change at page 29, line 44 skipping to change at page 29, line 44
implementation allowed to proceed with the association setup by implementation allowed to proceed with the association setup by
sending an INIT-ACK in response. sending an INIT-ACK in response.
An implementation that receives an INIT-ACK that indicates that the An implementation that receives an INIT-ACK that indicates that the
peer does not support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] peer does not support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]
extension MUST NOT send the COOKIE-ECHO to establish the association. extension MUST NOT send the COOKIE-ECHO to establish the association.
Instead the implementation MUST discard the INIT-ACK and report to Instead the implementation MUST discard the INIT-ACK and report to
the upper layer user that an association cannot be established the upper layer user that an association cannot be established
destroying the TCB. destroying the TCB.
6. IANA considerations 7. IANA considerations
This document defines the following new SCTP parameters, chunks and This document defines the following new SCTP parameters, chunks and
errors: errors (http://www.iana.org/assignments/sctp-parameters):
o Two new chunk types, o Two new chunk types,
o Seven parameter types, and o Six 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. The second chunk type must come from the range where 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 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. The available code point with the upper bit set is also acceptable. The
suggested chunk types are listed in Table 1. chunk types with there suggested values are shown below.
All but one of the parameter types must come from the range of types Chunk Type Chunk Name
where the upper two bits are set, we recommend 0xC001 - 0xC006, as --------------------------------------------------------------
specified in this document. The other parameter type must come from 0xC1 Address Configuration Change Chunk (ASCONF)
the 0x8000 range, we recommend 0x8008. Note: that for any of these 0x80 Address Configuration Acknowledgment (ASCONF-ACK)
values a different unique parameter type may be assigned by IANA as
long as the upper bits correspond to the ones specified in this All of the parameter types must come from the range of types where
document. The suggested parameter types are listed in Table 2, Table the upper two bits are set, we recommend 0xC001 - 0xC006, as shown
3, and Table 4. below. Note: that for any of these values a different unique
parameter type may be assigned by IANA as long as the upper bits
correspond to the ones specified in this document. The suggested
parameter types are listed below:
Parameter Type Parameter Name
-------------------------------------------------
0xC001 Add IP Address
0xC002 Delete IP Address
0xC003 Error Cause Indication
0xC004 Set Primary Address
0xC005 Success Indication
0xC006 Adaptation Layer Indication
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 separate 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. The suggested error causes are listed in Table 5. acceptable. The suggested error causes are listed below:.
This document also defines a Adaptation code point. The adaptation Cause Code
Value Cause Code
--------- ----------------
0x0100 Request to Delete Last Remaining IP Address.
0x0101 Operation Refused Due to Resource Shortage.
0x0102 Request to Delete Source IP Address.
0x0103 Association Aborted due to illegal ASCONF-ACK
0x0104 Request refused - no authorization.
This document also defines an 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]. For this new
registry no initial values are being added by this document, however
draft-ietf-rddp-sctp will add the first entry.
7. Acknowledgments 8. Acknowledgments
The authors would like to express a special note of thanks to Michael The authors would like to express a special note of thanks to Michael
Ramahlo and Phillip Conrad for there extreme efforts in the early Ramahlo and Phillip Conrad for there extreme efforts in the early
formation of this draft. formation of this draft.
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.
The authors would also like to give special mention to Maria-Carmen The authors would also like to give special mention to Maria-Carmen
Belinchon and Ian Rytina for there early contributions to this Belinchon and Ian Rytina for there early contributions to this
document and their thoughtful comments. document and their thoughtful comments.
8. References 9. References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[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-06 (work in progress), draft-ietf-tsvwg-sctp-auth-07 (work in progress),
November 2006. January 2007.
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 This appendix is non-normative. It is present to give the reader a
notion to discuss address reconfiguration. It is not intended to concise mathematical definition of an SCTP endpoint. The following
restrict implementations in any way, its goal is to provide as set of text provides a working definition of the endpoint notion to discuss
address reconfiguration. It is not intended to restrict
implementations in any way, its goal is to provide a 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.
A.2. Generalized endpoints A.2. Generalized endpoints
A generalized endpoint is a pair of a set of IP addresses and a port A generalized endpoint is a pair of a set of IP addresses and a port
number at any given point of time. The precise definition is as number at any given point of time. The precise definition is as
follows: follows:
A generalized endpoint gE at time t is given by A generalized endpoint gE at time t is given by
skipping to change at page 36, line 7 skipping to change at page 37, line 7
Yoshida-Honmachi Yoshida-Honmachi
Sakyo-ku Sakyo-ku
Kyoto, Kyoto 606-8501 Kyoto, Kyoto 606-8501
JAPAN JAPAN
Phone: +81-75-753-7468 Phone: +81-75-753-7468
Email: ma-kun@kozuka.jp Email: ma-kun@kozuka.jp
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 105 change blocks. 
246 lines changed or deleted 299 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/