draft-ietf-tsvwg-addip-sctp-20.txt   draft-ietf-tsvwg-addip-sctp-21.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: October 7, 2007 Motorola, Inc. Expires: December 14, 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
April 5, 2007 June 12, 2007
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-20.txt draft-ietf-tsvwg-addip-sctp-21.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 October 7, 2007. This Internet-Draft will expire on December 14, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes extensions to the Stream Control Transmission A local host may have multiple points of attachment to the Internet,
Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP giving it a degree of fault tolerance from hardware failures. Stream
address information on an existing association. Control Transmission Protocol (SCTP) SCTP-BIS
[I-D.ietf-tsvwg-2960bis] 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. This document
describes an extension to SCTP that will allow an SCTP stack to
dynamically add an IP Addresses to an SCTP association, dynamically
delete an IP addresses from an SCTP association, and to request to
set the primary address the peer will use when sending to an
endpoint.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Serial Number Arithmetic . . . . . . . . . . . . . . . . . . . 5 3. Serial Number Arithmetic . . . . . . . . . . . . . . . . . . . 6
4. Additional Chunks and Parameters . . . . . . . . . . . . . . . 5 4. Additional Chunks and Parameters . . . . . . . . . . . . . . . 6
4.1. New Chunk Types . . . . . . . . . . . . . . . . . . . . . 5 4.1. New Chunk Types . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Address Configuration Change Chunk (ASCONF) . . . . . 6 4.1.1. Address Configuration Change Chunk (ASCONF) . . . . . 7
4.1.2. Address Configuration Acknowledgment Chunk 4.1.2. Address Configuration Acknowledgment Chunk
(ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 7 (ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 8
4.2. New Parameter Types . . . . . . . . . . . . . . . . . . . 8 4.2. New Parameter Types . . . . . . . . . . . . . . . . . . . 9
4.2.1. Add IP Address . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Add IP Address . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Delete IP Address . . . . . . . . . . . . . . . . . . 10 4.2.2. Delete IP Address . . . . . . . . . . . . . . . . . . 11
4.2.3. Error Cause Indication . . . . . . . . . . . . . . . . 11 4.2.3. Error Cause Indication . . . . . . . . . . . . . . . . 12
4.2.4. Set Primary IP Address . . . . . . . . . . . . . . . . 12 4.2.4. Set Primary IP Address . . . . . . . . . . . . . . . . 13
4.2.5. Success Indication . . . . . . . . . . . . . . . . . . 13 4.2.5. Success Indication . . . . . . . . . . . . . . . . . . 14
4.2.6. Adaptation Layer Indication . . . . . . . . . . . . . 14 4.2.6. Adaptation Layer Indication . . . . . . . . . . . . . 15
4.2.7. Supported Extensions Parameter . . . . . . . . . . . . 14 4.2.7. Supported Extensions Parameter . . . . . . . . . . . . 15
4.3. New Error Causes . . . . . . . . . . . . . . . . . . . . . 15 4.3. New Error Causes . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Error Cause: Request to Delete Last Remaining IP 4.3.1. Error Cause: Request to Delete Last Remaining IP
Address . . . . . . . . . . . . . . . . . . . . . . . 16 Address . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.2. Error Cause: Operation Refused Due to Resource 4.3.2. Error Cause: Operation Refused Due to Resource
Shortage . . . . . . . . . . . . . . . . . . . . . . . 16 Shortage . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.3. Error Cause: Request to Delete Source IP Address . . . 17 4.3.3. Error Cause: Request to Delete Source IP Address . . . 18
4.3.4. Error Cause: Association Aborted due to illegal 4.3.4. Error Cause: Association Aborted due to illegal
ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 18 ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 19
4.3.5. Error Cause: Request refused - no authorization. . . . 18 4.3.5. Error Cause: Request refused - no authorization. . . . 19
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 19 5.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 20
5.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 21 5.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 22
5.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 22 5.2. Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 23
5.3. General rules for address manipulation . . . . . . . . . . 24 5.3. General rules for address manipulation . . . . . . . . . . 26
5.3.1. A special case for OOTB ABORT Chunks . . . . . . . . . 28 5.3.1. A special case for OOTB ABORT Chunks . . . . . . . . . 29
5.3.2. A special case for changing an address. . . . . . . . 28 5.3.2. A special case for changing an address. . . . . . . . 30
5.4. Setting of the primary address . . . . . . . . . . . . . . 29 5.4. Setting of the primary address . . . . . . . . . . . . . . 30
5.5. Bundling of multiple ASCONFs . . . . . . . . . . . . . . . 29 5.5. Bundling of multiple ASCONFs . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
9. Normative References . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 33 9.1. Normative References . . . . . . . . . . . . . . . . . . . 34
A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 33 9.2. Informative References . . . . . . . . . . . . . . . . . . 35
A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 33 Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 35
A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 34 A.1. General remarks . . . . . . . . . . . . . . . . . . . . . 35
A.4. Relationship with RFC 2960 . . . . . . . . . . . . . . . . 35 A.2. Generalized endpoints . . . . . . . . . . . . . . . . . . 35
A.5. Rules for address manipulation . . . . . . . . . . . . . . 35 A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 A.4. Relationship with RFC 4960 . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38 A.5. Rules for address manipulation . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 40
1. Introduction 1. Introduction
A local host may have multiple points of attachment to the Internet, A local host may have multiple points of attachment to the Internet,
giving it a degree of fault tolerance from hardware failures. SCTP giving it a degree of fault tolerance from hardware failures. SCTP
was developed to take full advantage of such a multi-homed host 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 provide a fast failover and association survivability in the face of
such hardware failures. However, many modern computers allow for the such hardware failures. However, many modern computers allow for the
dynamic addition and deletion of network cards (sometimes termed a dynamic addition and deletion of network cards (sometimes termed a
hot-pluggable interface). Complicate this with the ability of a hot-pluggable interface). Complicate this with the ability of a
skipping to change at page 5, line 24 skipping to change at page 6, line 24
programming the comparison of such values. When referring to ASCONF programming the comparison of such values. When referring to ASCONF
Sequence Numbers, the symbol "=<" means "less than or equal"(modulo Sequence Numbers, the symbol "=<" means "less than or equal"(modulo
2**32). 2**32).
Comparisons and arithmetic on ASCONF sequence numbers in this Comparisons and arithmetic on ASCONF sequence numbers in this
document SHOULD use Serial Number Arithmetic as defined in [RFC1982] document SHOULD use Serial Number Arithmetic as defined in [RFC1982]
where SERIAL_BITS = 32. where SERIAL_BITS = 32.
ASCONF Sequence Numbers wrap around when they reach 2**32 - 1. That ASCONF Sequence Numbers wrap around when they reach 2**32 - 1. That
is, the next ASCONF Sequence Number an ASCONF chunk MUST use after is, the next ASCONF Sequence Number an ASCONF chunk MUST use after
transmitting ASCONF Sequence Number = 2*32 - 1 is 0. transmitting ASCONF Sequence Number = 2**32 - 1 is 0.
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document uses normal All other arithmetic and comparisons in this document uses normal
arithmetic. arithmetic.
4. Additional Chunks and Parameters 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:
skipping to change at page 6, line 18 skipping to change at page 7, line 18
0x80 Address Configuration Acknowledgment (ASCONF-ACK) 0x80 Address Configuration Acknowledgment (ASCONF-ACK)
Table 1: Address Configuration Chunks Table 1: Address Configuration Chunks
4.1.1. Address Configuration Change Chunk (ASCONF) 4.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 SCTP-BIS [I-D.ietf-tsvwg-2960bis] for all
This chunk MUST be sent in an authenticated way by using the variable parameters. This chunk MUST be sent in an authenticated way
mechanism defined in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]. If this by using the mechanism defined in SCTP-AUTH
chunk is received unauthenticated it MUST be silently discarded as [I-D.ietf-tsvwg-sctp-auth]. If this chunk is received
described in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]. unauthenticated it MUST be silently discarded as described in SCTP-
AUTH [I-D.ietf-tsvwg-sctp-auth].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC1 | Chunk Flags | Chunk Length | | Type = 0xC1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #1 | | ASCONF Parameter #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ .... / / .... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #N | | ASCONF Parameter #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serial Number : 32 bits (unsigned integer) Sequence Number : 32 bits (unsigned integer)
This value represents a Serial Number for the ASCONF Chunk. The This value represents a Sequence Number for the ASCONF Chunk. The
valid range of Serial Number is from 0 to 4294967295 (2**32 - 1). valid range of Sequence Number is from 0 to 4294967295 (2**32 - 1).
Serial Numbers wrap back to 0 after reaching 4294967295. Sequence Numbers wrap back to 0 after reaching 4294967295.
Address Parameter : 8 or 20 bytes (depending on the address 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 SCTP-BIS [I-D.ietf-tsvwg-2960bis]. The address is an address of the
ASCONF Chunk, the address MUST be considered part of the association sender of the ASCONF Chunk, the address MUST be considered part of
by the peer endpoint (the receiver of the ASCONF Chunk). This field the association by the peer endpoint (the receiver of the ASCONF
may be used by the receiver of the ASCONF to help in finding the Chunk). This field may be used by the receiver of the ASCONF to help
association. If the address 0.0.0.0 or ::0 is provided the receiver in finding the association. If the address 0.0.0.0 or ::0 is
MAY lookup the association by other information provided in the provided the receiver MAY lookup the association by other information
packet. This parameter MUST be present in every ASCONF message i.e. provided in the packet. This parameter MUST be present in every
it is a mandatory TLV parameter. ASCONF message, i.e. it is a mandatory TLV parameter.
Note: the host name address MUST NOT be sent and MUST be ignored if Note: the host name address MUST NOT be sent and MUST be ignored if
received in any ASCONF message. received in any ASCONF message.
It should be noted that the ASCONF Chunk format requires the receiver 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. 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 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 described in SCTP-BIS [I-D.ietf-tsvwg-2960bis]. section 3.2. Note
bits in the ASCONF Chunk are set to one. As defined in RFC2960 that the upper two bits in the ASCONF Chunk are set to one. As
[RFC2960] section 3.2, when setting these upper bits in this manner defined in SCTP-BIS [I-D.ietf-tsvwg-2960bis] section 3.2, when
the receiver that does not understand this chunk MUST skip the chunk setting these upper bits in this manner the receiver that does not
and continue processing, and report in an Operation Error Chunk using understand this chunk MUST skip the chunk and continue processing,
the 'Unrecognized Chunk Type' cause of error. This will NOT abort and report in an Operation Error Chunk using the 'Unrecognized Chunk
the association but indicates to the sender that it MUST not send any Type' cause of error. This will NOT abort the association but
further ASCONF chunks. 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 4.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.
4.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
skipping to change at page 8, line 10 skipping to change at page 9, line 10
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x80 | Chunk Flags | Chunk Length | | Type = 0x80 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#1 | | ASCONF Parameter Response#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ .... / / .... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#N | | ASCONF Parameter Response#N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serial Number : 32 bits (unsigned integer) Sequence Number : 32 bits (unsigned integer)
This value represents the Serial Number for the received ASCONF Chunk This value represents the Sequence Number for the received ASCONF
that is acknowledged by this chunk. This value is copied from the Chunk that is acknowledged by this chunk. This value is copied from
received ASCONF Chunk. the received ASCONF Chunk.
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 Sequence Number.
4.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 describe the 3.2.1 of SCTP-BIS [I-D.ietf-tsvwg-2960bis]. Tables 2, 3 and 4
parameters. describe the 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 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
------------------------------------------------- -------------------------------------------------
skipping to change at page 10, line 4 skipping to change at page 11, line 4
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 into the ASCONF Response Correlation ID field of the 32 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. Note that the receiver MUST NOT change this 32 bit value. 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 SCTP-BIS [I-D.ietf-tsvwg-2960bis]. The complete TLV is
this parameter. It informs the receiver that the address specified wrapped within this parameter. It informs the receiver that the
is to be added to the existing association. This parameter MUST NOT address specified is to be added to the existing association. This
contain a broadcast or multicast address. If the address 0.0.0.0 or parameter MUST NOT contain a broadcast or multicast address. If the
::0 is provided, the source address of the packet MUST be added. address 0.0.0.0 or ::0 is provided, the source address of the packet
MUST be added.
An example TLV requesting that the IPv4 address 192.0.2.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 |
skipping to change at page 10, line 50 skipping to change at page 12, line 4
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. The receiver of the ASCONF Chunk will copy this request parameter. The receiver of the ASCONF Chunk will copy this
32 bit value into the ASCONF Response Correlation ID field of the 32 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. Note that the receiver MUST NOT change this 32 bit value. 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 SCTP-BIS [I-D.ietf-tsvwg-2960bis]. The complete TLV is
this parameter. It informs the receiver that the address specified wrapped within this parameter. It informs the receiver that the
is to be removed from the existing association. This parameter MUST address specified is to be removed from the existing association.
NOT contain a broadcast or multicast address. If the address 0.0.0.0 This parameter MUST NOT contain a broadcast or multicast address. If
or ::0 is provided, all addresses of the peer except the source the address 0.0.0.0 or ::0 is provided, all addresses of the peer
address of the packet MUST be deleted. except the source address of the packet MUST be deleted.
An example TLV deleting the IPv4 address 192.0.2.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 |
skipping to change at page 11, line 38 skipping to change at page 12, line 39
4.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 Success Indication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. Note that the receiver MUST NOT change request to this response. Note that the receiver MUST NOT change
this 32 bit value. 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 SCTP-BIS
The Error Cause(s) follow the format defined in section 3.3.10 of [I-D.ietf-tsvwg-2960bis]). The Error Cause(s) follow the format
RFC2960 [RFC2960]. defined in section 3.3.10 of SCTP-BIS [I-D.ietf-tsvwg-2960bis].
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.
4.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
skipping to change at page 12, line 39 skipping to change at page 13, line 39
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 into the ASCONF Response Correlation ID field of the 32 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. Note that the receiver MUST NOT change this 32 bit value. 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 SCTP-BIS [I-D.ietf-tsvwg-2960bis]. The complete TLV is
this parameter. It requests the receiver to mark the specified wrapped within this parameter. It requests the receiver to mark the
address as the primary address to send data to (see section 5.1.2 of specified address as the primary address to send data to (see section
RFC2960 [RFC2960]). The receiver MAY mark this as its primary upon 5.1.2 of SCTP-BIS [I-D.ietf-tsvwg-2960bis]). The receiver MAY mark
receiving this request. If the address 0.0.0.0 or ::0 is provided, this as its primary upon receiving this request. If the address
the receiver MAY mark the source address of the packet as its 0.0.0.0 or ::0 is provided, the receiver MAY mark the source address
primary. of the packet as its primary.
An example TLV requesting that the IPv4 address 192.0.2.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=0xC0000201 | | 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, the
the INIT, or the INIT-ACK chunk type. The inclusion of this INIT, or the INIT-ACK chunk type. The inclusion of this parameter in
parameter in the INIT or INIT-ACK can be used to indicate an initial the INIT or INIT-ACK can be used to indicate an initial preference of
preference of primary address. primary address.
4.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
requested TLV, a success is implicitly indicated. Thus a sender of a requested TLV, a success is implicitly indicated. Thus a sender of a
ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by
returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8)
and the Serial Number. and the Sequence Number.
The responding endpoint MAY also choose to explicitly report a The responding endpoint MAY also choose to explicitly report a
success for a requested TLV, by returning a success report ASCONF success for a requested TLV, by returning a success report ASCONF
Parameter Response. Parameter Response.
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
skipping to change at page 14, line 44 skipping to change at page 15, line 44
based upon the upper layer protocol configuration of the SCTP stack. 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 This parameter MUST NOT be sent in any other chunks and if it is
received in another chunk it MUST be ignored. received in another chunk it MUST be ignored.
4.2.7. Supported Extensions Parameter 4.2.7. Supported Extensions Parameter
This parameter is used at startup to identify any additional This parameter is used at startup to identify any additional
extensions that the sender supports. The sender MUST support both extensions that the sender supports. The sender MUST support both
the sending and the receiving of any chunk types listed within the the sending and the receiving of any chunk types listed within the
Supported Extensions Parameter. An implementation supporting this Supported Extensions Parameter. An implementation supporting this
extension MUST list the ASCONF and the ASCONF-ACK chunks in its INIT extension MUST list the ASCONF,the ASCONF-ACK, and the AUTH chunks in
and INIT-ACK parameters. its INIT and INIT-ACK parameters.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8008 | Parameter Length | | Parameter Type = 0x8008 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 | | CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 45 skipping to change at page 16, line 45
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
4.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
skipping to change at page 18, line 31 skipping to change at page 19, line 31
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.
4.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 5.3 Rule F0 ). 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. Sequence numbers smaller than the last current sequence number. Sequence numbers smaller than the last
acked sequence number are silently ignored. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.5. Error Cause: Request refused - no authorization. 4.3.5. Error Cause: Request refused - no authorization.
skipping to change at page 19, line 29 skipping to change at page 20, line 29
5.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 MUST do the following: remote endpoint it MUST do the following:
A1) Create an ASCONF Chunk as defined in Section 4.1.1. The chunk A1) Create an ASCONF Chunk as defined in Section 4.1.1. The chunk
MUST contain all of the TLV(s) of information necessary to be sent MUST contain all of the TLV(s) of information necessary to be sent
to the remote endpoint, and unique correlation identities for each to the remote endpoint, and unique correlation identities for each
request. request.
A2) A serial number MUST be assigned to the Chunk. The serial A2) A sequence number MUST be assigned to the Chunk. The sequence
number MUST be larger by one. The serial number MUST be number MUST be larger by one. The sequence number MUST be
initialized at the start of the association to the same value as initialized at the start of the association to the same value as
the Initial TSN and every time a new ASCONF Chunk is created it the Initial TSN and every time a new ASCONF Chunk is created it
MUST be incremented by one after assigning the serial number to MUST be incremented by one after assigning the sequence number 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. and proceed to step A4. If an ASCONF chunk is outstanding, then
the ASCONF chunk should be queued for later transmission and no
further action should be taken until the previous ASCONF is
acknowledged or a time out occurs.
A4) The sender MUST Start a T-4 RTO timer, using the RTO value of A4) The sender MUST Start a T-4 RTO timer, using the RTO value of
the selected destination address (normally the primary path; see the selected destination address (normally the primary path; see
RFC2960 [RFC2960] section 6.4 for details). SCTP-BIS [I-D.ietf-tsvwg-2960bis] section 6.4 for details).
A5) When the ASCONF-ACK that acknowledges the serial number last A5) When the ASCONF-ACK that acknowledges the sequence number last
sent arrives, the sender MUST stop the T-4 RTO timer, and clear sent arrives, the sender MUST stop the T-4 RTO timer, and clear
the appropriate association and destination error counters as the appropriate association and destination error counters as
defined in RFC2960 [RFC2960] section 8.1 and 8.2. defined in SCTP-BIS [I-D.ietf-tsvwg-2960bis] section 8.1 and 8.2.
A6) The endpoint MUST process all of the TLVs within the ASCONF- A6) The endpoint MUST process all of the TLVs within the ASCONF-
ACK(s) to find out particular status information returned to the ACK(s) to find out particular status information returned to the
various requests that were sent. Use the Correlation IDs to various requests that were sent. Use the Correlation IDs to
correlate the request 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
skipping to change at page 20, line 28 skipping to change at page 21, line 28
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 MUST 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 SCTP-BIS
[RFC2960] section 8.1 and 8.2. [I-D.ietf-tsvwg-2960bis] 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 SCTP-BIS
[RFC2960] section 8.1 and 8.2. [I-D.ietf-tsvwg-2960bis] 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 SCTP-BIS
section 6.4.1). An endpoint MUST NOT add new parameters to this [I-D.ietf-tsvwg-2960bis] section 6.4.1). An endpoint MUST NOT add
chunk, it MUST be the same (including its serial number) as the new parameters to this chunk, it MUST be the same (including its
last ASCONF sent. An endpoint MAY, however, bundle an additional sequence number) as the last ASCONF sent. An endpoint MAY,
ASCONF with new ASCONF parameters with the next sequence number. however, bundle an additional ASCONF with new ASCONF parameters
For details see Section 5.5 with the next sequence number. 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 SCTP-BIS [I-D.ietf-tsvwg-2960bis] section 6.4.1
for details).
5.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
skipping to change at page 21, line 33 skipping to change at page 22, line 34
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 5.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 Sequence 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 Sequence 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. If the path MTU is unknown, then the path MTU than the PMTU. If the PMTU is unknown, then the PMTU should be
should be set to a minimal path MTU. The minimum PMTU depends on set to the minimum PMTU. The minimum PMTU depends on the IP
the IP version used for transmission, and is the lesser of 576 version used for transmission, and is the lesser of 576 octets and
octets and the first-hop MTU for IPv4 RFC1122 [RFC1122] and 1280 the first-hop MTU for IPv4 RFC1122 [RFC1122] and 1280 octets for
octets for IPv6 RFC2460 [RFC2460]. IPv6 RFC2460 [RFC2460].
An ASCONF sender without these restrictions could possibly flood the An ASCONF sender without these restrictions could possibly flood the
network with a large number of separate address change operations network with a large number of separate address change operations
thus causing network congestion. 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.
5.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 SCTP-BIS [I-D.ietf-tsvwg-2960bis] used for all other SCTP Chunks).
proceed to rule D4. If found 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.
D2-ext) If more than one ASCONF Chunks are packed together, use the D2-ext) If more than one ASCONF Chunks are packed together, use the
address found in the ASCONF Address Parameter TLV of the each of address found in the ASCONF Address Parameter TLV of each of the
the subsequent ASCONF Chunks. If found, proceed to rule D4. subsequent ASCONF Chunks. If found, proceed to rule D4.
D3) If neither D1, D2 nor D2-ext locates the association, treat the D3) If neither D1, D2 nor D2-ext locates the association, treat the
chunk as an Out Of The Blue packet as defined in RFC2960 chunk as an Out Of The Blue packet as defined in SCTP-BIS
[RFC2960]. [I-D.ietf-tsvwg-2960bis].
D4) Follow the normal rules to validate the SCTP verification tag D4) Follow the normal rules to validate the SCTP verification tag
found in RFC2960 [RFC2960]. found in SCTP-BIS [I-D.ietf-tsvwg-2960bis].
D5) After the verification tag has been validated, normal chunk
processing should occur. Prior to finding the ASCONF chunk the
receiver MUST encounter an AUTH chunk as described in SCTP-AUTH
[I-D.ietf-tsvwg-sctp-auth]. If either authentication fails, or
the AUTH chunk is missing, the receiver MUST silently discard this
chunk and the rest of the packet.
After identification and verification of the association, the After identification and verification of the association, the
following should be performed to properly process the ASCONF Chunk: following should be performed to properly process the ASCONF Chunk:
E1) If the value found in the serial number of the ASCONF Chunk is
equal to the ('Peer-Serial-Number' + 1) and the Serial Number of
the ASCONF Chunk is the first in the SCTP Packet, the endpoint MAY
clean any old cached ASCONF-ACK up to the 'Peer-Serial-Number' and
then proceed to rule E4.
E1-ext If the value found in the serial number of the ASCONF Chunk E1)
is equal to the ('Peer-Serial-Number' + 1) and the ASCONF chunk is
NOT the first Serial Number in the SCTP packet proceed to rule E4 If the value found in the sequence number of the ASCONF Chunk is
but do NOT clear any cached ASCONF-ACK or state information. equal to the ('Peer-Sequence-Number' + 1) and the Sequence Number
E2) If the value found in the serial number is less than the ('Peer- of the ASCONF Chunk is the first in the SCTP Packet, the endpoint
Serial-Number' + 1), simply skip to the next ASCONF, and include MAY clean any old cached ASCONF-ACK up to the 'Peer-Sequence-
Number' and then proceed to rule E4.
E1-ext If the value found in the sequence number of the ASCONF Chunk
is equal to the ('Peer-Sequence-Number' + 1) and the ASCONF chunk
is NOT the first Sequence Number in the SCTP packet proceed to
rule E4 but do NOT clear any cached ASCONF-ACK or state
information.
E2)
If the value found in the sequence number is less than the ('Peer-
Sequence-Number' + 1), simply skip to the next ASCONF, and include
in the outbound response packet any previously cached ASCONF-ACK in the outbound response packet any previously cached ASCONF-ACK
response that was sent and saved that matches the serial number of response that was sent and saved that matches the sequence number
the ASCONF. Note: it is possible that no cached ASCONF-ACK Chunk of the ASCONF. Note: it is possible that no cached ASCONF-ACK
exists. This will occur when an older ASCONF arrives out of Chunk exists. This will occur when an older ASCONF arrives out of
order. In such a case the receiver should skip the ASCONF Chunk order. In such a case the receiver should skip the ASCONF Chunk
and not include ASCONF-ACK Chunk for that chunk. and not include ASCONF-ACK Chunk for that chunk.
E3) Then, process each ASCONF one by one as above while the Serial E3)
Number of the ASCONF is less than the ('Peer-Serial-Number' + 1).
E4) When the serial number matches the next one expected, process Then, process each ASCONF one by one as above while the Sequence
Number of the ASCONF is less than the ('Peer-Sequence-Number' +
1).
E4) When the sequence number matches the next one expected, process
the ASCONF as described below and after processing the ASCONF the ASCONF as described below and after processing the ASCONF
Chunk, append an ASCONF-ACK Chunk to the response packet and cache Chunk, append an ASCONF-ACK Chunk to the response packet and cache
a copy of it (in the event it later needs to be retransmitted). a copy of it (in the event it later needs to be retransmitted).
V1) Process the TLVs contained within the Chunk performing the V1) Process the TLVs contained within the Chunk performing the
appropriate actions as indicated by each TLV type. The TLVs appropriate actions as indicated by each TLV type. The TLVs
MUST be processed in order within the Chunk. For example, if MUST be processed in order within the Chunk. For example, if
the sender puts 3 TLVs in one chunk, the first TLV (the one the sender puts 3 TLVs in one chunk, the first TLV (the one
closest to the Chunk Header) in the Chunk MUST be processed closest to the Chunk Header) in the Chunk MUST be processed
first. The next TLV in the chunk (the middle one) MUST be first. The next TLV in the chunk (the middle one) MUST be
processed second and finally the last TLV in the Chunk MUST be processed second and finally the last TLV in the Chunk MUST be
processed last. processed last.
V2) In processing the chunk, the receiver should build a response V2) In processing the chunk, the receiver should build a response
message with the appropriate error TLVs, as specified in the message with the appropriate error TLVs, as specified in the
Parameter type bits for any ASCONF Parameter it does not Parameter type bits for any ASCONF Parameter it does not
understand. To indicate an unrecognized parameter, cause type understand. To indicate an unrecognized parameter, cause type
8 as defined in the ERROR in 3.3.10.8 of RFC2960 [RFC2960] 8 as defined in the ERROR in 3.3.10.8 of SCTP-BIS
should be used. The endpoint may also use the response to [I-D.ietf-tsvwg-2960bis] should be used. The endpoint may also
carry rejections for other reasons such as resource shortages use the response to carry rejections for other reasons such as
etc, using the Error Cause TLV and an appropriate error resource shortages etc, using the Error Cause TLV and an
condition. appropriate error condition.
Note: a positive response is implied if no error is indicated Note: a positive response is implied if no error is indicated
by the sender. by the sender.
V3) All responses MUST copy the ASCONF-Request Correlation ID V3)
field received in the ASCONF parameter, from the TLV being
responded to, into the ASCONF-Request Correlation ID field in All responses MUST copy the ASCONF-Request Correlation ID field
the response parameter. received in the ASCONF parameter, from the TLV being responded
to, into the ASCONF-Request Correlation ID field in the
response parameter.
V4) After processing the entire Chunk, the receiver of the ASCONF V4) After processing the entire Chunk, the receiver of the ASCONF
MUST queue the response ASCONF-ACK Chunk for transmission after MUST queue the response ASCONF-ACK Chunk for transmission after
the rest of the SCTP packet has been processed. This allows the rest of the SCTP packet has been processed. This allows
the ASCONF-ACK Chunk to be bundled with other ASCONF-ACK Chunks the ASCONF-ACK Chunk to be bundled with other ASCONF-ACK Chunks
as well as any additional responses e.g. a SACK Chunk. as well as any additional responses e.g. a SACK Chunk.
V5) Update the 'Peer-Serial-Number' to the value found in the V5) Update the 'Peer-Sequence-Number' to the value found in the
serial number field. sequence number field.
E5) Otherwise, the ASCONF Chunk is discarded since it must be either E5) Otherwise, the ASCONF Chunk is discarded since it must be either
a stale packet or from an attacker. A receiver of such a packet a stale packet or from an attacker. A receiver of such a packet
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.
skipping to change at page 24, line 46 skipping to change at page 26, line 18
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.
5.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 MUST 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 sequence number to be used but no ASCONF Chunk
outstanding the endpoint MUST ABORT the association. Note: that a is outstanding the endpoint MUST ABORT the association. Note:
sequence number is greater than if it is no more than 2^^31-1 that a sequence number is greater than if it is no more than
larger than the current sequence number (using serial arithmetic). 2^^31-1 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
the add is acknowledged the sender MUST NOT use the new IP address the add is acknowledged the sender MUST NOT use the new IP address
as a source for ANY SCTP packet except on carrying an ASCONF as a source for ANY SCTP packet except on carrying an ASCONF
Chunk. The receiver of the add IP address request may use the Chunk. The receiver of the add IP address request may use the
address as a destination immediately. The receiver MUST use the address as a destination immediately. The receiver MUST use the
path verification procedure for the added address before using path verification procedure for the added address before using
that address. The receiver MUST NOT send packets to the new that address. The receiver MUST NOT send packets to the new
skipping to change at page 27, line 15 skipping to change at page 28, line 28
F13) When an endpoint receives a valid request to DELETE an IP F13) When an endpoint receives a valid request to DELETE an IP
address the endpoint MUST consider the address no longer as part address the endpoint MUST consider the address no longer as part
of the association. It MUST NOT send SCTP packets for the of the association. It MUST NOT send SCTP packets for the
association to that address and it MUST treat subsequent packets association to that address and it MUST treat subsequent packets
received from that address as Out Of The Blue. received from that address as Out Of The Blue.
During the time interval between sending out the ASCONF and During the time interval between sending out the ASCONF and
receiving the ASCONF-ACK it MAY be possible to receive DATA Chunks receiving the ASCONF-ACK it MAY be possible to receive DATA Chunks
out of order. The following examples illustrate these problems: out of order. The following examples illustrate these problems:
F14) All addresses added by the reception of an ASCONF chunk MUST be
put into the unconfirmed state and MUST have path verification
performed on them before the address can be used as described in
SCTP-BIS [I-D.ietf-tsvwg-2960bis] section 5.4.
Endpoint-A Endpoint-Z Endpoint-A Endpoint-Z
---------- ---------- ---------- ----------
ASCONF[Add-IP:X]------------------------------> ASCONF[Add-IP:X]------------------------------>
/--ASCONF-ACK /--ASCONF-ACK
/ /
/--------/---New DATA: /--------/---New DATA:
/ / Destination / / Destination
<-------------------/ / IP:X <-------------------/ / IP:X
/ /
<--------------------------/ <--------------------------/
skipping to change at page 28, line 8 skipping to change at page 29, line 26
/ /
<-------------/ <-------------/
In this example we see a DATA chunk destined to the IP:X (which is In this example we see a DATA chunk destined to the IP:X (which is
about to be deleted) arriving after the deletion is complete. For about to be deleted) arriving after the deletion is complete. For
the ADD case an endpoint SHOULD consider the newly adding IP address the ADD case an endpoint SHOULD consider the newly adding IP address
valid for the association to receive data from during the interval valid for the association to receive data from during the interval
when awaiting the ASCONF-ACK. The endpoint MUST NOT source data from when awaiting the ASCONF-ACK. The endpoint MUST NOT source data from
this new address until the ASCONF-ACK arrives but it may receive out this new address until the ASCONF-ACK arrives but it may receive out
of order data as illustrated and MUST NOT treat this data as an OOTB of order data as illustrated and MUST NOT treat this data as an OOTB
datagram (please see RFC2960 [RFC2960] section 8.4). It MAY drop the datagram (please see SCTP-BIS [I-D.ietf-tsvwg-2960bis] section 8.4).
data silently or it MAY consider it part of the association but it It MAY drop the data silently or it MAY consider it part of the
MUST NOT respond with an ABORT. association but it MUST NOT respond with an ABORT.
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.
skipping to change at page 28, line 36 skipping to change at page 30, line 16
---------- ---------- ---------- ----------
New DATA:------------\ New DATA:------------\
Source IP:X \ Source IP:X \
\ \
ASCONF-REQ[DEL-IP:X]----\------------------> ASCONF-REQ[DEL-IP:X]----\------------------>
\ /---------ASCONF-ACK \ /---------ASCONF-ACK
\ / \ /
\----/-----------> OOTB \----/-----------> OOTB
(Ignored <---------------------/-------------ABORT (Ignored <---------------------/-------------ABORT
by rule D4) / by rule F4) /
<---------------------/ <---------------------/
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.
5.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 Parameter
only if the lookup fails using the source address from the IP header. field only if the lookup fails using the source address from the IP
The receiver MUST reply to the source address of the packet in this header. The receiver MUST reply to the source address of the packet
case which is the new address that was added by the ASCONF (since the in this case which is the new address that was added by the ASCONF
old address is no longer a part of the association after processing). (since the old address is no longer a part of the association after
processing).
5.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 MUST 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
requester's view). If a request arrives that asks the receiver to requester's view). If a request arrives that asks the receiver to
set an address as primary that does not exist, the receiver should set an address as primary that does not exist, the receiver SHOULD
NOT honor the request, leaving its existing primary address NOT honor the request, leaving its existing primary address
unchanged. unchanged.
5.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 ASCONFs in the allowable for a sender to bundle additional ASCONFs in the
retransmission. In bundling multiple ASCONFs 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 Sequence Number first in the
packet (closest to the Chunk header) and preceding 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 Sequence Number.
3. All ASCONFs 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 separate the ASCONFs.
no other chunk type must separate the ASCONFs. 4. Each new ASCONF lookup address MUST be populated as if the
4. Each new ASCONFs lookup address MUST be populated as if the
previous ASCONFs had been processed and accepted. previous ASCONFs had been processed and accepted.
6. 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.
skipping to change at page 30, line 31 skipping to change at page 32, line 9
initial two packets of the association setup when the SCTP-AUTH initial two packets of the association setup when the SCTP-AUTH
extension is used without pre-shared keys. If such a threat is extension is used without pre-shared keys. If such a threat is
considered a possibility, then the SCTP-AUTH considered a possibility, then the SCTP-AUTH
[I-D.ietf-tsvwg-sctp-auth] extension MUST be used with a [I-D.ietf-tsvwg-sctp-auth] extension MUST be used with a
preconfigured shared end-point pair key to mitigate this threat. For preconfigured shared end-point pair key to mitigate this threat. For
a more detailed analysis see SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]. a more detailed analysis see SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth].
When using a wildcard address for adding or deleting an address the When using a wildcard address for adding or deleting an address the
source address of the packet is used. This address is not protected source address of the packet is used. This address is not protected
by SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] and an attacker can therefore by SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] and an attacker can therefore
intercept such a packet and modfiy the source address. intercept such a packet and modify the source address.
If an SCTP endpoint that supports this extension receives an INIT If an SCTP endpoint that supports this extension receives an INIT
that indicates that the peer supports the ASCONF extension but does that indicates that the peer supports the ASCONF extension but does
NOT support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] extension, the NOT support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] extension, the
receiver of such an INIT MUST send an ABORT in response to such an receiver of such an INIT MUST send an ABORT in response to such an
INIT. Note: that an implementation is allowed to silently discard INIT. Note: that an implementation is allowed to silently discard
such an INIT as an option as well but under NO circumstance is an such an INIT as an option as well but under NO circumstance is an
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.
Other types of attacks, e.g. bombing, are discussed in detail in
SCTP-THREAT [I-D.ietf-tsvwg-sctpthreat]. The bombing attack, in
particular, is countered by the use of a random nonce and is required
by SCTP-BIS [I-D.ietf-tsvwg-2960bis].
7. 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 (http://www.iana.org/assignments/sctp-parameters): errors (http://www.iana.org/assignments/sctp-parameters):
o Two new chunk types, o Two new chunk types,
o Six 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
skipping to change at page 32, line 24 skipping to change at page 34, line 8
This document also defines an Adaptation code point. The adaptation 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]. For this new IETF Consensus action as defined in RFC2434 [RFC2434]. For this new
registry no initial values are being added by this document, however registry no initial values are being added by this document, however
draft-ietf-rddp-sctp will add the first entry. draft-ietf-rddp-sctp will add the first entry.
8. 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 their extreme efforts in the early
formation of this draft. formation of this draft.
The authors wish to thank Jon Berger, Mark Butler, Lars Eggert, The authors wish to thank Jon Berger, Mark Butler, Lars Eggert,
Janardhan Iyengar, Greg Kendall, Seok Koh, Salvatore Loreto, Peter Janardhan Iyengar, Greg Kendall, Seok Koh, Salvatore Loreto, Peter
Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose, Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose,
Ronnie Sellars, Chip Sharp, and Irene Ruengeler for their invaluable Ronnie Sellars, Chip Sharp, and Irene Ruengeler for their invaluable
comments. 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.
9. Normative References And a special thanks to James Polk, abstract writer to the few but
lucky.
9. References
9.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. 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 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [I-D.ietf-tsvwg-2960bis]
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Stewart, R., "Stream Control Transmission Protocol",
Zhang, L., and V. Paxson, "Stream Control Transmission draft-ietf-tsvwg-2960bis-04 (work in progress),
Protocol", RFC 2960, October 2000. April 2007.
[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-08 (work in progress), draft-ietf-tsvwg-sctp-auth-08 (work in progress),
February 2007. February 2007.
9.2. Informative References
[I-D.ietf-tsvwg-sctpthreat]
Stewart, R., "Security Attacks Found Against SCTP and
Current Countermeasures", draft-ietf-tsvwg-sctpthreat-04
(work in progress), June 2007.
Appendix A. Abstract Address Handling Appendix A. Abstract Address Handling
A.1. General remarks A.1. General remarks
This appendix is non-normative. It is present to give the reader a This appendix is non-normative. It is present to give the reader a
concise mathematical definition of an SCTP endpoint. The following concise mathematical definition of an SCTP endpoint. The following
text provides a working definition of the endpoint notion to discuss text provides a working definition of the endpoint notion to discuss
address reconfiguration. It is not intended to restrict address reconfiguration. It is not intended to restrict
implementations in any way, its goal is to provide a set of 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
skipping to change at page 35, line 13 skipping to change at page 37, line 4
Association establishment between gE' and gE'' can be seen as: Association establishment between gE' and gE'' can be seen as:
1. gE' and gE'' do exist before the association. 1. gE' and gE'' do exist before the association.
2. If an INIT has to be send from gE' to gE'' address scoping rules 2. If an INIT has to be send from gE' to gE'' address scoping rules
and other limitations are applied to calculate the subset S' from and other limitations are applied to calculate the subset S' from
Addr(gE'). The addresses of S' are included in the INIT chunk. Addr(gE'). The addresses of S' are included in the INIT chunk.
3. If an INIT-ACK has to be send from gE'' to gE' address scoping 3. If an INIT-ACK has to be send from gE'' to gE' address scoping
rules and other limitations are applied to calculate the subset rules and other limitations are applied to calculate the subset
S'' from Addr(gE''). The addresses of S'' are included in the S'' from Addr(gE''). The addresses of S'' are included in the
INIT-ACK chunk. INIT-ACK chunk.
4. After the handshake the association A = (gE', S', gE'', S'') has 4. After the handshake the association A = (gE', S', gE'', S'') has
been established. been established.
5. Right after the association establishment Addr(A, gE') and 5. Right after the association establishment Addr(A, gE') and
Addr(A, gE'') are the addresses which have been seen on the wire Addr(A, gE'') are the addresses which have been seen on the wire
during the handshake. during the handshake.
A.4. Relationship with RFC 2960 A.4. Relationship with RFC 4960
RFC2960 [RFC2960] defines the notion of an endpoint. This subsection SCTP-BIS [I-D.ietf-tsvwg-2960bis] defines the notion of an endpoint.
will show that these endpoints are also (special) generalized This subsection will show that these endpoints are also (special)
endpoints. generalized endpoints.
RFC2960 [RFC2960] has no notion of address scoping or other address SCTP-BIS [I-D.ietf-tsvwg-2960bis] has no notion of address scoping or
handling limitations and provides no mechanism to change the other address handling limitations and provides no mechanism to
addresses of an endpoint. change the addresses of an endpoint.
This means that an endpoint is simply a generalized endpoint which This means that an endpoint is simply a generalized endpoint which
does not depend on the time. Neither the Port nor the address list does not depend on the time. Neither the Port nor the address list
changes. changes.
During association setup no address scoping rules or other During association setup no address scoping rules or other
limitations will be applied. This means that for an association A limitations will be applied. This means that for an association A
between two endpoints gE' and gE'' the following is true: between two endpoints gE' and gE'' the following is true:
Addr(A, gE') = Addr(gE') and Addr(A, gE'') = Addr(gE''). Addr(A, gE') = Addr(gE') and Addr(A, gE'') = Addr(gE'').
 End of changes. 78 change blocks. 
215 lines changed or deleted 273 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/