rfc9260.original		rfc9260.txt
	Network Working Group R. R. Stewart		Internet Engineering Task Force (IETF) R. Stewart
	Internet-Draft Netflix, Inc.		Request for Comments: 9260 Netflix, Inc.
	Obsoletes: 4460, 4960, 6096, 7053, 8540 (if M. Tüxen		Obsoletes: 4460, 4960, 6096, 7053, 8540 M. Tüxen
	approved) Münster Univ. of Appl. Sciences		Category: Standards Track Münster Univ. of Appl. Sciences
	Intended status: Standards Track K. E. E. Nielsen		ISSN: 2070-1721 K. Nielsen
	Expires: 9 August 2022 Kamstrup A/S		Kamstrup A/S
	5 February 2022		May 2022
	Stream Control Transmission Protocol		Stream Control Transmission Protocol
	draft-ietf-tsvwg-rfc4960-bis-19
	Abstract		Abstract
	This document obsoletes RFC 4960, if approved. It describes the		This document describes the Stream Control Transmission Protocol
	Stream Control Transmission Protocol (SCTP) and incorporates the		(SCTP) and obsoletes RFC 4960. It incorporates the specification of
	specification of the chunk flags registry from RFC 6096 and the		the chunk flags registry from RFC 6096 and the specification of the I
	specification of the I bit of DATA chunks from RFC 7053. Therefore,		bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are
	RFC 6096 and RFC 7053 are also obsoleted by this document, if		also obsoleted by this document. In addition, RFCs 4460 and 8540,
	approved. In addition to that, the Errata documents RFC 4460 and RFC		which describe errata for SCTP, are obsoleted by this document.
	8540 are also obsoleted by this document, if approved.
	SCTP was originally designed to transport Public Switched Telephone		SCTP was originally designed to transport Public Switched Telephone
	Network (PSTN) signaling messages over IP networks. It is also		Network (PSTN) signaling messages over IP networks. It is also
	suited to be used for other applications, for example WebRTC.		suited to be used for other applications, for example, WebRTC.
	SCTP is a reliable transport protocol operating on top of a		SCTP is a reliable transport protocol operating on top of a
	connectionless packet network such as IP. It offers the following		connectionless packet network, such as IP. It offers the following
	services to its users:		services to its users:
	* acknowledged error-free non-duplicated transfer of user data,		* acknowledged error-free, non-duplicated transfer of user data,
	* data fragmentation to conform to discovered path maximum		* data fragmentation to conform to discovered Path Maximum
	transmission unit (PMTU) size,		Transmission Unit (PMTU) size,
	* sequenced delivery of user messages within multiple streams, with		* sequenced delivery of user messages within multiple streams, with
	an option for order-of-arrival delivery of individual user		an option for order-of-arrival delivery of individual user
	messages,		messages,
	* optional bundling of multiple user messages into a single SCTP		* optional bundling of multiple user messages into a single SCTP
	packet, and		packet, and
	* network-level fault tolerance through supporting of multi-homing		* network-level fault tolerance through supporting of multi-homing
	at either or both ends of an association.		at either or both ends of an association.
	The design of SCTP includes appropriate congestion avoidance behavior		The design of SCTP includes appropriate congestion avoidance behavior
	and resistance to flooding and masquerade attacks.		and resistance to flooding and masquerade attacks.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 9 August 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9260.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Motivation
	2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 7		1.2. Architectural View of SCTP
	2.2. Architectural View of SCTP . . . . . . . . . . . . . . . 7		1.3. Key Terms
	2.3. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 8		1.4. Abbreviations
	2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 12		1.5. Functional View of SCTP
	2.5. Functional View of SCTP . . . . . . . . . . . . . . . . . 13		1.5.1. Association Startup and Takedown
	2.5.1. Association Startup and Takedown . . . . . . . . . . 13		1.5.2. Sequenced Delivery within Streams
	2.5.2. Sequenced Delivery within Streams . . . . . . . . . . 14		1.5.3. User Data Fragmentation
	2.5.3. User Data Fragmentation . . . . . . . . . . . . . . . 15		1.5.4. Acknowledgement and Congestion Avoidance
	2.5.4. Acknowledgement and Congestion Avoidance . . . . . . 15		1.5.5. Chunk Bundling
	2.5.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 15		1.5.6. Packet Validation
	2.5.6. Packet Validation . . . . . . . . . . . . . . . . . . 16		1.5.7. Path Management
	2.5.7. Path Management . . . . . . . . . . . . . . . . . . . 16		1.6. Serial Number Arithmetic
	2.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 17		1.7. Changes from RFC 4960
	2.7. Changes from RFC 4960 . . . . . . . . . . . . . . . . . . 17		2. Conventions
	3. SCTP Packet Format . . . . . . . . . . . . . . . . . . . . . 18		3. SCTP Packet Format
	3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 19		3.1. SCTP Common Header Field Descriptions
	3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 20		3.2. Chunk Field Descriptions
	3.2.1. Optional/Variable-Length Parameter Format . . . . . . 23		3.2.1. Optional/Variable-Length Parameter Format
	3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 25		3.2.2. Reporting of Unrecognized Parameters
	3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 25		3.3. SCTP Chunk Definitions
	3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 25		3.3.1. Payload Data (DATA) (0)
	3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 28		3.3.2. Initiation (INIT) (1)
	3.3.2.1. Optional or Variable-Length Parameters in INIT		3.3.2.1. Optional or Variable-Length Parameters in INIT
	chunks . . . . . . . . . . . . . . . . . . . . . . 32		chunks
	3.3.3. Initiation Acknowledgement (INIT ACK) (2) . . . . . . 35		3.3.3. Initiation Acknowledgement (INIT ACK) (2)
	3.3.3.1. Optional or Variable-Length Parameters in INIT ACK		3.3.3.1. Optional or Variable-Length Parameters in INIT ACK
	chunks . . . . . . . . . . . . . . . . . . . . . . 39		Chunks
	3.3.4. Selective Acknowledgement (SACK) (3) . . . . . . . . 40		3.3.4. Selective Acknowledgement (SACK) (3)
	3.3.5. Heartbeat Request (HEARTBEAT) (4) . . . . . . . . . . 43		3.3.5. Heartbeat Request (HEARTBEAT) (4)
	3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) . . . . 44		3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5)
	3.3.7. Abort Association (ABORT) (6) . . . . . . . . . . . . 45		3.3.7. Abort Association (ABORT) (6)
	3.3.8. Shutdown Association (SHUTDOWN) (7) . . . . . . . . . 46		3.3.8. Shutdown Association (SHUTDOWN) (7)
	3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) . . . . . 47		3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8)
	3.3.10. Operation Error (ERROR) (9) . . . . . . . . . . . . . 47		3.3.10. Operation Error (ERROR) (9)
	3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 49		3.3.10.1. Invalid Stream Identifier (1)
	3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 50		3.3.10.2. Missing Mandatory Parameter (2)
	3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 50		3.3.10.3. Stale Cookie (3)
	3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 51		3.3.10.4. Out of Resource (4)
	3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 51		3.3.10.5. Unresolvable Address (5)
	3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 52		3.3.10.6. Unrecognized Chunk Type (6)
	3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 52		3.3.10.7. Invalid Mandatory Parameter (7)
	3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 52		3.3.10.8. Unrecognized Parameters (8)
	3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 53		3.3.10.9. No User Data (9)
	3.3.10.10. Cookie Received While Shutting Down (10) . . . . 53		3.3.10.10. Cookie Received While Shutting Down (10)
	3.3.10.11. Restart of an Association with New Addresses		3.3.10.11. Restart of an Association with New Addresses (11)
	(11) . . . . . . . . . . . . . . . . . . . . . . . 54		3.3.10.12. User-Initiated Abort (12)
	3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 54		3.3.10.13. Protocol Violation (13)
	3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 54		3.3.11. Cookie Echo (COOKIE ECHO) (10)
			3.3.12. Cookie Acknowledgement (COOKIE ACK) (11)
	3.3.11. Cookie Echo (COOKIE ECHO) (10) . . . . . . . . . . . 55		3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14)
	3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) . . . . . . 56		4. SCTP Association State Diagram
	3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) . . . . . 56		5. Association Initialization
	4. SCTP Association State Diagram . . . . . . . . . . . . . . . 57		5.1. Normal Establishment of an Association
	5. Association Initialization . . . . . . . . . . . . . . . . . 60		5.1.1. Handle Stream Parameters
	5.1. Normal Establishment of an Association . . . . . . . . . 60		5.1.2. Handle Address Parameters
	5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 62		5.1.3. Generating State Cookie
	5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 63		5.1.4. State Cookie Processing
	5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 64		5.1.5. State Cookie Authentication
	5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 65		5.1.6. An Example of Normal Association Establishment
	5.1.5. State Cookie Authentication . . . . . . . . . . . . . 65
	5.1.6. An Example of Normal Association Establishment . . . 66
	5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO,		5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO,
	and COOKIE ACK Chunks . . . . . . . . . . . . . . . . . . 68		and COOKIE ACK Chunks
	5.2.1. INIT Chunk Received in COOKIE-WAIT or COOKIE-ECHOED		5.2.1. INIT Chunk Received in COOKIE-WAIT or COOKIE-ECHOED
	State (Item B) . . . . . . . . . . . . . . . . . . . 68		State (Item B)
	5.2.2. Unexpected INIT Chunk in States Other than CLOSED,		5.2.2. Unexpected INIT Chunk in States Other than CLOSED,
	COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT . . 69		COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT
	5.2.3. Unexpected INIT ACK Chunk . . . . . . . . . . . . . . 70		5.2.3. Unexpected INIT ACK Chunk
	5.2.4. Handle a COOKIE ECHO Chunk when a TCB Exists . . . . 70		5.2.4. Handle a COOKIE ECHO Chunk When a TCB Exists
	5.2.4.1. An Example of a Association Restart . . . . . . . 73		5.2.4.1. An Example of an Association Restart
	5.2.5. Handle Duplicate COOKIE ACK Chunk . . . . . . . . . . 74		5.2.5. Handle Duplicate COOKIE ACK Chunk
	5.2.6. Handle Stale Cookie Error . . . . . . . . . . . . . . 74		5.2.6. Handle Stale Cookie Error
	5.3. Other Initialization Issues . . . . . . . . . . . . . . . 74		5.3. Other Initialization Issues
	5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 75		5.3.1. Selection of Tag Value
	5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 75		5.4. Path Verification
	6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 76		6. User Data Transfer
	6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 78		6.1. Transmission of DATA Chunks
	6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 81		6.2. Acknowledgement on Reception of DATA Chunks
	6.2.1. Processing a Received SACK Chunk . . . . . . . . . . 84		6.2.1. Processing a Received SACK Chunk
	6.3. Management of Retransmission Timer . . . . . . . . . . . 86		6.3. Management of Retransmission Timer
	6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 86		6.3.1. RTO Calculation
	6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 88		6.3.2. Retransmission Timer Rules
	6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 89		6.3.3. Handle T3-rtx Expiration
	6.4. Multi-Homed SCTP Endpoints . . . . . . . . . . . . . . . 90		6.4. Multi-Homed SCTP Endpoints
	6.4.1. Failover from an Inactive Destination Address . . . . 91		6.4.1. Failover from an Inactive Destination Address
	6.5. Stream Identifier and Stream Sequence Number . . . . . . 92		6.5. Stream Identifier and Stream Sequence Number
	6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 92		6.6. Ordered and Unordered Delivery
	6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 93		6.7. Report Gaps in Received DATA TSNs
	6.8. CRC32c Checksum Calculation . . . . . . . . . . . . . . . 94		6.8. CRC32c Checksum Calculation
	6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 95		6.9. Fragmentation and Reassembly
	6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 96		6.10. Bundling
	7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 97		7. Congestion Control
	7.1. SCTP Differences from TCP Congestion Control . . . . . . 98		7.1. SCTP Differences from TCP Congestion Control
	7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 99		7.2. SCTP Slow-Start and Congestion Avoidance
	7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 100		7.2.1. Slow-Start
	7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 101		7.2.2. Congestion Avoidance
	7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 102		7.2.3. Congestion Control
	7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 102		7.2.4. Fast Retransmit on Gap Reports
	7.2.5. Reinitialization . . . . . . . . . . . . . . . . . . 104		7.2.5. Reinitialization
	7.2.5.1. Change of Differentiated Services Code Points . . 104		7.2.5.1. Change of Differentiated Services Code Points
	7.2.5.2. Change of Routes . . . . . . . . . . . . . . . . 104		7.2.5.2. Change of Routes
	7.3. PMTU Discovery . . . . . . . . . . . . . . . . . . . . . 104		7.3. PMTU Discovery
	8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 105		8. Fault Management
	8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 105		8.1. Endpoint Failure Detection
	8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 105		8.2. Path Failure Detection
	8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 106		8.3. Path Heartbeat
	8.4. Handle "Out of the Blue" Packets . . . . . . . . . . . . 109		8.4. Handle "Out of the Blue" Packets
	8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 110		8.5. Verification Tag
	8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 110		8.5.1. Exceptions in Verification Tag Rules
	9. Termination of Association . . . . . . . . . . . . . . . . . 111		9. Termination of Association
	9.1. Abort of an Association . . . . . . . . . . . . . . . . . 112		9.1. Abort of an Association
	9.2. Shutdown of an Association . . . . . . . . . . . . . . . 112		9.2. Shutdown of an Association
	10. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 115		10. ICMP Handling
	11. Interface with Upper Layer . . . . . . . . . . . . . . . . . 116		11. Interface with Upper Layer
	11.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . 117		11.1. ULP-to-SCTP
	11.1.1. Initialize . . . . . . . . . . . . . . . . . . . . . 117		11.1.1. Initialize
	11.1.2. Associate . . . . . . . . . . . . . . . . . . . . . 118		11.1.2. Associate
	11.1.3. Shutdown . . . . . . . . . . . . . . . . . . . . . . 119		11.1.3. Shutdown
	11.1.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 119		11.1.4. Abort
	11.1.5. Send . . . . . . . . . . . . . . . . . . . . . . . . 119		11.1.5. Send
	11.1.6. Set Primary . . . . . . . . . . . . . . . . . . . . 121		11.1.6. Set Primary
	11.1.7. Receive . . . . . . . . . . . . . . . . . . . . . . 121		11.1.7. Receive
	11.1.8. Status . . . . . . . . . . . . . . . . . . . . . . . 122		11.1.8. Status
	11.1.9. Change Heartbeat . . . . . . . . . . . . . . . . . . 123		11.1.9. Change Heartbeat
	11.1.10. Request Heartbeat . . . . . . . . . . . . . . . . . 124		11.1.10. Request Heartbeat
	11.1.11. Get SRTT Report . . . . . . . . . . . . . . . . . . 124		11.1.11. Get SRTT Report
	11.1.12. Set Failure Threshold . . . . . . . . . . . . . . . 125		11.1.12. Set Failure Threshold
	11.1.13. Set Protocol Parameters . . . . . . . . . . . . . . 125		11.1.13. Set Protocol Parameters
	11.1.14. Receive Unsent Message . . . . . . . . . . . . . . . 125		11.1.14. Receive Unsent Message
	11.1.15. Receive Unacknowledged Message . . . . . . . . . . . 126		11.1.15. Receive Unacknowledged Message
	11.1.16. Destroy SCTP Instance . . . . . . . . . . . . . . . 127		11.1.16. Destroy SCTP Instance
	11.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . 127		11.2. SCTP-to-ULP
	11.2.1. DATA ARRIVE Notification . . . . . . . . . . . . . . 127		11.2.1. DATA ARRIVE Notification
	11.2.2. SEND FAILURE Notification . . . . . . . . . . . . . 128		11.2.2. SEND FAILURE Notification
	11.2.3. NETWORK STATUS CHANGE Notification . . . . . . . . . 128		11.2.3. NETWORK STATUS CHANGE Notification
	11.2.4. COMMUNICATION UP Notification . . . . . . . . . . . 128		11.2.4. COMMUNICATION UP Notification
	11.2.5. COMMUNICATION LOST Notification . . . . . . . . . . 129		11.2.5. COMMUNICATION LOST Notification
	11.2.6. COMMUNICATION ERROR Notification . . . . . . . . . . 130		11.2.6. COMMUNICATION ERROR Notification
	11.2.7. RESTART Notification . . . . . . . . . . . . . . . . 130		11.2.7. RESTART Notification
	11.2.8. SHUTDOWN COMPLETE Notification . . . . . . . . . . . 130		11.2.8. SHUTDOWN COMPLETE Notification
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 130		12. Security Considerations
	12.1. Security Objectives . . . . . . . . . . . . . . . . . . 130		12.1. Security Objectives
	12.2. SCTP Responses to Potential Threats . . . . . . . . . . 131		12.2. SCTP Responses to Potential Threats
	12.2.1. Countering Insider Attacks . . . . . . . . . . . . . 131		12.2.1. Countering Insider Attacks
	12.2.2. Protecting against Data Corruption in the Network . 131		12.2.2. Protecting against Data Corruption in the Network
	12.2.3. Protecting Confidentiality . . . . . . . . . . . . . 131		12.2.3. Protecting Confidentiality
	12.2.4. Protecting against Blind Denial-of-Service		12.2.4. Protecting against Blind Denial-of-Service Attacks
	Attacks . . . . . . . . . . . . . . . . . . . . . . . 132		12.2.4.1. Flooding
	12.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 132		12.2.4.2. Blind Masquerade
	12.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 133		12.2.4.3. Improper Monopolization of Services
	12.2.4.3. Improper Monopolization of Services . . . . . . 134		12.3. SCTP Interactions with Firewalls
	12.3. SCTP Interactions with Firewalls . . . . . . . . . . . . 134		12.4. Protection of Non-SCTP-capable Hosts
	12.4. Protection of Non-SCTP-Capable Hosts . . . . . . . . . . 134		13. Network Management Considerations
	13. Network Management Considerations . . . . . . . . . . . . . . 135		14. Recommended Transmission Control Block (TCB) Parameters
	14. Recommended Transmission Control Block (TCB) Parameters . . . 135		14.1. Parameters Necessary for the SCTP Instance
	14.1. Parameters Necessary for the SCTP Instance . . . . . . . 135		14.2. Parameters Necessary per Association (i.e., the TCB)
	14.2. Parameters Necessary per Association (i.e., the TCB) . . 136		14.3. Per Transport Address Data
	14.3. Per Transport Address Data . . . . . . . . . . . . . . . 138		14.4. General Parameters Needed
	14.4. General Parameters Needed . . . . . . . . . . . . . . . 139		15. IANA Considerations
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 139		15.1. IETF-Defined Chunk Extension
	15.1. IETF-Defined Chunk Extension . . . . . . . . . . . . . . 143		15.2. IETF-Defined Chunk Flags Registration
	15.2. IETF Chunk Flags Registration . . . . . . . . . . . . . 144		15.3. IETF-Defined Chunk Parameter Extension
	15.3. IETF-Defined Chunk Parameter Extension . . . . . . . . . 144		15.4. IETF-Defined Additional Error Causes
	15.4. IETF-Defined Additional Error Causes . . . . . . . . . . 144		15.5. Payload Protocol Identifiers
	15.5. Payload Protocol Identifiers . . . . . . . . . . . . . . 145		15.6. Port Numbers Registry
	15.6. Port Numbers Registry . . . . . . . . . . . . . . . . . 145		16. Suggested SCTP Protocol Parameter Values
	16. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 145		17. References
	17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 146		17.1. Normative References
	18. Normative References . . . . . . . . . . . . . . . . . . . . 147		17.2. Informative References
	19. Informative References . . . . . . . . . . . . . . . . . . . 149		Appendix A. CRC32c Checksum Calculation
	Appendix A. CRC32c Checksum Calculation . . . . . . . . . . . . 152		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159		Authors' Addresses
	1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.
	2. Introduction		1. Introduction
	This section explains the reasoning behind the development of the		This section explains the reasoning behind the development of the
	Stream Control Transmission Protocol (SCTP), the services it offers,		Stream Control Transmission Protocol (SCTP), the services it offers,
	and the basic concepts needed to understand the detailed description		and the basic concepts needed to understand the detailed description
	of the protocol.		of the protocol.
	This document obsoletes [RFC4960], if approved. In addition to that,		This document obsoletes [RFC4960]. In addition to that, it
	it incorporates the specification of the chunk flags registry from		incorporates the specification of the chunk flags registry from
	[RFC6096] and the specification of the I bit of DATA chunks from		[RFC6096] and the specification of the I bit of DATA chunks from
	[RFC7053]. Therefore, [RFC6096] and [RFC7053] are also obsoleted by		[RFC7053]. Therefore, [RFC6096] and [RFC7053] are also obsoleted by
	this document, if approved.		this document.
	2.1. Motivation		1.1. Motivation
	TCP [RFC0793] has performed immense service as the primary means of		TCP [RFC0793] has performed immense service as the primary means of
	reliable data transfer in IP networks. However, an increasing number		reliable data transfer in IP networks. However, an increasing number
	of recent applications have found TCP too limiting, and have		of recent applications have found TCP too limiting and have
	incorporated their own reliable data transfer protocol on top of UDP		incorporated their own reliable data transfer protocol on top of UDP
	[RFC0768]. The limitations that users have wished to bypass include		[RFC0768]. The limitations that users have wished to bypass include
	the following:		the following:
	* TCP provides both reliable data transfer and strict order-of-		* TCP provides both reliable data transfer and strict order-of-
	transmission delivery of data. Some applications need reliable		transmission delivery of data. Some applications need reliable
	transfer without sequence maintenance, while others would be		transfer without sequence maintenance, while others would be
	satisfied with partial ordering of the data. In both of these		satisfied with partial ordering of the data. In both of these
	cases, the head-of-line blocking offered by TCP causes unnecessary		cases, the head-of-line blocking offered by TCP causes unnecessary
	delay.		delay.
	* The stream-oriented nature of TCP is often an inconvenience.		* The stream-oriented nature of TCP is often an inconvenience.
	Applications add their own record marking to delineate their		Applications add their own record marking to delineate their
	messages, and make explicit use of the push facility to ensure		messages and make explicit use of the push facility to ensure that
	that a complete message is transferred in a reasonable time.		a complete message is transferred in a reasonable time.
	* The limited scope of TCP sockets complicates the task of providing		* The limited scope of TCP sockets complicates the task of providing
	highly-available data transfer capability using multi-homed hosts.		highly available data transfer capability using multi-homed hosts.
	* TCP is relatively vulnerable to denial-of-service attacks, such as		* TCP is relatively vulnerable to denial-of-service attacks, such as
	SYN attacks.		SYN attacks.
	Transport of PSTN signaling across the IP network is an application		Transport of PSTN signaling across the IP network is an application
	for which all of these limitations of TCP are relevant. While this		for which all of these limitations of TCP are relevant. While this
	application directly motivated the development of SCTP, other		application directly motivated the development of SCTP, other
	applications might find SCTP a good match to their requirements. One		applications might find SCTP a good match to their requirements. One
	example of this is the use of datachannels in the WebRTC		example of this is the use of data channels in the WebRTC
	infrastructure.		infrastructure.
	2.2. Architectural View of SCTP		1.2. Architectural View of SCTP
	SCTP is viewed as a layer between the SCTP user application ("SCTP		SCTP is viewed as a layer between the SCTP user application ("SCTP
	user" for short) and a connectionless packet network service such as		user" for short) and a connectionless packet network service, such as
	IP. The remainder of this document assumes SCTP runs on top of IP.		IP. The remainder of this document assumes SCTP runs on top of IP.
	The basic service offered by SCTP is the reliable transfer of user		The basic service offered by SCTP is the reliable transfer of user
	messages between peer SCTP users. It performs this service within		messages between peer SCTP users. It performs this service within
	the context of an association between two SCTP endpoints. Section 11		the context of an association between two SCTP endpoints. Section 11
	of this document sketches the API that exists at the boundary between		of this document sketches the API that exists at the boundary between
	the SCTP and the SCTP upper layers.		SCTP and the SCTP upper layers.
	SCTP is connection-oriented in nature, but the SCTP association is a		SCTP is connection oriented in nature, but the SCTP association is a
	broader concept than the TCP connection. SCTP provides the means for		broader concept than the TCP connection. SCTP provides the means for
	each SCTP endpoint (Section 2.3) to provide the other endpoint		each SCTP endpoint (Section 1.3) to provide the other endpoint
	(during association startup) with a list of transport addresses		(during association startup) with a list of transport addresses
	(i.e., multiple IP addresses in combination with an SCTP port)		(i.e., multiple IP addresses in combination with an SCTP port)
	through which that endpoint can be reached and from which it will		through which that endpoint can be reached and from which it will
	originate SCTP packets. The association spans transfers over all of		originate SCTP packets. The association spans transfers over all of
	the possible source/destination combinations that can be generated		the possible source/destination combinations that can be generated
	from each endpoint's lists.		from each endpoint's lists.
	_____________ _____________		_____________ _____________
	| SCTP User | | SCTP User |		| SCTP User | | SCTP User |
	| Application | | Application |		| Application | | Application |
	skipping to change at page 8, line 32 ¶		skipping to change at line 352 ¶
	|_____________| ---- |_____________|		|_____________| ---- |_____________|
	SCTP Node A |<-------- Network transport ------->| SCTP Node B		SCTP Node A |<-------- Network transport ------->| SCTP Node B
	Figure 1: An SCTP Association		Figure 1: An SCTP Association
	In addition to encapsulating SCTP packets in IPv4 or IPv6, it is also		In addition to encapsulating SCTP packets in IPv4 or IPv6, it is also
	possible to encapsulate SCTP packets in UDP as specified in [RFC6951]		possible to encapsulate SCTP packets in UDP as specified in [RFC6951]
	or encapsulate them in DTLS as specified in [RFC8261].		or encapsulate them in DTLS as specified in [RFC8261].
	2.3. Key Terms		1.3. Key Terms
	Some of the language used to describe SCTP has been introduced in the		Some of the language used to describe SCTP has been introduced in the
	previous sections. This section provides a consolidated list of the		previous sections. This section provides a consolidated list of the
	key terms and their definitions.		key terms and their definitions.
	Active Destination Transport Address: A transport address on a peer		Active Destination Transport Address: A transport address on a peer
	endpoint that a transmitting endpoint considers available for		endpoint that a transmitting endpoint considers available for
	receiving user messages.		receiving user messages.
	Association Maximum DATA Chunk Size (AMDCS): The smallest Path		Association Maximum DATA Chunk Size (AMDCS): The smallest Path
	Maximum DATA Chunk Size (PMDCS) of all destination addresses.		Maximum DATA Chunk Size (PMDCS) of all destination addresses.
	Bundling Of Chunks: An optional multiplexing operation, whereby more		Bundling of Chunks: An optional multiplexing operation, whereby more
	than one chunk can be carried in the same SCTP packet.		than one chunk can be carried in the same SCTP packet.
	Bundling Of User Messages: An optional multiplexing operation,		Bundling of User Messages: An optional multiplexing operation,
	whereby more than one user message can be carried in the same SCTP		whereby more than one user message can be carried in the same SCTP
	packet. Each user message occupies its own DATA chunk.		packet. Each user message occupies its own DATA chunk.
	Chunk: A unit of information within an SCTP packet, consisting of a		Chunk: A unit of information within an SCTP packet, consisting of a
	chunk header and chunk-specific content.		chunk header and chunk-specific content.
	Congestion Window (cwnd): An SCTP variable that limits outstanding		Congestion Window (cwnd): An SCTP variable that limits outstanding
	data, in number of bytes, that a sender can send to a particular		data, in number of bytes, that a sender can send to a particular
	destination transport address before receiving an acknowledgement.		destination transport address before receiving an acknowledgement.
	Control Chunk: A chunk not being used for transmitting user data,		Control Chunk: A chunk not being used for transmitting user data,
	i.e. every chunk which is not a DATA chunk.		i.e., every chunk that is not a DATA chunk.
	Cumulative TSN Ack Point: The Transmission Sequence Number (TSN) of		Cumulative TSN Ack Point: The Transmission Sequence Number (TSN) of
	the last DATA chunk acknowledged via the Cumulative TSN Ack field		the last DATA chunk acknowledged via the Cumulative TSN Ack field
	of a SACK chunk.		of a SACK chunk.
	Flightsize: The number of bytes of outstanding data to a particular		Flightsize: The number of bytes of outstanding data to a particular
	destination transport address at any given time.		destination transport address at any given time.
	Idle Destination Address: An address that has not had user messages		Idle Destination Address: An address that has not had user messages
	sent to it within some length of time, normally the 'HB.interval'		sent to it within some length of time, normally the 'HB.interval'
	or greater.		or greater.
	Inactive Destination Transport Address: An address that is		Inactive Destination Transport Address: An address that is
	considered inactive due to errors and unavailable to transport		considered inactive due to errors and unavailable to transport
	user messages.		user messages.
	Message (or User Message): Data submitted to SCTP by the Upper Layer		Message (or User Message): Data submitted to SCTP by the Upper-Layer
	Protocol (ULP).		Protocol (ULP).
	Network Byte Order: Most significant byte first, a.k.a., big endian.		Network Byte Order: Most significant byte first, a.k.a., big endian.
	Ordered Message: A user message that is delivered in order with		Ordered Message: A user message that is delivered in order with
	respect to all previous user messages sent within the stream on		respect to all previous user messages sent within the stream on
	which the message was sent.		which the message was sent.
	Outstanding Data (or Data Outstanding or Data In Flight): The total		Outstanding Data (or Data Outstanding or Data In Flight): The total
	size of the DATA chunks associated with outstanding TSNs. A		size of the DATA chunks associated with outstanding TSNs. A
	retransmitted DATA chunk is counted once in outstanding data. A		retransmitted DATA chunk is counted once in outstanding data. A
	DATA chunk that is classified as lost but that has not yet been		DATA chunk that is classified as lost but that has not yet been
	retransmitted is not in outstanding data.		retransmitted is not in outstanding data.
	Outstanding TSN (at an SCTP Endpoint): A TSN (and the associated		Outstanding TSN (at an SCTP Endpoint): A TSN (and the associated
	DATA chunk) that has been sent by the endpoint but for which it		DATA chunk) that has been sent by the endpoint but for which it
	has not yet received an acknowledgement.		has not yet received an acknowledgement.
	Out Of The Blue (OOTB) Packet: A correctly formed packet, for which		"Out of the Blue" (OOTB) Packet: A correctly formed packet, for
	the receiver can not identify the association it belongs to. See		which the receiver cannot identify the association it belongs to.
	Section 8.4.		See Section 8.4.
	Path: The route taken by the SCTP packets sent by one SCTP endpoint		Path: The route taken by the SCTP packets sent by one SCTP endpoint
	to a specific destination transport address of its peer SCTP		to a specific destination transport address of its peer SCTP
	endpoint. Sending to different destination transport addresses		endpoint. Sending to different destination transport addresses
	does not necessarily guarantee getting separate paths. Within		does not necessarily guarantee getting separate paths. Within
	this specification, a path is identified by the destination		this specification, a path is identified by the destination
	transport address, since the routing is assumed to be stable.		transport address, since the routing is assumed to be stable.
	This includes in particular the source address being selected when		This includes, in particular, the source address being selected
	sending packets to the destination address.		when sending packets to the destination address.
	Path Maximum DATA Chunk Size (PMDCS): The maximum size (including		Path Maximum DATA Chunk Size (PMDCS): The maximum size (including
	the DATA chunk header) of a DATA chunk which fits into an SCTP		the DATA chunk header) of a DATA chunk that fits into an SCTP
	packet not exceeding the PMTU of a particular destination address.		packet not exceeding the PMTU of a particular destination address.
	Path Maximum Transmission Unit (PMTU): The maximum size (including		Path Maximum Transmission Unit (PMTU): The maximum size (including
	the SCTP common header and all chunks including their paddings) of		the SCTP common header and all chunks including their paddings) of
	an SCTP packet which can be sent to a particular destination		an SCTP packet that can be sent to a particular destination
	address without using IP level fragmentation.		address without using IP-level fragmentation.
	Primary Path: The primary path is the destination and source address		Primary Path: The destination and source address that will be put
	that will be put into a packet outbound to the peer endpoint by		into a packet outbound to the peer endpoint by default. The
	default. The definition includes the source address since an		definition includes the source address since an implementation MAY
	implementation MAY wish to specify both destination and source		wish to specify both destination and source address to better
	address to better control the return path taken by reply chunks		control the return path taken by reply chunks and on which
	and on which interface the packet is transmitted when the data		interface the packet is transmitted when the data sender is multi-
	sender is multi-homed.		homed.
	Receiver Window (rwnd): An SCTP variable a data sender uses to store		Receiver Window (rwnd): An SCTP variable a data sender uses to store
	the most recently calculated receiver window of its peer, in		the most recently calculated receiver window of its peer, in
	number of bytes. This gives the sender an indication of the space		number of bytes. This gives the sender an indication of the space
	available in the receiver's inbound buffer.		available in the receiver's inbound buffer.
	SCTP Association: A protocol relationship between SCTP endpoints,		SCTP Association: A protocol relationship between SCTP endpoints,
	composed of the two SCTP endpoints and protocol state information		composed of the two SCTP endpoints and protocol state information,
	including Verification Tags and the currently active set of		including Verification Tags and the currently active set of
	Transmission Sequence Numbers (TSNs), etc. An association can be		Transmission Sequence Numbers (TSNs), etc. An association can be
	uniquely identified by the transport addresses used by the		uniquely identified by the transport addresses used by the
	endpoints in the association. Two SCTP endpoints MUST NOT have		endpoints in the association. Two SCTP endpoints MUST NOT have
	more than one SCTP association between them at any given time.		more than one SCTP association between them at any given time.
	SCTP Endpoint: The logical sender/receiver of SCTP packets. On a		SCTP Endpoint: The logical sender/receiver of SCTP packets. On a
	multi-homed host, an SCTP endpoint is represented to its peers as		multi-homed host, an SCTP endpoint is represented to its peers as
	a combination of a set of eligible destination transport addresses		a combination of a set of eligible destination transport addresses
	to which SCTP packets can be sent and a set of eligible source		to which SCTP packets can be sent and a set of eligible source
	transport addresses from which SCTP packets can be received. All		transport addresses from which SCTP packets can be received. All
	transport addresses used by an SCTP endpoint MUST use the same		transport addresses used by an SCTP endpoint MUST use the same
	port number, but can use multiple IP addresses. A transport		port number but can use multiple IP addresses. A transport
	address used by an SCTP endpoint MUST NOT be used by another SCTP		address used by an SCTP endpoint MUST NOT be used by another SCTP
	endpoint. In other words, a transport address is unique to an		endpoint. In other words, a transport address is unique to an
	SCTP endpoint.		SCTP endpoint.
	SCTP Packet (or Packet): The unit of data delivery across the		SCTP Packet (or Packet): The unit of data delivery across the
	interface between SCTP and the connectionless packet network		interface between SCTP and the connectionless packet network
	(e.g., IP). An SCTP packet includes the common SCTP header,		(e.g., IP). An SCTP packet includes the common SCTP header,
	possible SCTP control chunks, and user data encapsulated within		possible SCTP control chunks, and user data encapsulated within
	SCTP DATA chunks.		SCTP DATA chunks.
	SCTP User Application (or SCTP User): The logical higher-layer		SCTP User Application (or SCTP User): The logical higher-layer
	application entity which uses the services of SCTP, also called		application entity that uses the services of SCTP, also called the
	the Upper-Layer Protocol (ULP).		Upper-Layer Protocol (ULP).
	Slow-Start Threshold (ssthresh): An SCTP variable. This is the		Slow-Start Threshold (ssthresh): An SCTP variable. This is the
	threshold that the endpoint will use to determine whether to		threshold that the endpoint will use to determine whether to
	perform slow start or congestion avoidance on a particular		perform slow-start or congestion avoidance on a particular
	destination transport address. Ssthresh is in number of bytes.		destination transport address. Ssthresh is in number of bytes.
	State Cookie: A container of all information needed to establish an		State Cookie: A container of all information needed to establish an
	association.		association.
	Stream: A unidirectional logical channel established from one to		Stream: A unidirectional logical channel established from one to
	another associated SCTP endpoint, within which all user messages		another associated SCTP endpoint, within which all user messages
	are delivered in sequence except for those submitted to the		are delivered in sequence, except for those submitted to the
	unordered delivery service.		unordered delivery service.
	Note: The relationship between stream numbers in opposite		Note: The relationship between stream numbers in opposite
	directions is strictly a matter of how the applications use them.		directions is strictly a matter of how the applications use them.
	It is the responsibility of the SCTP user to create and manage		It is the responsibility of the SCTP user to create and manage
	these correlations if they are so desired.		these correlations if they are so desired.
	Stream Sequence Number: A 16-bit sequence number used internally by		Stream Sequence Number: A 16-bit sequence number used internally by
	SCTP to ensure sequenced delivery of the user messages within a		SCTP to ensure sequenced delivery of the user messages within a
	given stream. One Stream Sequence Number is attached to each		given stream. One Stream Sequence Number is attached to each
	skipping to change at page 12, line 16 ¶		skipping to change at line 520 ¶
	by an SCTP endpoint for each of its existing SCTP associations to		by an SCTP endpoint for each of its existing SCTP associations to
	other SCTP endpoints. TCB contains all the status and operational		other SCTP endpoints. TCB contains all the status and operational
	information for the endpoint to maintain and manage the		information for the endpoint to maintain and manage the
	corresponding association.		corresponding association.
	Transmission Sequence Number (TSN): A 32-bit sequence number used		Transmission Sequence Number (TSN): A 32-bit sequence number used
	internally by SCTP. One TSN is attached to each chunk containing		internally by SCTP. One TSN is attached to each chunk containing
	user data to permit the receiving SCTP endpoint to acknowledge its		user data to permit the receiving SCTP endpoint to acknowledge its
	receipt and detect duplicate deliveries.		receipt and detect duplicate deliveries.
	Transport Address: A transport address is traditionally defined by a		Transport Address: A transport address is typically defined by a
	network-layer address, a transport-layer protocol, and a		network-layer address, a transport-layer protocol, and a
	transport-layer port number. In the case of SCTP running over IP,		transport-layer port number. In the case of SCTP running over IP,
	a transport address is defined by the combination of an IP address		a transport address is defined by the combination of an IP address
	and an SCTP port number (where SCTP is the transport protocol).		and an SCTP port number (where SCTP is the transport protocol).
	Unordered Message: Unordered messages are "unordered" with respect		Unordered Message: Unordered messages are "unordered" with respect
	to any other message; this includes both other unordered messages		to any other message; this includes both other unordered messages
	as well as other ordered messages. An unordered message might be		as well as other ordered messages. An unordered message might be
	delivered prior to or later than ordered messages sent on the same		delivered prior to or later than ordered messages sent on the same
	stream.		stream.
	User Message: The unit of data delivery across the interface between		User Message: The unit of data delivery across the interface between
	SCTP and its user.		SCTP and its user.
	Verification Tag: A 32-bit unsigned integer that is randomly		Verification Tag: A 32-bit unsigned integer that is randomly
	generated. The Verification Tag provides a key that allows a		generated. The Verification Tag provides a key that allows a
	receiver to verify that the SCTP packet belongs to the current		receiver to verify that the SCTP packet belongs to the current
	association and is not an old or stale packet from a previous		association and is not an old or stale packet from a previous
	association.		association.
	2.4. Abbreviations		1.4. Abbreviations
			MAC Message Authentication Code [RFC2104]
			RTO Retransmission Timeout
			RTT Round-Trip Time
	MAC Message Authentication Code [RFC2104]
	RTO Retransmission Timeout
	RTT Round-Trip Time
	RTTVAR Round-Trip Time Variation		RTTVAR Round-Trip Time Variation
	SCTP Stream Control Transmission Protocol
	SRTT Smoothed RTT
	TCB Transmission Control Block
	TLV Type-Length-Value coding format
	TSN Transmission Sequence Number
	ULP Upper-Layer Protocol
	2.5. Functional View of SCTP		SCTP Stream Control Transmission Protocol
			SRTT Smoothed RTT
			TCB Transmission Control Block
			TLV Type-Length-Value coding format
			TSN Transmission Sequence Number
			ULP Upper-Layer Protocol
			1.5. Functional View of SCTP
	The SCTP transport service can be decomposed into a number of		The SCTP transport service can be decomposed into a number of
	functions. These are depicted in Figure 2 and explained in the		functions. These are depicted in Figure 2 and explained in the
	remainder of this section.		remainder of this section.
	SCTP User Application		SCTP User Application
	-----------------------------------------------------		-----------------------------------------------------
	_____________ ____________________		_____________ ____________________
	| | | Sequenced Delivery |		| | | Sequenced Delivery |
	skipping to change at page 13, line 43 ¶		skipping to change at line 601 ¶
	| | ________________________________		| | ________________________________
	| | | Packet Validation |		| | | Packet Validation |
	| | |________________________________|		| | |________________________________|
	| |		| |
	| | ________________________________		| | ________________________________
	| | | Path Management |		| | | Path Management |
	|_____________| |________________________________|		|_____________| |________________________________|
	Figure 2: Functional View of the SCTP Transport Service		Figure 2: Functional View of the SCTP Transport Service
	2.5.1. Association Startup and Takedown		1.5.1. Association Startup and Takedown
	An association is initiated by a request from the SCTP user (see the		An association is initiated by a request from the SCTP user (see the
	description of the ASSOCIATE (or SEND) primitive in Section 11).		description of the ASSOCIATE (or SEND) primitive in Section 11).
	A cookie mechanism, similar to one described by Karn and Simpson in		A cookie mechanism, similar to one described by Karn and Simpson in
	[RFC2522], is employed during the initialization to provide		[RFC2522], is employed during the initialization to provide
	protection against synchronization attacks. The cookie mechanism		protection against synchronization attacks. The cookie mechanism
	uses a four-way handshake, the last two legs of which are allowed to		uses a four-way handshake, the last two legs of which are allowed to
	carry user data for fast setup. The startup sequence is described in		carry user data for fast setup. The startup sequence is described in
	Section 5 of this document.		Section 5 of this document.
	skipping to change at page 14, line 26 ¶		skipping to change at line 627 ¶
	primitive) or as a result of an error condition detected within the		primitive) or as a result of an error condition detected within the
	SCTP layer. Section 9 describes both the graceful and the ungraceful		SCTP layer. Section 9 describes both the graceful and the ungraceful
	close procedures.		close procedures.
	SCTP does not support a half-open state (like TCP) wherein one side		SCTP does not support a half-open state (like TCP) wherein one side
	continues sending data while the other end is closed. When either		continues sending data while the other end is closed. When either
	endpoint performs a shutdown, the association on each peer will stop		endpoint performs a shutdown, the association on each peer will stop
	accepting new data from its user and only deliver data in queue at		accepting new data from its user and only deliver data in queue at
	the time of the graceful close (see Section 9).		the time of the graceful close (see Section 9).
	2.5.2. Sequenced Delivery within Streams		1.5.2. Sequenced Delivery within Streams
	The term "stream" is used in SCTP to refer to a sequence of user		The term "stream" is used in SCTP to refer to a sequence of user
	messages that are to be delivered to the upper-layer protocol in		messages that are to be delivered to the upper-layer protocol in
	order with respect to other messages within the same stream. This is		order with respect to other messages within the same stream. This is
	in contrast to its usage in TCP, where it refers to a sequence of		in contrast to its usage in TCP, where it refers to a sequence of
	bytes (in this document, a byte is assumed to be 8 bits).		bytes (in this document, a byte is assumed to be 8 bits).
	The SCTP user can specify at association startup time the number of		At association startup time, the SCTP user can specify the number of
	streams to be supported by the association. This number is		streams to be supported by the association. This number is
	negotiated with the remote end (see Section 5.1.1). User messages		negotiated with the remote end (see Section 5.1.1). User messages
	are associated with stream numbers (SEND, RECEIVE primitives,		are associated with stream numbers (SEND, RECEIVE primitives;
	Section 11). Internally, SCTP assigns a Stream Sequence Number to		Section 11). Internally, SCTP assigns a Stream Sequence Number to
	each message passed to it by the SCTP user. On the receiving side,		each message passed to it by the SCTP user. On the receiving side,
	SCTP ensures that messages are delivered to the SCTP user in sequence		SCTP ensures that messages are delivered to the SCTP user in sequence
	within a given stream. However, while one stream might be blocked		within a given stream. However, while one stream might be blocked
	waiting for the next in-sequence user message, delivery from other		waiting for the next in-sequence user message, delivery from other
	streams might proceed.		streams might proceed.
	SCTP provides a mechanism for bypassing the sequenced delivery		SCTP provides a mechanism for bypassing the sequenced delivery
	service. User messages sent using this mechanism are delivered to		service. User messages sent using this mechanism are delivered to
	the SCTP user as soon as they are received.		the SCTP user as soon as they are received.
	2.5.3. User Data Fragmentation		1.5.3. User Data Fragmentation
	When needed, SCTP fragments user messages to ensure that the size of		When needed, SCTP fragments user messages to ensure that the size of
	the SCTP packet passed to the lower layer does not exceed the PMTU.		the SCTP packet passed to the lower layer does not exceed the PMTU.
	Once a user message has been fragmented, this fragmentation cannot be		Once a user message has been fragmented, this fragmentation cannot be
	changed anymore. On receipt, fragments are reassembled into complete		changed anymore. On receipt, fragments are reassembled into complete
	messages before being passed to the SCTP user.		messages before being passed to the SCTP user.
	2.5.4. Acknowledgement and Congestion Avoidance		1.5.4. Acknowledgement and Congestion Avoidance
	SCTP assigns a Transmission Sequence Number (TSN) to each user data		SCTP assigns a Transmission Sequence Number (TSN) to each user data
	fragment or unfragmented message. The TSN is independent of any		fragment or unfragmented message. The TSN is independent of any
	Stream Sequence Number assigned at the stream level. The receiving		Stream Sequence Number assigned at the stream level. The receiving
	end acknowledges all TSNs received, even if there are gaps in the		end acknowledges all TSNs received, even if there are gaps in the
	sequence. If a user data fragment or unfragmented message needs to		sequence. If a user data fragment or unfragmented message needs to
	be retransmitted, the TSN assigned to it is used. In this way,		be retransmitted, the TSN assigned to it is used. In this way,
	reliable delivery is kept functionally separate from sequenced stream		reliable delivery is kept functionally separate from sequenced stream
	delivery.		delivery.
	The acknowledgement and congestion avoidance function is responsible		The acknowledgement and congestion avoidance function is responsible
	for packet retransmission when timely acknowledgement has not been		for packet retransmission when timely acknowledgement has not been
	received. Packet retransmission is conditioned by congestion		received. Packet retransmission is conditioned by congestion
	avoidance procedures similar to those used for TCP. See Section 6		avoidance procedures similar to those used for TCP. See Sections 6
	and Section 7 for a detailed description of the protocol procedures		and 7 for detailed descriptions of the protocol procedures associated
	associated with this function.		with this function.
	2.5.5. Chunk Bundling		1.5.5. Chunk Bundling
	As described in Section 3, the SCTP packet as delivered to the lower		As described in Section 3, the SCTP packet as delivered to the lower
	layer consists of a common header followed by one or more chunks.		layer consists of a common header followed by one or more chunks.
	Each chunk contains either user data or SCTP control information. An		Each chunk contains either user data or SCTP control information. An
	SCTP implementation supporting bundling on the sender side might		SCTP implementation supporting bundling on the sender side might
	delay the sending of user messages to allow the corresponding DATA		delay the sending of user messages to allow the corresponding DATA
	chunks to be bundled.		chunks to be bundled.
	The SCTP user has the option to request that an SCTP implementation		The SCTP user has the option to request that an SCTP implementation
	does not delay the sending of a user message just for this purpose.		does not delay the sending of a user message just for this purpose.
	However, even if the SCTP user has chosen this option, the SCTP		However, even if the SCTP user has chosen this option, the SCTP
	implementation might delay the sending due to other reasons, for		implementation might delay the sending due to other reasons (for
	example due to congestion control or flow control, and might also		example, due to congestion control or flow control) and might also
	bundle multiple DATA chunks, if possible.		bundle multiple DATA chunks, if possible.
	2.5.6. Packet Validation		1.5.6. Packet Validation
	A mandatory Verification Tag field and a 32-bit checksum field (see		A mandatory Verification Tag field and a 32-bit checksum field (see
	Appendix A for a description of the CRC32c checksum) are included in		Appendix A for a description of the 32-bit Cyclic Redundancy Check
	the SCTP common header. The Verification Tag value is chosen by each		(CRC32c) checksum) are included in the SCTP common header. The
	end of the association during association startup. Packets received		Verification Tag value is chosen by each end of the association
	without the expected Verification Tag value are discarded, as a		during association startup. Packets received without the expected
	protection against blind masquerade attacks and against stale SCTP		Verification Tag value are discarded, as a protection against blind
	packets from a previous association. The CRC32c checksum is set by		masquerade attacks and against stale SCTP packets from a previous
	the sender of each SCTP packet to provide additional protection		association. The CRC32c checksum is set by the sender of each SCTP
	against data corruption in the network. The receiver of an SCTP		packet to provide additional protection against data corruption in
	packet with an invalid CRC32c checksum silently discards the packet.		the network. The receiver of an SCTP packet with an invalid CRC32c
			checksum silently discards the packet.
	2.5.7. Path Management		1.5.7. Path Management
	The sending SCTP user is able to manipulate the set of transport		The sending SCTP user is able to manipulate the set of transport
	addresses used as destinations for SCTP packets through the		addresses used as destinations for SCTP packets through the
	primitives described in Section 11. The SCTP path management		primitives described in Section 11. The SCTP path management
	function monitors reachability through heartbeats when other packet		function monitors reachability through heartbeats when other packet
	traffic is inadequate to provide this information and advises the		traffic is inadequate to provide this information and advises the
	SCTP user when reachability of any transport address of the peer		SCTP user when reachability of any transport address of the peer
	endpoint changes. The path management function chooses the		endpoint changes. The path management function chooses the
	destination transport address for each outgoing SCTP packet based on		destination transport address for each outgoing SCTP packet based on
	the SCTP user's instructions and the currently perceived reachability		the SCTP user's instructions and the currently perceived reachability
	status of the eligible destination set. The path management function		status of the eligible destination set. The path management function
	is also responsible for reporting the eligible set of local transport		is also responsible for reporting the eligible set of local transport
	addresses to the peer endpoint during association startup, and for		addresses to the peer endpoint during association startup and for
	reporting the transport addresses returned from the peer endpoint to		reporting the transport addresses returned from the peer endpoint to
	the SCTP user.		the SCTP user.
	At association startup, a primary path is defined for each SCTP		At association startup, a primary path is defined for each SCTP
	endpoint, and is used for normal sending of SCTP packets.		endpoint and is used to send SCTP packets normally.
	On the receiving end, the path management is responsible for		On the receiving end, the path management is responsible for
	verifying the existence of a valid SCTP association to which the		verifying the existence of a valid SCTP association to which the
	inbound SCTP packet belongs before passing it for further processing.		inbound SCTP packet belongs before passing it for further processing.
	Note: Path Management and Packet Validation are done at the same		Note: Path Management and Packet Validation are done at the same
	time, so although described separately above, in reality they cannot		time; although described separately above, in reality, they cannot be
	be performed as separate items.		performed as separate items.
	2.6. Serial Number Arithmetic		1.6. Serial Number Arithmetic
	It is essential to remember that the actual Transmission Sequence		It is essential to remember that the actual Transmission Sequence
	Number space is finite, though very large. This space ranges from 0		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		to 2^32 - 1. Since the space is finite, all arithmetic dealing with
	Transmission Sequence Numbers MUST be performed modulo 2^32. This		Transmission Sequence Numbers MUST be performed modulo 2^32. This
	unsigned arithmetic preserves the relationship of sequence numbers as		unsigned arithmetic preserves the relationship of sequence numbers as
	they cycle from 2^32 - 1 to 0 again. There are some subtleties to		they cycle from 2^32 - 1 to 0 again. There are some subtleties to
	computer modulo arithmetic, so great care has to be taken in		computer modulo arithmetic, so great care has to be taken in
	programming the comparison of such values. When referring to TSNs,		programming the comparison of such values. When referring to TSNs,
	the symbol "<=" means "less than or equal" (modulo 2^32).		the symbol "<=" means "less than or equal" (modulo 2^32).
	Comparisons and arithmetic on TSNs in this document SHOULD use Serial		Comparisons and arithmetic on TSNs in this document SHOULD use Serial
	Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.		Number Arithmetic, as defined in [RFC1982], where SERIAL_BITS = 32.
	An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more		An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more
	than 2^31 - 1 above the beginning TSN of its current send window.		than 2^31 - 1 above the beginning TSN of its current send window.
	Doing so will cause problems in comparing TSNs.		Doing so will cause problems in comparing TSNs.
	Transmission Sequence Numbers wrap around when they reach 2^32 - 1.		Transmission Sequence Numbers wrap around when they reach 2^32 - 1.
	That is, the next TSN a DATA chunk MUST use after transmitting TSN =		That is, the next TSN a DATA chunk MUST use after transmitting TSN =
	2^32 - 1 is TSN = 0.		2^32 - 1 is TSN = 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 use normal		All other arithmetic and comparisons in this document use normal
	arithmetic.		arithmetic.
	2.7. Changes from RFC 4960		1.7. Changes from RFC 4960
	SCTP was originally defined in [RFC4960], which this document		SCTP was originally defined in [RFC4960], which this document
	obsoletes, if approved. Readers interested in the details of the		obsoletes. Readers interested in the details of the various changes
	various changes that this document incorporates are asked to consult		that this document incorporates are asked to consult [RFC8540].
	[RFC8540].
	In addition to these and further editorial changes, the following		In addition to these and further editorial changes, the following
	changes have been incorporated in this document:		changes have been incorporated in this document:
	* Update references.		* Update references.
	* Improve the language related to requirements levels.		* Improve the language related to requirements levels.
	* Allow the ASSOCIATE primitive to take multiple remote addresses;		* Allow the ASSOCIATE primitive to take multiple remote addresses;
	also refer to the Socket API specification.		also refer to the socket API specification.
	* Refer to the PLPMTUD specification for path MTU discovery.		* Refer to the Packetization Layer Path MTU Discovery (PLPMTUD)
			specification for path MTU discovery.
	* Move the description of ICMP handling from an Appendix to the main		* Move the description of ICMP handling from the Appendix to the
	text.		main text.
	* Remove the Appendix describing ECN handling from the document.		* Remove the Appendix describing Explicit Congestion Notification
			(ECN) handling from the document.
	* Describe the packet size handling more precisely by introducing		* Describe the packet size handling more precisely by introducing
	PMTU, PMDCS and AMDCS.		PMTU, PMDCS, and AMDCS.
	* Add the definition of control chunk.		* Add the definition of control chunk.
	* Improve the description of the handling of INIT and INIT ACK		* Improve the description of the handling of INIT and INIT ACK
	chunks with invalid mandatory parameters.		chunks with invalid mandatory parameters.
	* Allow using L > 1 for Appropriate Byte Counting (ABC) during slow		* Allow using L > 1 for Appropriate Byte Counting (ABC) during slow
	start.		start.
	* Explicitly describe the reinitialization of the congestion		* Explicitly describe the reinitialization of the congestion
	controller on route changes.		controller on route changes.
	* Improve the terminology to make clear that this specification does		* Improve the terminology to make it clear that this specification
	not describe a full mesh architecture.		does not describe a full mesh architecture.
	* Improve the description of sequence number generation		* Improve the description of sequence number generation
	(Transmission Sequence Number and Stream Sequence Number).		(Transmission Sequence Number and Stream Sequence Number).
	* Improve the description of reneging.		* Improve the description of reneging.
	* Don't require the change of the cumulative TSN ACK anymore for		* Don't require the change of the Cumulative TSN Ack anymore for
	increasing the congestion window. This improves the consistency		increasing the congestion window. This improves the consistency
	with the handling in congestion avoidance.		with the handling in congestion avoidance.
	* Improve the description of the State Cookie.		* Improve the description of the State Cookie.
	* Fix the API for retrieving messages in case of association		* Fix the API for retrieving messages in case of association
	failures.		failures.
			2. Conventions
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. SCTP Packet Format		3. SCTP Packet Format
	An SCTP packet is composed of a common header and chunks. A chunk		An SCTP packet is composed of a common header and chunks. A chunk
	contains either control information or user data.		contains either control information or user data.
	The SCTP packet format is shown below:		The SCTP packet format is shown below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Common Header |		| Common Header |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Chunk #1 |		| Chunk #1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Chunk #n |		| Chunk #n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	INIT, INIT ACK and SHUTDOWN COMPLETE chunks MUST NOT be bundled with		INIT, INIT ACK, and SHUTDOWN COMPLETE chunks MUST NOT be bundled with
	any other chunk into an SCTP packet. All other chunks MAY be bundled		any other chunk into an SCTP packet. All other chunks MAY be bundled
	to form an SCTP packet that does not exceed the PMTU. See		to form an SCTP packet that does not exceed the PMTU. See
	Section 6.10 for more details on chunk bundling.		Section 6.10 for more details on chunk bundling.
	If a user data message does not fit into one SCTP packet it can be		If a user data message does not fit into one SCTP packet, it can be
	fragmented into multiple chunks using the procedure defined in		fragmented into multiple chunks using the procedure defined in
	Section 6.9.		Section 6.9.
	All integer fields in an SCTP packet MUST be transmitted in network		All integer fields in an SCTP packet MUST be transmitted in network
	byte order, unless otherwise stated.		byte order, unless otherwise stated.
	3.1. SCTP Common Header Field Descriptions		3.1. SCTP Common Header Field Descriptions
	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 19, line 44 ¶		skipping to change at line 872 ¶
	| Source Port Number | Destination Port Number |		| Source Port Number | Destination Port Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Verification Tag |		| Verification Tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Checksum |		| Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Source Port Number: 16 bits (unsigned integer)		Source Port Number: 16 bits (unsigned integer)
	This is the SCTP sender's port number. It can be used by the		This is the SCTP sender's port number. It can be used by the
	receiver in combination with the source IP address, the SCTP		receiver in combination with the source IP address, the SCTP
	destination port, and possibly the destination IP address to		Destination Port Number, and possibly the destination IP address
	identify the association to which this packet belongs. The source		to identify the association to which this packet belongs. The
	port number 0 MUST NOT be used.		Source Port Number 0 MUST NOT be used.
	Destination Port Number: 16 bits (unsigned integer)		Destination Port Number: 16 bits (unsigned integer)
	This is the SCTP port number to which this packet is destined.		This is the SCTP port number to which this packet is destined.
	The receiving host will use this port number to de-multiplex the		The receiving host will use this port number to de-multiplex the
	SCTP packet to the correct receiving endpoint/application. The		SCTP packet to the correct receiving endpoint/application. The
	destination port number 0 MUST NOT be used.		Destination Port Number 0 MUST NOT be used.
	Verification Tag: 32 bits (unsigned integer)		Verification Tag: 32 bits (unsigned integer)
	The receiver of an SCTP packet uses the Verification Tag to		The receiver of an SCTP packet uses the Verification Tag to
	validate the sender of this packet. On transmit, the value of the		validate the sender of this packet. On transmit, the value of the
	Verification Tag MUST be set to the value of the Initiate Tag		Verification Tag MUST be set to the value of the Initiate Tag
	received from the peer endpoint during the association		received from the peer endpoint during the association
	initialization, with the following exceptions:		initialization, with the following exceptions:
	* A packet containing an INIT chunk MUST have a zero Verification		* A packet containing an INIT chunk MUST have a zero Verification
	Tag.		Tag.
	* A packet containing a SHUTDOWN COMPLETE chunk with the T bit		* A packet containing a SHUTDOWN COMPLETE chunk with the T bit
	set MUST have the Verification Tag copied from the packet with		set MUST have the Verification Tag copied from the packet with
	the SHUTDOWN ACK chunk.		the SHUTDOWN ACK chunk.
	* A packet containing an ABORT chunk MAY have the verification		* A packet containing an ABORT chunk MAY have the Verification
	tag copied from the packet that caused the ABORT chunk to be		Tag copied from the packet that caused the ABORT chunk to be
	sent. For details see Section 8.4 and Section 8.5.		sent. For details, see Sections 8.4 and 8.5.
	Checksum: 32 bits (unsigned integer)		Checksum: 32 bits (unsigned integer)
	This field contains the checksum of the SCTP packet. Its		This field contains the checksum of the SCTP packet. Its
	calculation is discussed in Section 6.8. SCTP uses the CRC32c		calculation is discussed in Section 6.8. SCTP uses the CRC32c
	algorithm as described in Appendix A for calculating the checksum.		algorithm as described in Appendix A for calculating the checksum.
	3.2. Chunk Field Descriptions		3.2. Chunk Field Descriptions
	The figure below illustrates the field format for the chunks to be		The figure below illustrates the field format for the chunks to be
	transmitted in the SCTP packet. Each chunk is formatted with a Chunk		transmitted in the SCTP packet. Each chunk is formatted with a Chunk
	Type field, a chunk-specific Flag field, a Chunk Length field, and a		Type field, a Chunk Flags field, a Chunk Length field, and a Chunk
	Value field.		Value field.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Chunk Type | Chunk Flags | Chunk Length |		| Chunk Type | Chunk Flags | Chunk Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ \		\ \
	/ Chunk Value /		/ Chunk Value /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Chunk Type: 8 bits (unsigned integer)		Chunk Type: 8 bits (unsigned integer)
	This field identifies the type of information contained in the		This field identifies the type of information contained in the
	Chunk Value field. It takes a value from 0 to 254. The value of		Chunk Value field. It takes a value from 0 to 254. The value of
	255 is reserved for future use as an extension field.		255 is reserved for future use as an extension field.
	The values of Chunk Types are defined as follows:		The values of Chunk Types defined in this document are as follows:
	+==========+===========================================+		+==========+===========================================+
	| ID Value | Chunk Type |		| ID Value | Chunk Type |
	+==========+===========================================+		+==========+===========================================+
	| 0 | Payload Data (DATA) |		| 0 | Payload Data (DATA) |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 1 | Initiation (INIT) |		| 1 | Initiation (INIT) |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 2 | Initiation Acknowledgement (INIT ACK) |		| 2 | Initiation Acknowledgement (INIT ACK) |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	skipping to change at page 21, line 40 ¶		skipping to change at line 964 ¶
	| 11 | Cookie Acknowledgement (COOKIE ACK) |		| 11 | Cookie Acknowledgement (COOKIE ACK) |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 12 | Reserved for Explicit Congestion |		| 12 | Reserved for Explicit Congestion |
	| | Notification Echo (ECNE) |		| | Notification Echo (ECNE) |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 13 | Reserved for Congestion Window Reduced |		| 13 | Reserved for Congestion Window Reduced |
	| | (CWR) |		| | (CWR) |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 14 | Shutdown Complete (SHUTDOWN COMPLETE) |		| 14 | Shutdown Complete (SHUTDOWN COMPLETE) |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 15 to 62 | available |		| 15 to 62 | Unassigned |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 63 | reserved for IETF-defined Chunk |		| 63 | Reserved for IETF-defined Chunk |
	| | Extensions |		| | Extensions |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 64 to | available |		| 64 to | Unassigned |
	| 126 | |		| 126 | |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 127 | reserved for IETF-defined Chunk |		| 127 | Reserved for IETF-defined Chunk |
	| | Extensions |		| | Extensions |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 128 to | available |		| 128 to | Unassigned |
	| 190 | |		| 190 | |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 191 | reserved for IETF-defined Chunk |		| 191 | Reserved for IETF-defined Chunk |
	| | Extensions |		| | Extensions |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 192 to | available |		| 192 to | Unassigned |
	| 254 | |		| 254 | |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	| 255 | reserved for IETF-defined Chunk |		| 255 | Reserved for IETF-defined Chunk |
	| | Extensions |		| | Extensions |
	+----------+-------------------------------------------+		+----------+-------------------------------------------+
	Table 1: Chunk Types		Table 1: Chunk Types
	Note: The ECNE and CWR chunk types are reserved for future use of		Note: The ECNE and CWR chunk types are reserved for future use of
	Explicit Congestion Notification (ECN).		Explicit Congestion Notification (ECN).
	Chunk Types are encoded such that the highest-order 2 bits specify		Chunk Types are encoded such that the highest-order 2 bits specify
	the action that is taken if the processing endpoint does not		the action that is taken if the processing endpoint does not
	recognize the Chunk Type.		recognize the Chunk Type.
	+----+--------------------------------------------------+		+----+--------------------------------------------------+
	| 00 | Stop processing this SCTP packet; discard the |		| 00 | Stop processing this SCTP packet and discard the |
	| | unrecognized chunk and all further chunks. |		| | unrecognized chunk and all further chunks. |
	+----+--------------------------------------------------+		+----+--------------------------------------------------+
	| 01 | Stop processing this SCTP packet, discard the |		| 01 | Stop processing this SCTP packet, discard the |
	| | unrecognized chunk and all further chunks, and |		| | unrecognized chunk and all further chunks, and |
	| | report the unrecognized chunk in an ERROR chunk |		| | report the unrecognized chunk in an ERROR chunk |
	| | using the 'Unrecognized Chunk Type' error cause. |		| | using the 'Unrecognized Chunk Type' error cause. |
	+----+--------------------------------------------------+		+----+--------------------------------------------------+
	| 10 | Skip this chunk and continue processing. |		| 10 | Skip this chunk and continue processing. |
	+----+--------------------------------------------------+		+----+--------------------------------------------------+
	| 11 | Skip this chunk and continue processing, but |		| 11 | Skip this chunk and continue processing, but |
	| | report it in an ERROR chunk using the |		| | report it in an ERROR chunk using the |
	| | 'Unrecognized Chunk Type' error cause. |		| | 'Unrecognized Chunk Type' error cause. |
	+----+--------------------------------------------------+		+----+--------------------------------------------------+
	Table 2: Processing of Unknown Chunks		Table 2: Processing of Unknown Chunks
	Chunk Flags: 8 bits		Chunk Flags: 8 bits
	The usage of these bits depends on the Chunk type as given by the		The usage of these bits depends on the Chunk Type, as given by the
	Chunk Type field. Unless otherwise specified, they are set to 0		Chunk Type field. Unless otherwise specified, they are set to 0
	on transmit and are ignored on receipt.		on transmit and are ignored on receipt.
	Chunk Length: 16 bits (unsigned integer)		Chunk Length: 16 bits (unsigned integer)
	This value represents the size of the chunk in bytes, including		This value represents the size of the chunk in bytes, including
	the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.		the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
	Therefore, if the Chunk Value field is zero-length, the Length		Therefore, if the Chunk Value field is zero-length, the Length
	field will be set to 4. The Chunk Length field does not count any		field will be set to 4. The Chunk Length field does not count any
	chunk padding. However, it does include any padding of variable-		chunk padding. However, it does include any padding of variable-
	length parameters other than the last parameter in the chunk.		length parameters other than the last parameter in the chunk.
	skipping to change at page 23, line 36 ¶		skipping to change at line 1053 ¶
	SCTP-defined chunks are described in detail in Section 3.3. The		SCTP-defined chunks are described in detail in Section 3.3. The
	guidelines for IETF-defined chunk extensions can be found in		guidelines for IETF-defined chunk extensions can be found in
	Section 15.1 of this document.		Section 15.1 of this document.
	3.2.1. Optional/Variable-Length Parameter Format		3.2.1. Optional/Variable-Length Parameter Format
	Chunk values of SCTP control chunks consist of a chunk-type-specific		Chunk values of SCTP control chunks consist of a chunk-type-specific
	header of required fields, followed by zero or more parameters. The		header of required fields, followed by zero or more parameters. The
	optional and variable-length parameters contained in a chunk are		optional and variable-length parameters contained in a chunk are
	defined in a Type-Length-Value format as shown below.		defined in a Type-Length-Value format, as shown below.
	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 | Parameter Length |		| Parameter Type | Parameter Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ \		\ \
	/ Parameter Value /		/ Parameter Value /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 24, line 32 ¶		skipping to change at line 1096 ¶
	If the length of the parameter is not a multiple of 4 bytes, the		If the length of the parameter is not a multiple of 4 bytes, the
	sender pads the parameter at the end (i.e., after the Parameter Value		sender pads the parameter at the end (i.e., after the Parameter Value
	field) with all zero bytes. The length of the padding is not		field) with all zero bytes. The length of the padding is not
	included in the Parameter Length field. A sender MUST NOT pad with		included in the Parameter Length field. A sender MUST NOT pad with
	more than 3 bytes. The receiver MUST ignore the padding bytes.		more than 3 bytes. The receiver MUST ignore the padding bytes.
	The Parameter Types are encoded such that the highest-order 2 bits		The Parameter Types are encoded such that the highest-order 2 bits
	specify the action that is taken if the processing endpoint does not		specify the action that is taken if the processing endpoint does not
	recognize the Parameter Type.		recognize the Parameter Type.
	+----+-------------------------------------------------------+		+----+--------------------------------------------------------+
	| 00 | Stop processing this parameter; do not process any |		| 00 | Stop processing this parameter and do not process any |
	| | further parameters within this chunk. |		| | further parameters within this chunk. |
	+----+-------------------------------------------------------+		+----+--------------------------------------------------------+
	| 01 | Stop processing this parameter, do not process any |		| 01 | Stop processing this parameter, do not process any |
	| | further parameters within this chunk, and report the |		| | further parameters within this chunk, and report the |
	| | unrecognized parameter as described in Section 3.2.2. |		| | unrecognized parameter, as described in Section 3.2.2. |
	+----+-------------------------------------------------------+		+----+--------------------------------------------------------+
	| 10 | Skip this parameter and continue processing. |		| 10 | Skip this parameter and continue processing. |
	+----+-------------------------------------------------------+		+----+--------------------------------------------------------+
	| 11 | Skip this parameter and continue processing but |		| 11 | Skip this parameter and continue processing, but |
	| | report the unrecognized parameter as described in |		| | report the unrecognized parameter, as described in |
	| | Section 3.2.2. |		| | Section 3.2.2. |
	+----+-------------------------------------------------------+		+----+--------------------------------------------------------+
	Table 3: Processing of Unknown Parameters		Table 3: Processing of Unknown Parameters
	Please note that, when an INIT or INIT ACK chunk is received, in all		Please note that, when an INIT or INIT ACK chunk is received, in all
	four cases, an INIT ACK or COOKIE ECHO chunk is sent in response,		four cases, an INIT ACK or COOKIE ECHO chunk is sent in response,
	respectively. In the 00 or 01 case, the processing of the parameters		respectively. In the 00 or 01 case, the processing of the parameters
	after the unknown parameter is canceled, but no processing already		after the unknown parameter is canceled, but no processing already
	done is rolled back.		done is rolled back.
	The actual SCTP parameters are defined in the specific SCTP chunk		The actual SCTP parameters are defined in the specific SCTP chunk
	sections. The rules for IETF-defined parameter extensions are		sections. The rules for IETF-defined parameter extensions are
	defined in Section 15.3. Parameter types MUST be unique across all		defined in Section 15.3. Parameter types MUST be unique across all
	chunks. For example, the parameter type '5' is used to represent an		chunks. For example, the parameter type '5' is used to represent an
	IPv4 address (see Section 3.3.2.1). The value '5' then is reserved		IPv4 address (see Section 3.3.2.1.1). The value '5' then is reserved
	across all chunks to represent an IPv4 address and MUST NOT be reused		across all chunks to represent an IPv4 address and MUST NOT be reused
	with a different meaning in any other chunk.		with a different meaning in any other chunk.
	3.2.2. Reporting of Unrecognized Parameters		3.2.2. Reporting of Unrecognized Parameters
	If the receiver of an INIT chunk detects unrecognized parameters and		If the receiver of an INIT chunk detects unrecognized parameters and
	has to report them according to Section 3.2.1, it MUST put the		has to report them according to Section 3.2.1, it MUST put the
	"Unrecognized Parameter" parameter(s) in the INIT ACK chunk sent in		"Unrecognized Parameter" parameter(s) in the INIT ACK chunk sent in
	response to the INIT chunk. Note that if the receiver of the INIT		response to the INIT chunk. Note that, if the receiver of the INIT
	chunk is not going to establish an association (e.g., due to lack of		chunk is not going to establish an association (e.g., due to lack of
	resources), an "Unrecognized Parameter" error cause would not be		resources), an "Unrecognized Parameters" error cause would not be
	included with any ABORT chunk being sent to the sender of the INIT		included with any ABORT chunk being sent to the sender of the INIT
	chunk.		chunk.
	If the receiver of any other chunk (e.g., INIT ACK) detects		If the receiver of any other chunk (e.g., INIT ACK) detects
	unrecognized parameters and has to report them according to		unrecognized parameters and has to report them according to
	Section 3.2.1, it SHOULD bundle the ERROR chunk containing the		Section 3.2.1, it SHOULD bundle the ERROR chunk containing the
	"Unrecognized Parameters" error cause with the chunk sent in response		"Unrecognized Parameters" error cause with the chunk sent in response
	(e.g., COOKIE ECHO). If the receiver of an INIT ACK chunk cannot		(e.g., COOKIE ECHO). If the receiver of an INIT ACK chunk cannot
	bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk		bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk
	MAY be sent separately but not before the COOKIE ACK chunk has been		MAY be sent separately but not before the COOKIE ACK chunk has been
	skipping to change at page 27, line 7 ¶		skipping to change at line 1208 ¶
	of a user message.		of a user message.
	E bit: 1 bit		E bit: 1 bit
	The (E)nding fragment bit, if set, indicates the last fragment of		The (E)nding fragment bit, if set, indicates the last fragment of
	a user message.		a user message.
	Length: 16 bits (unsigned integer)		Length: 16 bits (unsigned integer)
	This field indicates the length of the DATA chunk in bytes from		This field indicates the length of the DATA chunk in bytes from
	the beginning of the type field to the end of the User Data field		the beginning of the type field to the end of the User Data field
	excluding any padding. A DATA chunk with one byte of user data		excluding any padding. A DATA chunk with one byte of user data
	will have Length set to 17 (indicating 17 bytes).		will have the Length field set to 17 (indicating 17 bytes).
	A DATA chunk with a User Data field of length L will have the		A DATA chunk with a User Data field of length L will have the
	Length field set to (16 + L) (indicating 16 + L bytes) where L		Length field set to (16 + L) (indicating 16 + L bytes) where L
	MUST be greater than 0.		MUST be greater than 0.
	TSN: 32 bits (unsigned integer)		TSN: 32 bits (unsigned integer)
	This value represents the TSN for this DATA chunk. The valid		This value represents the TSN for this DATA chunk. The valid
	range of TSN is from 0 to 4294967295 (2^32 - 1). TSN wraps back		range of TSN is from 0 to 4294967295 (2^32 - 1). TSN wraps back
	to 0 after reaching 4294967295.		to 0 after reaching 4294967295.
	skipping to change at page 27, line 38 ¶		skipping to change at line 1239 ¶
	Payload Protocol Identifier: 32 bits (unsigned integer)		Payload Protocol Identifier: 32 bits (unsigned integer)
	This value represents an application (or upper layer) specified		This value represents an application (or upper layer) specified
	protocol identifier. This value is passed to SCTP by its upper		protocol identifier. This value is passed to SCTP by its upper
	layer and sent to its peer. This identifier is not used by SCTP		layer and sent to its peer. This identifier is not used by SCTP
	but can be used by certain network entities, as well as by the		but can be used by certain network entities, as well as by the
	peer application, to identify the type of information being		peer application, to identify the type of information being
	carried in this DATA chunk. This field MUST be sent even in		carried in this DATA chunk. This field MUST be sent even in
	fragmented DATA chunks (to make sure it is available for agents in		fragmented DATA chunks (to make sure it is available for agents in
	the middle of the network). Note that this field is not touched		the middle of the network). Note that this field is not touched
	by an SCTP implementation; The upper layer is responsible for the		by an SCTP implementation; the upper layer is responsible for the
	host to network byte order conversion of this field.		host to network byte order conversion of this field.
	The value 0 indicates that no application identifier is specified		The value 0 indicates that no application identifier is specified
	by the upper layer for this payload data.		by the upper layer for this payload data.
	User Data: variable length		User Data: variable length
	This is the payload user data. The implementation MUST pad the		This is the payload user data. The implementation MUST pad the
	end of the data to a 4-byte boundary with all-zero bytes. Any		end of the data to a 4-byte boundary with all zero bytes. Any
	padding MUST NOT be included in the Length field. A sender MUST		padding MUST NOT be included in the Length field. A sender MUST
	never add more than 3 bytes of padding.		never add more than 3 bytes of padding.
	An unfragmented user message MUST have both the B and E bits set to		An unfragmented user message MUST have both the B and E bits set to
	1. Setting both B and E bits to 0 indicates a middle fragment of a		1. Setting both B and E bits to 0 indicates a middle fragment of a
	multi-fragment user message, as summarized in the following table:		multi-fragment user message, as summarized in the following table:
	+---+---+-------------------------------------------+		+===+===+===========================================+
	| B | E | Description |		| B | E | Description |
	+---+---+-------------------------------------------+		+===+===+===========================================+
	| 1 | 0 | First piece of a fragmented user message |		| 1 | 0 | First piece of a fragmented user message |
	+---+---+-------------------------------------------+		+---+---+-------------------------------------------+
	| 0 | 0 | Middle piece of a fragmented user message |		| 0 | 0 | Middle piece of a fragmented user message |
	+---+---+-------------------------------------------+		+---+---+-------------------------------------------+
	| 0 | 1 | Last piece of a fragmented user message |		| 0 | 1 | Last piece of a fragmented user message |
	+---+---+-------------------------------------------+		+---+---+-------------------------------------------+
	| 1 | 1 | Unfragmented message |		| 1 | 1 | Unfragmented message |
	+---+---+-------------------------------------------+		+---+---+-------------------------------------------+
	Table 4: Fragment Description Flags		Table 4: Fragment Description Flags
	skipping to change at page 29, line 27 ¶		skipping to change at line 1306 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ \		\ \
	/ Optional/Variable-Length Parameters /		/ Optional/Variable-Length Parameters /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The following parameters are specified for the INIT chunk. Unless		The following parameters are specified for the INIT chunk. Unless
	otherwise noted, each parameter MUST only be included once in the		otherwise noted, each parameter MUST only be included once in the
	INIT chunk.		INIT chunk.
	+-----------------------------------+-----------+		+===================================+===========+
	| Fixed Length Parameter | Status |		| Fixed-Length Parameter | Status |
	+-----------------------------------+-----------+		+===================================+===========+
	| Initiate Tag | Mandatory |		| Initiate Tag | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Advertised Receiver Window Credit | Mandatory |		| Advertised Receiver Window Credit | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Number of Outbound Streams | Mandatory |		| Number of Outbound Streams | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Number of Inbound Streams | Mandatory |		| Number of Inbound Streams | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Initial TSN | Mandatory |		| Initial TSN | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	Table 5: Fixed Length Parameters of INIT Chunks		Table 5: Fixed-Length Parameters of INIT Chunks
	+-----------------------------------+------------+----------------+		+===================================+============+================+
	| Variable Length Parameter | Status | Type Value |		| Variable-Length Parameter | Status | Type Value |
	+-----------------------------------+------------+----------------+		+===================================+============+================+
	| IPv4 Address (Note 1) | Optional | 5 |		| IPv4 Address (Note 1) | Optional | 5 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| IPv6 Address (Note 1) | Optional | 6 |		| IPv6 Address (Note 1) | Optional | 6 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| Cookie Preservative | Optional | 9 |		| Cookie Preservative | Optional | 9 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| Reserved for ECN Capable (Note 2) | Optional | 32768 (0x8000) |		| Reserved for ECN Capable (Note 2) | Optional | 32768 (0x8000) |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| Host Name Address (Note 3) | Deprecated | 11 |		| Host Name Address (Note 3) | Deprecated | 11 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| Supported Address Types (Note 4) | Optional | 12 |		| Supported Address Types (Note 4) | Optional | 12 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	Table 6: Variable Length Parameters of INIT Chunks		Table 6: Variable-Length Parameters of INIT Chunks
	Note 1: The INIT chunks can contain multiple addresses that can be		Note 1: The INIT chunks can contain multiple addresses that can be
	IPv4 and/or IPv6 in any combination.		IPv4 and/or IPv6 in any combination.
	Note 2: The ECN Capable field is reserved for future use of Explicit		Note 2: The ECN Capable field is reserved for future use of Explicit
	Congestion Notification.		Congestion Notification.
	Note 3: An INIT chunk MUST NOT contain the Host Name Address		Note 3: An INIT chunk MUST NOT contain the Host Name Address
	parameter. The receiver of an INIT chunk containing a Host Name		parameter. The receiver of an INIT chunk containing a Host Name
	Address parameter MUST send an ABORT chunk and MAY include an		Address parameter MUST send an ABORT chunk and MAY include an
	skipping to change at page 31, line 46 ¶		skipping to change at line 1412 ¶
	A receiver of an INIT chunk with the OS value set to 0 MUST		A receiver of an INIT chunk with the OS value set to 0 MUST
	discard the packet, SHOULD send a packet in response containing an		discard the packet, SHOULD send a packet in response containing an
	ABORT chunk and using the Initiate Tag as the Verification Tag,		ABORT chunk and using the Initiate Tag as the Verification Tag,
	and MUST NOT change the state of any existing association.		and MUST NOT change the state of any existing association.
	Number of Inbound Streams (MIS): 16 bits (unsigned integer)		Number of Inbound Streams (MIS): 16 bits (unsigned integer)
	Defines the maximum number of streams the sender of this INIT		Defines the maximum number of streams the sender of this INIT
	chunk allows the peer end to create in this association. The		chunk allows the peer end to create in this association. The
	value 0 MUST NOT be used.		value 0 MUST NOT be used.
	Note: There is no negotiation of the actual number of streams but		Note: There is no negotiation of the actual number of streams;
	instead the two endpoints will use the min(requested, offered).		instead, the two endpoints will use the min(requested, offered).
	See Section 5.1.1 for details.		See Section 5.1.1 for details.
	A receiver of an INIT chunk with the MIS value set to 0 MUST		A receiver of an INIT chunk with the MIS value set to 0 MUST
	discard the packet, SHOULD send a packet in response containing an		discard the packet, SHOULD send a packet in response containing an
	ABORT chunk and using the Initiate Tag as the Verification Tag,		ABORT chunk and using the Initiate Tag as the Verification Tag,
	and MUST NOT change the state of any existing association.		and MUST NOT change the state of any existing association.
	Initial TSN (I-TSN): 32 bits (unsigned integer)		Initial TSN (I-TSN): 32 bits (unsigned integer)
	Defines the initial TSN that the sender of the INIT chunk will		Defines the TSN that the sender of the INIT chunk will use
	use. The valid range is from 0 to 4294967295 and the Initial TSN		initially. The valid range is from 0 to 4294967295 and the
	SHOULD be set to a random value in that range. The methods		Initial TSN SHOULD be set to a random value in that range. The
	described in [RFC4086] can be used for the Initial TSN		methods described in [RFC4086] can be used for the Initial TSN
	randomization.		randomization.
	3.3.2.1. Optional or Variable-Length Parameters in INIT chunks		3.3.2.1. Optional or Variable-Length Parameters in INIT chunks
	The following parameters follow the Type-Length-Value format as		The following parameters follow the Type-Length-Value format as
	defined in Section 3.2.1. Any Type-Length-Value fields MUST be		defined in Section 3.2.1. Any Type-Length-Value fields MUST be
	placed after the fixed-length fields. (The fixed-length fields are		placed after the fixed-length fields. (The fixed-length fields are
	defined in the previous section.)		defined in the previous section.)
	3.3.2.1.1. IPv4 Address (5)		3.3.2.1.1. IPv4 Address (5)
	skipping to change at page 33, line 7 ¶		skipping to change at line 1466 ¶
	| |		| |
	| IPv6 Address |		| IPv6 Address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IPv6 Address: 128 bits (unsigned integer)		IPv6 Address: 128 bits (unsigned integer)
	Contains an IPv6 [RFC8200] address of the sending endpoint. It is		Contains an IPv6 [RFC8200] address of the sending endpoint. It is
	binary encoded.		binary encoded.
	A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], but		A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291] but
	SHOULD instead use an IPv4 Address parameter for an IPv4 address.		SHOULD instead use an IPv4 Address parameter for an IPv4 address.
	Combined with the Source Port Number in the SCTP common header, the		Combined with the Source Port Number in the SCTP common header, the
	value passed in an IPv4 or IPv6 Address parameter indicates a		value passed in an IPv4 or IPv6 Address parameter indicates a
	transport address the sender of the INIT chunk will support for the		transport address the sender of the INIT chunk will support for the
	association being initiated. That is, during the life time of this		association being initiated. That is, during the life time of this
	association, this IP address can appear in the source address field		association, this IP address can appear in the source address field
	of an IP datagram sent from the sender of the INIT chunk, and can be		of an IP datagram sent from the sender of the INIT chunk and can be
	used as a destination address of an IP datagram sent from the		used as a destination address of an IP datagram sent from the
	receiver of the INIT chunk.		receiver of the INIT chunk.
	More than one IP Address parameter can be included in an INIT chunk		More than one IP Address parameter can be included in an INIT chunk
	when the sender of the INIT chunk is multi-homed. Moreover, a multi-		when the sender of the INIT chunk is multi-homed. Moreover, a multi-
	homed endpoint might have access to different types of network; thus,		homed endpoint might have access to different types of network; thus,
	more than one address type can be present in one INIT chunk, i.e.,		more than one address type can be present in one INIT chunk, i.e.,
	IPv4 and IPv6 addresses are allowed in the same INIT chunk.		IPv4 and IPv6 addresses are allowed in the same INIT chunk.
	If the INIT chunk contains at least one IP Address parameter, then		If the INIT chunk contains at least one IP Address parameter, then
	skipping to change at page 33, line 41 ¶		skipping to change at line 1500 ¶
	the received IP datagram as its sole destination address for the		the received IP datagram as its sole destination address for the
	association.		association.
	Note that not using any IP Address parameters in the INIT and INIT		Note that not using any IP Address parameters in the INIT and INIT
	ACK chunk is a way to make an association more likely to work in		ACK chunk is a way to make an association more likely to work in
	combination with Network Address Translation (NAT).		combination with Network Address Translation (NAT).
	3.3.2.1.3. Cookie Preservative (9)		3.3.2.1.3. Cookie Preservative (9)
	The sender of the INIT chunk uses this parameter to suggest to the		The sender of the INIT chunk uses this parameter to suggest to the
	receiver of the INIT chunk a longer life-span for the State Cookie.		receiver of the INIT chunk a longer life span for the State Cookie.
	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 = 9 | Length = 8 |		| Type = 9 | Length = 8 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Suggested Cookie Life-Span Increment (msec.) |		| Suggested Cookie Life-Span Increment (msec.) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Suggested Cookie Life-Span Increment: 32 bits (unsigned integer)		Suggested Cookie Life-Span Increment: 32 bits (unsigned integer)
	This parameter indicates to the receiver how much increment in		This parameter indicates to the receiver how much increment in
	milliseconds the sender wishes the receiver to add to its default		milliseconds the sender wishes the receiver to add to its default
	cookie life-span.		cookie life span.
	This optional parameter MAY be added to the INIT chunk by the		This optional parameter MAY be added to the INIT chunk by the
	sender when it reattempts establishing an association with a peer		sender when it reattempts establishing an association with a peer
	to which its previous attempt of establishing the association		to which its previous attempt of establishing the association
	failed due to a stale cookie operation error. The receiver MAY		failed due to a stale cookie operation error. The receiver MAY
	choose to ignore the suggested cookie life-span increase for its		choose to ignore the suggested cookie life span increase for its
	own security reasons.		own security reasons.
	3.3.2.1.4. Host Name Address (11)		3.3.2.1.4. Host Name Address (11)
	The sender of an INIT chunk or INIT ACK chunk MUST NOT include this		The sender of an INIT chunk or INIT ACK chunk MUST NOT include this
	parameter. The usage of the Host Name Address parameter is		parameter. The usage of the Host Name Address parameter is
	deprecated. The receiver of an INIT chunk or an INIT ACK containing		deprecated. The receiver of an INIT chunk or an INIT ACK containing
	a Host Name Address parameter MUST send an ABORT chunk and MAY		a Host Name Address parameter MUST send an ABORT chunk and MAY
	include an "Unresolvable Address" error cause.		include an "Unresolvable Address" error cause.
	skipping to change at page 34, line 42 ¶		skipping to change at line 1549 ¶
	Host Name: variable length		Host Name: variable length
	This field contains a host name in "host name syntax" per		This field contains a host name in "host name syntax" per
	Section 2.1 of [RFC1123]. The method for resolving the host name		Section 2.1 of [RFC1123]. The method for resolving the host name
	is out of scope of SCTP.		is out of scope of SCTP.
	At least one null terminator is included in the Host Name string		At least one null terminator is included in the Host Name string
	and MUST be included in the length.		and MUST be included in the length.
	3.3.2.1.5. Supported Address Types (12)		3.3.2.1.5. Supported Address Types (12)
	The sender of INIT chunk uses this parameter to list all the address		The sender of the INIT chunk uses this parameter to list all the
	types it can support.		address types it can support.
	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 = 12 | Length |		| Type = 12 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address Type #1 | Address Type #2 |		| Address Type #1 | Address Type #2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ...... |		| ...... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
	Address Type: 16 bits (unsigned integer)		Address Type: 16 bits (unsigned integer)
	This is filled with the type value of the corresponding address		This is filled with the type value of the corresponding address
	TLV (e.g., 5 for indicating IPv4, 6 for indicating IPv6). The		TLV (e.g., 5 for indicating IPv4, and 6 for indicating IPv6). The
	value indicating the Host Name Address parameter MUST NOT be used		value indicating the Host Name Address parameter MUST NOT be used
	when sending this parameter and MUST be ignored when receiving		when sending this parameter and MUST be ignored when receiving
	this parameter.		this parameter.
	3.3.3. Initiation Acknowledgement (INIT ACK) (2)		3.3.3. Initiation Acknowledgement (INIT ACK) (2)
	The INIT ACK chunk is used to acknowledge the initiation of an SCTP		The INIT ACK chunk is used to acknowledge the initiation of an SCTP
	association. The format of the INIT ACK chunk is shown below:		association. The format of the INIT ACK chunk is shown below:
	0 1 2 3		0 1 2 3
	skipping to change at page 36, line 5 ¶		skipping to change at line 1596 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ \		\ \
	/ Optional/Variable-Length Parameters /		/ Optional/Variable-Length Parameters /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The parameter part of INIT ACK is formatted similarly to the INIT		The parameter part of INIT ACK is formatted similarly to the INIT
	chunk. The following parameters are specified for the INIT ACK		chunk. The following parameters are specified for the INIT ACK
	chunk:		chunk:
	+-----------------------------------+-----------+		+===================================+===========+
	| Fixed Length Parameter | Status |		| Fixed-Length Parameter | Status |
	+-----------------------------------+-----------+		+===================================+===========+
	| Initiate Tag | Mandatory |		| Initiate Tag | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Advertised Receiver Window Credit | Mandatory |		| Advertised Receiver Window Credit | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Number of Outbound Streams | Mandatory |		| Number of Outbound Streams | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Number of Inbound Streams | Mandatory |		| Number of Inbound Streams | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	| Initial TSN | Mandatory |		| Initial TSN | Mandatory |
	+-----------------------------------+-----------+		+-----------------------------------+-----------+
	Table 7: Fixed Length Parameters of INIT ACK		Table 7: Fixed-Length Parameters of INIT ACK
	Chunks		Chunks
	It uses two extra variable parameters: The State Cookie and the		It uses two extra variable parameters: the State Cookie and the
	Unrecognized Parameter:		Unrecognized Parameter.
	+-----------------------------------+------------+----------------+		+===================================+============+================+
	| Variable Length Parameter | Status | Type Value |		| Variable-Length Parameter | Status | Type Value |
	+-----------------------------------+------------+----------------+		+===================================+============+================+
	| State Cookie | Mandatory | 7 |		| State Cookie | Mandatory | 7 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| IPv4 Address (Note 1) | Optional | 5 |		| IPv4 Address (Note 1) | Optional | 5 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| IPv6 Address (Note 1) | Optional | 6 |		| IPv6 Address (Note 1) | Optional | 6 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| Unrecognized Parameter | Optional | 8 |		| Unrecognized Parameter | Optional | 8 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| Reserved for ECN Capable (Note 2) | Optional | 32768 (0x8000) |		| Reserved for ECN Capable (Note 2) | Optional | 32768 (0x8000) |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	| Host Name Address (Note 3) | Deprecated | 11 |		| Host Name Address (Note 3) | Deprecated | 11 |
	+-----------------------------------+------------+----------------+		+-----------------------------------+------------+----------------+
	Table 8: Variable Length Parameters of INIT ACK Chunks		Table 8: Variable-Length Parameters of INIT ACK Chunks
	Note 1: The INIT ACK chunks can contain any number of IP address		Note 1: The INIT ACK chunks can contain any number of IP Address
	parameters that can be IPv4 and/or IPv6 in any combination.		parameters that can be IPv4 and/or IPv6 in any combination.
	Note 2: The ECN Capable field is reserved for future use of Explicit		Note 2: The ECN Capable field is reserved for future use of Explicit
	Congestion Notification.		Congestion Notification.
	Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address		Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address
	parameter. The receiver of INIT ACK chunks containing a Host Name		parameter. The receiver of INIT ACK chunks containing a Host Name
	Address parameter MUST send an ABORT chunk and MAY include an		Address parameter MUST send an ABORT chunk and MAY include an
	"Unresolvable Address" error cause.		"Unresolvable Address" error cause.
	skipping to change at page 37, line 19 ¶		skipping to change at line 1659 ¶
	The receiver of the INIT ACK chunk records the value of the		The receiver of the INIT ACK chunk records the value of the
	Initiate Tag parameter. This value MUST be placed into the		Initiate Tag parameter. This value MUST be placed into the
	Verification Tag field of every SCTP packet that the receiver of		Verification Tag field of every SCTP packet that the receiver of
	the INIT ACK chunk transmits within this association.		the INIT ACK chunk transmits within this association.
	The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for		The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
	more on the selection of the Initiate Tag value.		more on the selection of the Initiate Tag value.
	If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk		If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk
	with the Initiate Tag set to 0, it MUST destroy the TCB and SHOULD		with the Initiate Tag set to 0, it MUST destroy the TCB and SHOULD
	send an ABORT chunk with the T bit set. If such an INIT-ACK chunk		send an ABORT chunk with the T bit set. If such an INIT ACK chunk
	is received in any state other than CLOSED or COOKIE-WAIT, it		is received in any state other than CLOSED or COOKIE-WAIT, it
	SHOULD be discarded silently (see Section 5.2.3).		SHOULD be discarded silently (see Section 5.2.3).
	Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned		Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
	integer)		integer)
	This value represents the dedicated buffer space, in number of		This value represents the dedicated buffer space, in number of
	bytes, the sender of the INIT ACK chunk has reserved in		bytes, the sender of the INIT ACK chunk has reserved in
	association with this window.		association with this window.
	The Advertised Receiver Window Credit MUST NOT be smaller than		The Advertised Receiver Window Credit MUST NOT be smaller than
	skipping to change at page 38, line 7 ¶		skipping to change at line 1691 ¶
	of a_rwnd it sends in SACK chunks.		of a_rwnd it sends in SACK chunks.
	Number of Outbound Streams (OS): 16 bits (unsigned integer)		Number of Outbound Streams (OS): 16 bits (unsigned integer)
	Defines the number of outbound streams the sender of this INIT ACK		Defines the number of outbound streams the sender of this INIT ACK
	chunk wishes to create in this association. The value of 0 MUST		chunk wishes to create in this association. The value of 0 MUST
	NOT be used, and the value MUST NOT be greater than the MIS value		NOT be used, and the value MUST NOT be greater than the MIS value
	sent in the INIT chunk.		sent in the INIT chunk.
	If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk		If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk
	with the OS value set to 0, it MUST destroy the TCB and SHOULD		with the OS value set to 0, it MUST destroy the TCB and SHOULD
	send an ABORT chunk. If such an INIT-ACK chunk is received in any		send an ABORT chunk. If such an INIT ACK chunk is received in any
	state other than CLOSED or COOKIE-WAIT, it SHOULD be discarded		state other than CLOSED or COOKIE-WAIT, it SHOULD be discarded
	silently (see Section 5.2.3).		silently (see Section 5.2.3).
	Number of Inbound Streams (MIS): 16 bits (unsigned integer)		Number of Inbound Streams (MIS): 16 bits (unsigned integer)
	Defines the maximum number of streams the sender of this INIT ACK		Defines the maximum number of streams the sender of this INIT ACK
	chunk allows the peer end to create in this association. The		chunk allows the peer end to create in this association. The
	value 0 MUST NOT be used.		value 0 MUST NOT be used.
	Note: There is no negotiation of the actual number of streams but		Note: There is no negotiation of the actual number of streams, but
	instead the two endpoints will use the min(requested, offered).		instead the two endpoints will use the min(requested, offered).
	See Section 5.1.1 for details.		See Section 5.1.1 for details.
	If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk		If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk
	with the MIS value set to 0, it MUST destroy the TCB and SHOULD		with the MIS value set to 0, it MUST destroy the TCB and SHOULD
	send an ABORT chunk. If such an INIT-ACK chunk is received in any		send an ABORT chunk. If such an INIT ACK chunk is received in any
	state other than CLOSED or COOKIE-WAIT, it SHOULD be discarded		state other than CLOSED or COOKIE-WAIT, it SHOULD be discarded
	silently (see Section 5.2.3).		silently (see Section 5.2.3).
	Initial TSN (I-TSN): 32 bits (unsigned integer)		Initial TSN (I-TSN): 32 bits (unsigned integer)
	Defines the initial TSN that the sender of the INIT ACK chunk will		Defines the TSN that the sender of the INIT ACK chunk will use
	use. The valid range is from 0 to 4294967295 and the Initial TSN		initially. The valid range is from 0 to 4294967295 and the
	SHOULD be set to a random value in that range. The methods		Initial TSN SHOULD be set to a random value in that range. The
	described in [RFC4086] can be used for the Initial TSN		methods described in [RFC4086] can be used for the Initial TSN
	randomization.		randomization.
	Implementation Note: An implementation MUST be prepared to receive an		Implementation Note: An implementation MUST be prepared to receive an
	INIT ACK chunk that is quite large (more than 1500 bytes) due to the		INIT ACK chunk that is quite large (more than 1500 bytes) due to the
	variable size of the State Cookie and the variable address list. For		variable size of the State Cookie and the variable address list. For
	example if a responder to the INIT chunk has 1000 IPv4 addresses it		example, if a responder to the INIT chunk has 1000 IPv4 addresses it
	wishes to send, it would need at least 8,000 bytes to encode this in		wishes to send, it would need at least 8,000 bytes to encode this in
	the INIT ACK chunk.		the INIT ACK chunk.
	If an INIT ACK chunk is received with all mandatory parameters that		If an INIT ACK chunk is received with all mandatory parameters that
	are specified for the INIT ACK chunk, then the receiver SHOULD		are specified for the INIT ACK chunk, then the receiver SHOULD
	process the INIT ACK chunk and send back a COOKIE ECHO chunk. The		process the INIT ACK chunk and send back a COOKIE ECHO chunk. The
	receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the		receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the
	COOKIE ECHO chunk. However, restrictive implementations MAY send		COOKIE ECHO chunk. However, restrictive implementations MAY send
	back an ABORT chunk in response to the INIT ACK chunk.		back an ABORT chunk in response to the INIT ACK chunk.
	In combination with the Source Port carried in the SCTP common		In combination with the Source Port Number carried in the SCTP common
	header, each IP Address parameter in the INIT ACK chunk indicates to		header, each IP Address parameter in the INIT ACK chunk indicates to
	the receiver of the INIT ACK chunk a valid transport address		the receiver of the INIT ACK chunk a valid transport address
	supported by the sender of the INIT ACK chunk for the life time of		supported by the sender of the INIT ACK chunk for the life time of
	the association being initiated.		the association being initiated.
	If the INIT ACK chunk contains at least one IP Address parameter,		If the INIT ACK chunk contains at least one IP Address parameter,
	then the source address of the IP datagram containing the INIT ACK		then the source address of the IP datagram containing the INIT ACK
	chunk and any additional address(es) provided within the INIT ACK		chunk and any additional address(es) provided within the INIT ACK
	chunk MAY be used as destinations by the receiver of the INIT ACK		chunk MAY be used as destinations by the receiver of the INIT ACK
	chunk. If the INIT ACK chunk does not contain any IP Address		chunk. If the INIT ACK chunk does not contain any IP Address
	parameters, the receiver of the INIT ACK chunk MUST use the source		parameters, the receiver of the INIT ACK chunk MUST use the source
	address associated with the received IP datagram as its sole		address associated with the received IP datagram as its sole
	destination address for the association.		destination address for the association.
	The State Cookie and Unrecognized Parameters use the Type-Length-		The State Cookie and Unrecognized Parameters use the Type-Length-
	Value format as defined in Section 3.2.1 and are described below.		Value format as defined in Section 3.2.1 and are described below.
	The other fields are defined the same as their counterparts in the		The other fields are defined in the same way as their counterparts in
	INIT chunk.		the INIT chunk.
	3.3.3.1. Optional or Variable-Length Parameters in INIT ACK chunks		3.3.3.1. Optional or Variable-Length Parameters in INIT ACK Chunks
	The State Cookie and Unrecognized Parameters use the Type-Length-		The State Cookie and Unrecognized Parameters use the Type-Length-
	Value format as defined in Section 3.2.1 and are described below.		Value format, as defined in Section 3.2.1, and are described below.
	The IPv4 Address Parameter is described in Section 3.3.2.1.1, and the		The IPv4 Address parameter is described in Section 3.3.2.1.1, and the
	IPv6 Address Parameter is described in Section 3.3.2.1.2. The Host		IPv6 Address parameter is described in Section 3.3.2.1.2. The Host
	Name Address Parameter is described in Section 3.3.2.1.4 and MUST NOT		Name Address parameter is described in Section 3.3.2.1.4 and MUST NOT
	be included in an INIT ACK chunk. Any Type-Length-Value fields MUST		be included in an INIT ACK chunk. Any Type-Length-Value fields MUST
	be placed after the fixed-length fields. (The fixed-length fields		be placed after the fixed-length fields. (The fixed-length fields
	are defined in the previous section.)		are defined in the previous section.)
	3.3.3.1.1. State Cookie (7)		3.3.3.1.1. State Cookie (7)
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 7 | Length |		| Type = 7 | Length |
	skipping to change at page 40, line 15 ¶		skipping to change at line 1796 ¶
	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 = 8 | Length |		| Type = 8 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Unrecognized Parameter /		/ Unrecognized Parameter /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Unrecognized Parameter: variable length		Unrecognized Parameter: variable length
	The parameter value field will contain an unrecognized parameter		The Parameter Value field will contain an unrecognized parameter
	copied from the INIT chunk complete with Parameter Type, Length,		copied from the INIT chunk complete with Parameter Type, Length,
	and Value fields.		and Value fields.
	3.3.4. Selective Acknowledgement (SACK) (3)		3.3.4. Selective Acknowledgement (SACK) (3)
	This chunk is sent to the peer endpoint to acknowledge received DATA		This chunk is sent to the peer endpoint to acknowledge received DATA
	chunks and to inform the peer endpoint of gaps in the received		chunks and to inform the peer endpoint of gaps in the received
	subsequences of DATA chunks as represented by their TSNs.		subsequences of DATA chunks as represented by their TSNs.
	The SACK chunk MUST contain the Cumulative TSN Ack, Advertised		The SACK chunk MUST contain the Cumulative TSN Ack, Advertised
	skipping to change at page 42, line 19 ¶		skipping to change at line 1890 ¶
	These fields contain the Gap Ack Blocks. They are repeated for		These fields contain the Gap Ack Blocks. They are repeated for
	each Gap Ack Block up to the number of Gap Ack Blocks defined in		each Gap Ack Block up to the number of Gap Ack Blocks defined in
	the Number of Gap Ack Blocks field. All DATA chunks with TSNs		the Number of Gap Ack Blocks field. All DATA chunks with TSNs
	greater than or equal to (Cumulative TSN Ack + Gap Ack Block		greater than or equal to (Cumulative TSN Ack + Gap Ack Block
	Start) and less than or equal to (Cumulative TSN Ack + Gap Ack		Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
	Block End) of each Gap Ack Block are assumed to have been received		Block End) of each Gap Ack Block are assumed to have been received
	correctly.		correctly.
	Gap Ack Block Start: 16 bits (unsigned integer)		Gap Ack Block Start: 16 bits (unsigned integer)
	Indicates the Start offset TSN for this Gap Ack Block. To		Indicates the Start offset TSN for this Gap Ack Block. To
	calculate the actual TSN number the Cumulative TSN Ack is added to		calculate the actual TSN number, the Cumulative TSN Ack is added
	this offset number. This calculated TSN identifies the lowest TSN		to this offset number. This calculated TSN identifies the lowest
	in this Gap Ack Block that has been received.		TSN in this Gap Ack Block that has been received.
	Gap Ack Block End: 16 bits (unsigned integer)		Gap Ack Block End: 16 bits (unsigned integer)
	Indicates the End offset TSN for this Gap Ack Block. To calculate		Indicates the End offset TSN for this Gap Ack Block. To calculate
	the actual TSN number, the Cumulative TSN Ack is added to this		the actual TSN number, the Cumulative TSN Ack is added to this
	offset number. This calculated TSN identifies the highest TSN in		offset number. This calculated TSN identifies the highest TSN in
	this Gap Ack Block that has been received.		this Gap Ack Block that has been received.
	For example, assume that the receiver has the following DATA		For example, assume that the receiver has the following DATA
	chunks newly arrived at the time when it decides to send a		chunks newly arrived at the time when it decides to send a
	Selective ACK,		Selective ACK:
	------------		------------
	| TSN = 17 |		| TSN = 17 |
	------------		------------
	| | <- still missing		| | <- still missing
	------------		------------
	| TSN = 15 |		| TSN = 15 |
	------------		------------
	| TSN = 14 |		| TSN = 14 |
	------------		------------
	| | <- still missing		| | <- still missing
	------------		------------
	| TSN = 12 |		| TSN = 12 |
	------------		------------
	| TSN = 11 |		| TSN = 11 |
	------------		------------
	| TSN = 10 |		| TSN = 10 |
	------------		------------
	then the parameter part of the SACK chunk MUST be constructed as		Then, the parameter part of the SACK chunk MUST be constructed as
	follows (assuming the new a_rwnd is set to 4660 by the sender):		follows (assuming the new a_rwnd is set to 4660 by the sender):
	+-------------------+-------------------+		+-------------------+-------------------+
	| Cumulative TSN Ack = 12 |		| Cumulative TSN Ack = 12 |
	+-------------------+-------------------+		+-------------------+-------------------+
	| a_rwnd = 4660 |		| a_rwnd = 4660 |
	+-------------------+-------------------+		+-------------------+-------------------+
	| num of block = 2 | num of dup = 0 |		| num of block = 2 | num of dup = 0 |
	+-------------------+-------------------+		+-------------------+-------------------+
	|block #1 start = 2 | block #1 end = 3 |		|block #1 start = 2 | block #1 end = 3 |
	skipping to change at page 43, line 27 ¶		skipping to change at line 1944 ¶
	|block #2 start = 5 | block #2 end = 5 |		|block #2 start = 5 | block #2 end = 5 |
	+-------------------+-------------------+		+-------------------+-------------------+
	Duplicate TSN: 32 bits (unsigned integer)		Duplicate TSN: 32 bits (unsigned integer)
	Indicates the number of times a TSN was received in duplicate		Indicates the number of times a TSN was received in duplicate
	since the last SACK chunk was sent. Every time a receiver gets a		since the last SACK chunk was sent. Every time a receiver gets a
	duplicate TSN (before sending the SACK chunk), it adds it to the		duplicate TSN (before sending the SACK chunk), it adds it to the
	list of duplicates. The duplicate count is reinitialized to zero		list of duplicates. The duplicate count is reinitialized to zero
	after sending each SACK chunk.		after sending each SACK chunk.
	For example, if a receiver were to get the TSN 19 three times it		For example, if a receiver were to get the TSN 19 three times, it
	would list 19 twice in the outbound SACK chunk. After sending the		would list 19 twice in the outbound SACK chunk. After sending the
	SACK chunk, if it received yet one more TSN 19 it would list 19 as		SACK chunk, if it received yet one more TSN 19, it would list 19
	a duplicate once in the next outgoing SACK chunk.		as a duplicate once in the next outgoing SACK chunk.
	3.3.5. Heartbeat Request (HEARTBEAT) (4)		3.3.5. Heartbeat Request (HEARTBEAT) (4)
	An endpoint SHOULD send a HEARTBEAT (HB) chunk to its peer endpoint		An endpoint SHOULD send a HEARTBEAT (HB) chunk to its peer endpoint
	to probe the reachability of a particular destination transport		to probe the reachability of a particular destination transport
	address defined in the present association.		address defined in the present association.
	The parameter field contains the Heartbeat Information, which is a		The parameter field contains the Heartbeat Information, which is a
	variable-length opaque data structure understood only by the sender.		variable-length opaque data structure understood only by the sender.
	skipping to change at page 44, line 11 ¶		skipping to change at line 1977 ¶
	Chunk Flags: 8 bits		Chunk Flags: 8 bits
	Set to 0 on transmit and ignored on receipt.		Set to 0 on transmit and ignored on receipt.
	Heartbeat Length: 16 bits (unsigned integer)		Heartbeat Length: 16 bits (unsigned integer)
	Set to the size of the chunk in bytes, including the chunk header		Set to the size of the chunk in bytes, including the chunk header
	and the Heartbeat Information field.		and the Heartbeat Information field.
	Heartbeat Information: variable length		Heartbeat Information: variable length
	Defined as a variable-length parameter using the format described		Defined as a variable-length parameter using the format described
	in Section 3.2.1, i.e.:		in Section 3.2.1, that is:
	+---------------------+-----------+------------+		+=====================+===========+============+
	| Variable Parameters | Status | Type Value |		| Variable Parameters | Status | Type Value |
	+---------------------+-----------+------------+		+=====================+===========+============+
	| Heartbeat Info | Mandatory | 1 |		| Heartbeat Info | Mandatory | 1 |
	+---------------------+-----------+------------+		+---------------------+-----------+------------+
	Table 9: Variable Length Parameters of		Table 9: Variable-Length Parameters of
	HEARTBEAT Chunks		HEARTBEAT Chunks
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Heartbeat Info Type = 1 | HB Info Length |		| Heartbeat Info Type = 1 | HB Info Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Sender-Specific Heartbeat Info /		/ Sender-Specific Heartbeat Info /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Sender-Specific Heartbeat Info field SHOULD include		The Sender-Specific Heartbeat Info field SHOULD include
	information about the sender's current time when this HEARTBEAT		information about the sender's current time when this HEARTBEAT
	chunk is sent and the destination transport address to which this		chunk is sent and the destination transport address to which this
	HEARTBEAT chunk is sent (see Section 8.3). This information is		HEARTBEAT chunk is sent (see Section 8.3). This information is
	simply reflected back by the receiver in the HEARTBEAT ACK chunk		simply reflected back by the receiver in the HEARTBEAT ACK chunk
	(see Section 3.3.6). Note also that the HEARTBEAT chunk is both		(see Section 3.3.6). Note also that the HEARTBEAT chunk is both
	for reachability checking and for path verification (see		for reachability checking and for path verification (see
	Section 5.4). When a HEARTBEAT chunk is being used for path		Section 5.4). When a HEARTBEAT chunk is being used for path
	verification purposes, it MUST include a random nonce of length		verification purposes, it MUST include a random nonce of length 64
	64-bit or longer ([RFC4086] provides some information on		bits or longer ([RFC4086] provides some information on randomness
	randomness guidelines).		guidelines).
	3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5)		3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5)
	An endpoint MUST send this chunk to its peer endpoint as a response		An endpoint MUST send this chunk to its peer endpoint as a response
	to a HEARTBEAT chunk (see Section 8.3). A packet containing the		to a HEARTBEAT chunk (see Section 8.3). A packet containing the
	HEARTBEAT ACK chunk is always sent to the source IP address of the IP		HEARTBEAT ACK chunk is always sent to the source IP address of the IP
	datagram containing the HEARTBEAT chunk to which this HEARTBEAT ACK		datagram containing the HEARTBEAT chunk to which this HEARTBEAT ACK
	chunk is responding.		chunk is responding.
	The parameter field contains a variable-length opaque data structure.		The parameter field contains a variable-length opaque data structure.
	skipping to change at page 45, line 27 ¶		skipping to change at line 2041 ¶
	Heartbeat Ack Length: 16 bits (unsigned integer)		Heartbeat Ack Length: 16 bits (unsigned integer)
	Set to the size of the chunk in bytes, including the chunk header		Set to the size of the chunk in bytes, including the chunk header
	and the Heartbeat Information field.		and the Heartbeat Information field.
	Heartbeat Information: variable length		Heartbeat Information: variable length
	This field MUST contain the Heartbeat Info parameter (as defined		This field MUST contain the Heartbeat Info parameter (as defined
	in Section 3.3.5) of the Heartbeat Request to which this Heartbeat		in Section 3.3.5) of the Heartbeat Request to which this Heartbeat
	Acknowledgement is responding.		Acknowledgement is responding.
	+---------------------+-----------+------------+		+=====================+===========+============+
	| Variable Parameters | Status | Type Value |		| Variable Parameters | Status | Type Value |
	+---------------------+-----------+------------+		+=====================+===========+============+
	| Heartbeat Info | Mandatory | 1 |		| Heartbeat Info | Mandatory | 1 |
	+---------------------+-----------+------------+		+---------------------+-----------+------------+
	Table 10: Variable Length Parameters of		Table 10: Variable-Length Parameters of
	HEARTBEAT ACK Chunks		HEARTBEAT ACK Chunks
	3.3.7. Abort Association (ABORT) (6)		3.3.7. Abort Association (ABORT) (6)
	The ABORT chunk is sent to the peer of an association to close the		The ABORT chunk is sent to the peer of an association to close the
	association. The ABORT chunk MAY contain Cause Parameters to inform		association. The ABORT chunk MAY contain error causes to inform the
	the receiver about the reason of the abort. DATA chunks MUST NOT be		receiver about the reason of the abort. DATA chunks MUST NOT be
	bundled with ABORT chunks. Control chunks (except for INIT, INIT		bundled with ABORT chunks. Control chunks (except for INIT, INIT
	ACK, and SHUTDOWN COMPLETE) MAY be bundled with an ABORT chunk, but		ACK, and SHUTDOWN COMPLETE) MAY be bundled with an ABORT chunk, but
	they MUST be placed before the ABORT chunk in the SCTP packet,		they MUST be placed before the ABORT chunk in the SCTP packet;
	otherwise they will be ignored by the receiver.		otherwise, they will be ignored by the receiver.
	If an endpoint receives an ABORT chunk with a format error or no TCB		If an endpoint receives an ABORT chunk with a format error or no TCB
	is found, it MUST silently discard it. Moreover, under any		is found, it MUST silently discard it. Moreover, under any
	circumstances, an endpoint that receives an ABORT chunk MUST NOT		circumstances, an endpoint that receives an ABORT chunk MUST NOT
	respond to that ABORT chunk by sending an ABORT chunk of its own.		respond to that ABORT chunk by sending an ABORT chunk of its own.
	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 = 6 | Reserved |T| Length |		| Type = 6 | Reserved |T| Length |
	skipping to change at page 49, line 5 ¶		skipping to change at line 2188 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cause Code | Cause Length |		| Cause Code | Cause Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Cause-Specific Information /		/ Cause-Specific Information /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Cause Code: 16 bits (unsigned integer)		Cause Code: 16 bits (unsigned integer)
	Defines the type of error conditions being reported.		Defines the type of error conditions being reported.
	+-------+----------------------------------------------+		+=======+==============================================+
	| Value | Cause Code |		| Value | Cause Code |
	+-------+----------------------------------------------+		+=======+==============================================+
	| 1 | Invalid Stream Identifier |		| 1 | Invalid Stream Identifier |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 2 | Missing Mandatory Parameter |		| 2 | Missing Mandatory Parameter |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 3 | Stale Cookie Error |		| 3 | Stale Cookie |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 4 | Out of Resource |		| 4 | Out of Resource |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 5 | Unresolvable Address |		| 5 | Unresolvable Address |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 6 | Unrecognized Chunk Type |		| 6 | Unrecognized Chunk Type |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 7 | Invalid Mandatory Parameter |		| 7 | Invalid Mandatory Parameter |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 8 | Unrecognized Parameters |		| 8 | Unrecognized Parameters |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 9 | No User Data |		| 9 | No User Data |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 10 | Cookie Received While Shutting Down |		| 10 | Cookie Received While Shutting Down |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 11 | Restart of an Association with New Addresses |		| 11 | Restart of an Association with New Addresses |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 12 | User Initiated Abort |		| 12 | User-Initiated Abort |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	| 13 | Protocol Violation |		| 13 | Protocol Violation |
	+-------+----------------------------------------------+		+-------+----------------------------------------------+
	Table 11: Cause Code		Table 11: Cause Code
	Cause Length: 16 bits (unsigned integer)		Cause Length: 16 bits (unsigned integer)
	Set to the size of the parameter in bytes, including the Cause		Set to the size of the parameter in bytes, including the Cause
	Code, Cause Length, and Cause-Specific Information fields.		Code, Cause Length, and Cause-Specific Information fields.
	Cause-Specific Information: variable length		Cause-Specific Information: variable length
	This field carries the details of the error condition.		This field carries the details of the error condition.
	Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP.		Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP.
	Guidelines for the IETF to define new error cause values are		Guidelines for the IETF to define new error cause values are
	discussed in Section 15.4.		discussed in Section 15.4.
	3.3.10.1. Invalid Stream Identifier (1)		3.3.10.1. Invalid Stream Identifier (1)
	Indicates that the endpoint received a DATA chunk sent using a		Indicates that the endpoint received a DATA chunk sent using a
	nonexistent stream.		nonexistent stream.
	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 50, line 45 ¶		skipping to change at line 2276 ¶
	| Missing Param Type #N-1 | Missing Param Type #N |		| Missing Param Type #N-1 | Missing Param Type #N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Number of Missing params: 32 bits (unsigned integer)		Number of Missing params: 32 bits (unsigned integer)
	This field contains the number of parameters contained in the		This field contains the number of parameters contained in the
	Cause-Specific Information field.		Cause-Specific Information field.
	Missing Param Type: 16 bits (unsigned integer)		Missing Param Type: 16 bits (unsigned integer)
	Each field will contain the missing mandatory parameter number.		Each field will contain the missing mandatory parameter number.
	3.3.10.3. Stale Cookie Error (3)		3.3.10.3. Stale Cookie (3)
	Indicates the receipt of a valid State Cookie that has expired.		Indicates the receipt of a valid State Cookie that has expired.
	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 = 3 | Cause Length = 8 |		| Cause Code = 3 | Cause Length = 8 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Measure of Staleness (usec.) |		| Measure of Staleness (usec.) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 53, line 37 ¶		skipping to change at line 2400 ¶
	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 = 9 | Cause Length = 8 |		| Cause Code = 9 | Cause Length = 8 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TSN |		| TSN |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TSN: 32 bits (unsigned integer)		TSN: 32 bits (unsigned integer)
	This parameter contains the TSN of the DATA chunk received with no		This parameter contains the TSN of the DATA chunk received with no
	user data field.		User Data field.
	This cause code is normally returned in an ABORT chunk (see		This cause code is normally returned in an ABORT chunk (see
	Section 6.2).		Section 6.2).
	3.3.10.10. Cookie Received While Shutting Down (10)		3.3.10.10. Cookie Received While Shutting Down (10)
	A COOKIE ECHO chunk was received while the endpoint was in the		A COOKIE ECHO chunk was received while the endpoint was in the
	SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR		SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR
	chunk bundled with the retransmitted SHUTDOWN ACK chunk.		chunk bundled with the retransmitted SHUTDOWN ACK chunk.
	skipping to change at page 54, line 46 ¶		skipping to change at line 2458 ¶
	| Cause Code = 12 | Cause Length |		| Cause Code = 12 | Cause Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Upper Layer Abort Reason /		/ Upper Layer Abort Reason /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.3.10.13. Protocol Violation (13)		3.3.10.13. Protocol Violation (13)
	This error cause MAY be included in ABORT chunks that are sent		This error cause MAY be included in ABORT chunks that are sent
	because an SCTP endpoint detects a protocol violation of the peer		because an SCTP endpoint detects a protocol violation of the peer
	that is not covered by the error causes described in Section 3.3.10.1		that is not covered by the error causes described in Sections
	to Section 3.3.10.12. An implementation MAY provide additional		3.3.10.1 - 3.3.10.12. An implementation MAY provide additional
	information specifying what kind of protocol violation has been		information specifying what kind of protocol violation has been
	detected.		detected.
	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 = 13 | Cause Length |		| Cause Code = 13 | Cause Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Additional Information /		/ Additional Information /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.3.11. Cookie Echo (COOKIE ECHO) (10)		3.3.11. Cookie Echo (COOKIE ECHO) (10)
	This chunk is used only during the initialization of an association.		This chunk is used only during the initialization of an association.
	It is sent by the initiator of an association to its peer to complete		It is sent by the initiator of an association to its peer to complete
	the initialization process. This chunk MUST precede any DATA chunk		the initialization process. This chunk MUST precede any DATA chunk
	sent within the association, but MAY be bundled with one or more DATA		sent within the association but MAY be bundled with one or more DATA
	chunks in the same packet.		chunks in the same packet.
	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 = 10 | Chunk Flags | Length |		| Type = 10 | Chunk Flags | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ Cookie /		/ Cookie /
	\ \		\ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 56, line 9 ¶		skipping to change at line 2513 ¶
	Note: A Cookie Echo does not contain a State Cookie parameter;		Note: A Cookie Echo does not contain a State Cookie parameter;
	instead, the data within the State Cookie's Parameter Value		instead, the data within the State Cookie's Parameter Value
	becomes the data within the Cookie Echo's Chunk Value. This		becomes the data within the Cookie Echo's Chunk Value. This
	allows an implementation to change only the first 2 bytes of the		allows an implementation to change only the first 2 bytes of the
	State Cookie parameter to become a COOKIE ECHO chunk.		State Cookie parameter to become a COOKIE ECHO chunk.
	3.3.12. Cookie Acknowledgement (COOKIE ACK) (11)		3.3.12. Cookie Acknowledgement (COOKIE ACK) (11)
	This chunk is used only during the initialization of an association.		This chunk is used only during the initialization of an association.
	It is used to acknowledge the receipt of a COOKIE ECHO chunk. This		It is used to acknowledge the receipt of a COOKIE ECHO chunk. This
	chunk MUST precede any DATA or SACK chunk sent within the		chunk MUST precede any DATA or SACK chunk sent within the association
	association, but MAY be bundled with one or more DATA chunks or SACK		but MAY be bundled with one or more DATA chunks or SACK chunk's in
	chunk's in the same SCTP packet.		the same SCTP packet.
	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 = 11 | Chunk Flags | Length = 4 |		| Type = 11 | Chunk Flags | Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Chunk Flags: 8 bits		Chunk Flags: 8 bits
	Set to 0 on transmit and ignored on receipt.		Set to 0 on transmit and ignored on receipt.
	skipping to change at page 56, line 46 ¶		skipping to change at line 2550 ¶
	Chunk Flags: 8 bits		Chunk Flags: 8 bits
	Reserved: 7 bits		Reserved: 7 bits
	Set to 0 on transmit and ignored on receipt.		Set to 0 on transmit and ignored on receipt.
	T bit: 1 bit		T bit: 1 bit
	The T bit is set to 0 if the sender filled in the Verification		The T bit is set to 0 if the sender filled in the Verification
	Tag expected by the peer. If the Verification Tag is		Tag expected by the peer. If the Verification Tag is
	reflected, the T bit MUST be set to 1. Reflecting means that		reflected, the T bit MUST be set to 1. Reflecting means that
	the sent Verification Tag is the same as the received one.		the sent Verification Tag is the same as the received one.
	Note: Special rules apply to this chunk for verification, please see		Note: Special rules apply to this chunk for verification; please see
	Section 8.5.1 for details.		Section 8.5.1 for details.
	4. SCTP Association State Diagram		4. SCTP Association State Diagram
	During the life time of an SCTP association, the SCTP endpoint's		During the life time of an SCTP association, the SCTP endpoint's
	association progresses from one state to another in response to		association progresses from one state to another in response to
	various events. The events that might potentially advance an		various events. The events that might potentially advance an
	association's state include:		association's state include:
	* SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],		* SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], or
			[ABORT],
	* Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control		* reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., and control
	chunks, or		chunks, or
	* Some timeout events.		* some timeout events.
	The state diagram in the figures below illustrates state changes,		The state diagram in the figures below illustrates state changes,
	together with the causing events and resulting actions. Note that		together with the causing events and resulting actions. Note that
	some of the error conditions are not shown in the state diagram.		some of the error conditions are not shown in the state diagram.
	Full descriptions of all special cases are found in the text.		Full descriptions of all special cases are found in the text.
	Note: Chunk names are given in all capital letters, while parameter		Note: Chunk names are given in all capital letters, while parameter
	names have the first letter capitalized, e.g., COOKIE ECHO chunk type		names have the first letter capitalized, e.g., COOKIE ECHO chunk type
	vs. State Cookie parameter. If more than one event/message can occur		vs. State Cookie parameter. If more than one event/message can occur
	that causes a state transition, it is labeled (A), (B).		that causes a state transition, it is labeled (A) or (B).
	----- -------- (from any state)		----- -------- (from any state)
	/ \ /receive ABORT [ABORT]		/ \ /receive ABORT [ABORT]
	receive INIT | | |-------------- or ----------		receive INIT | | |-------------- or ----------
	---------------------| v v delete TCB send ABORT		---------------------| v v delete TCB send ABORT
	generate State Cookie \ +---------+ delete TCB		generate State Cookie \ +---------+ delete TCB
	send INIT ACK ---| CLOSED |		send INIT ACK ---| CLOSED |
	+---------+		+---------+
	/ \		/ \
	/ \ [ASSOCIATE]		/ \ [ASSOCIATE]
	skipping to change at page 59, line 35 ¶		skipping to change at line 2681 ¶
	The following applies:		The following applies:
	1) If the State Cookie in the received COOKIE ECHO chunk is invalid		1) If the State Cookie in the received COOKIE ECHO chunk is invalid
	(i.e., failed to pass the integrity check), the receiver MUST		(i.e., failed to pass the integrity check), the receiver MUST
	silently discard the packet. Or, if the received State Cookie is		silently discard the packet. Or, if the received State Cookie is
	expired (see Section 5.1.5), the receiver MUST send back an ERROR		expired (see Section 5.1.5), the receiver MUST send back an ERROR
	chunk. In either case, the receiver stays in the CLOSED state.		chunk. In either case, the receiver stays in the CLOSED state.
	2) If the T1-init timer expires, the endpoint MUST retransmit the		2) If the T1-init timer expires, the endpoint MUST retransmit the
	INIT chunk and restart the T1-init timer without changing state.		INIT chunk and restart the T1-init timer. The endpoint stays in
	This MUST be repeated up to 'Max.Init.Retransmits' times. After		the COOKIE-WAIT state. This MUST be repeated up to
	that, the endpoint MUST abort the initialization process and		'Max.Init.Retransmits' times. After that, the endpoint MUST
	report the error to the SCTP user.		abort the initialization process and report the error to the SCTP
			user.
	3) If the T1-cookie timer expires, the endpoint MUST retransmit		3) If the T1-cookie timer expires, the endpoint MUST retransmit
	COOKIE ECHO chunk and restart the T1-cookie timer without		COOKIE ECHO chunk and restart the T1-cookie timer. The endpoint
	changing state. This MUST be repeated up to		stays in the COOKIE-ECHOED state. This MUST be repeated up to
	'Max.Init.Retransmits' times. After that, the endpoint MUST		'Max.Init.Retransmits' times. After that, the endpoint MUST
	abort the initialization process and report the error to the SCTP		abort the initialization process and report the error to the SCTP
	user.		user.
	4) In the SHUTDOWN-SENT state, the endpoint MUST acknowledge any		4) In the SHUTDOWN-SENT state, the endpoint MUST acknowledge any
	received DATA chunks without delay.		received DATA chunks without delay.
	5) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any		5) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any
	new send requests from its SCTP user.		new send requests from its SCTP user.
	skipping to change at page 61, line 9 ¶		skipping to change at line 2747 ¶
	INIT chunk, "A" MUST provide its Verification Tag (Tag_A) in the		INIT chunk, "A" MUST provide its Verification Tag (Tag_A) in the
	Initiate Tag field. Tag_A SHOULD be a random number in the range		Initiate Tag field. Tag_A SHOULD be a random number in the range
	of 1 to 4294967295 (see Section 5.3.1 for Tag value selection).		of 1 to 4294967295 (see Section 5.3.1 for Tag value selection).
	After sending the INIT chunk, "A" starts the T1-init timer and		After sending the INIT chunk, "A" starts the T1-init timer and
	enters the COOKIE-WAIT state.		enters the COOKIE-WAIT state.
	B) "Z" responds immediately with an INIT ACK chunk. The destination		B) "Z" responds immediately with an INIT ACK chunk. The destination
	IP address of the INIT ACK chunk MUST be set to the source IP		IP address of the INIT ACK chunk MUST be set to the source IP
	address of the INIT chunk to which this INIT ACK chunk is		address of the INIT chunk to which this INIT ACK chunk is
	responding. In the response, besides filling in other		responding. In the response, besides filling in other
	parameters, "Z" MUST set the Verification Tag field to Tag_A, and		parameters, "Z" MUST set the Verification Tag field to Tag_A and
	also provide its own Verification Tag (Tag_Z) in the Initiate Tag		also provide its own Verification Tag (Tag_Z) in the Initiate Tag
	field.		field.
	Moreover, "Z" MUST generate and send along with the INIT ACK		Moreover, "Z" MUST generate and send along with the INIT ACK
	chunk a State Cookie. See Section 5.1.3 for State Cookie		chunk a State Cookie. See Section 5.1.3 for State Cookie
	generation.		generation.
	After sending an INIT ACK chunk with the State Cookie parameter,		After sending an INIT ACK chunk with the State Cookie parameter,
	"Z" MUST NOT allocate any resources or keep any states for the		"Z" MUST NOT allocate any resources or keep any states for the
	new association. Otherwise, "Z" will be vulnerable to resource		new association. Otherwise, "Z" will be vulnerable to resource
	attacks.		attacks.
	C) Upon reception of the INIT ACK chunk from "Z", "A" stops the		C) Upon reception of the INIT ACK chunk from "Z", "A" stops the
	T1-init timer and leaves the COOKIE-WAIT state. "A" then sends		T1-init timer and leaves the COOKIE-WAIT state. "A" then sends
	the State Cookie received in the INIT ACK chunk in a COOKIE ECHO		the State Cookie received in the INIT ACK chunk in a COOKIE ECHO
	chunk, starts the T1-cookie timer, and enters the COOKIE-ECHOED		chunk, starts the T1-cookie timer, and enters the COOKIE-ECHOED
	state.		state.
	The COOKIE ECHO chunk MAY be bundled with any pending outbound		The COOKIE ECHO chunk MAY be bundled with any pending outbound
	DATA chunks, but it MUST be the first chunk in the packet and		DATA chunks, but it MUST be the first chunk in the packet and,
	until the COOKIE ACK chunk is returned the sender MUST NOT send		until the COOKIE ACK chunk is returned, the sender MUST NOT send
	any other packets to the peer.		any other packets to the peer.
	D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" replies		D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" replies
	with a COOKIE ACK chunk after building a TCB and moving to the		with a COOKIE ACK chunk after building a TCB and moving to the
	ESTABLISHED state. A COOKIE ACK chunk MAY be bundled with any		ESTABLISHED state. A COOKIE ACK chunk MAY be bundled with any
	pending DATA chunks (and/or SACK chunks), but the COOKIE ACK		pending DATA chunks (and/or SACK chunks), but the COOKIE ACK
	chunk MUST be the first chunk in the packet.		chunk MUST be the first chunk in the packet.
	Implementation Note: An implementation can choose to send the		Implementation Note: An implementation can choose to send the
	Communication Up notification to the SCTP user upon reception of		COMMUNICATION UP notification to the SCTP user upon reception of
	a valid COOKIE ECHO chunk.		a valid COOKIE ECHO chunk.
	E) Upon reception of the COOKIE ACK chunk, endpoint "A" moves from		E) Upon reception of the COOKIE ACK chunk, endpoint "A" moves from
	the COOKIE-ECHOED state to the ESTABLISHED state, stopping the		the COOKIE-ECHOED state to the ESTABLISHED state, stopping the
	T1-cookie timer. It can also notify its ULP about the successful		T1-cookie timer. It can also notify its ULP about the successful
	establishment of the association with a Communication Up		establishment of the association with a COMMUNICATION UP
	notification (see Section 11).		notification (see Section 11).
	An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk.		An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk.
	They MUST be the only chunks present in the SCTP packets that carry		They MUST be the only chunks present in the SCTP packets that carry
	them.		them.
	An endpoint MUST send the INIT ACK chunk to the IP address from which		An endpoint MUST send the INIT ACK chunk to the IP address from which
	it received the INIT chunk.		it received the INIT chunk.
	T1-init timer and T1-cookie timer SHOULD follow the same rules given		The T1-init timer and T1-cookie timer SHOULD follow the same rules
	in Section 6.3. If the application provided multiple IP addresses of		given in Section 6.3. If the application provided multiple IP
	the peer, there SHOULD be a T1-init and T1-cookie timer for each		addresses of the peer, there SHOULD be a T1-init and T1-cookie timer
	address of the peer. Retransmissions of INIT chunks and COOKIE ECHO		for each address of the peer. Retransmissions of INIT chunks and
	chunks SHOULD use all addresses of the peer similar to		COOKIE ECHO chunks SHOULD use all addresses of the peer similar to
	retransmissions of DATA chunks.		retransmissions of DATA chunks.
	If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but		If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
	decides not to establish the new association due to missing mandatory		decides not to establish the new association due to missing mandatory
	parameters in the received INIT or INIT ACK chunk, invalid parameter		parameters in the received INIT or INIT ACK chunk, invalid parameter
	values, or lack of local resources, it SHOULD respond with an ABORT		values, or lack of local resources, it SHOULD respond with an ABORT
	chunk. It SHOULD also specify the cause of abort, such as the type		chunk. It SHOULD also specify the cause of abort, such as the type
	of the missing mandatory parameters, etc., by including the error		of the missing mandatory parameters, etc., by including an error
	cause parameters with the ABORT chunk. The Verification Tag field in		cause in the ABORT chunk. The Verification Tag field in the common
	the common header of the outbound SCTP packet containing the ABORT		header of the outbound SCTP packet containing the ABORT chunk MUST be
	chunk MUST be set to the Initiate Tag value of the received INIT or		set to the Initiate Tag value of the received INIT or INIT ACK chunk
	INIT ACK chunk this ABORT chunk is responding to.		this ABORT chunk is responding to.
	Note that a COOKIE ECHO chunk that does not pass the integrity check		Note that a COOKIE ECHO chunk that does not pass the integrity check
	is not considered an 'invalid mandatory parameter' and requires		is not considered an 'invalid mandatory parameter' and requires
	special handling; see Section 5.1.5.		special handling; see Section 5.1.5.
	After the reception of the first DATA chunk in an association the		After the reception of the first DATA chunk in an association, the
	endpoint MUST immediately respond with a SACK chunk to acknowledge		endpoint MUST immediately respond with a SACK chunk to acknowledge
	the DATA chunk. Subsequent acknowledgements SHOULD be done as		the DATA chunk. Subsequent acknowledgements SHOULD be done as
	described in Section 6.2.		described in Section 6.2.
	When the TCB is created, each endpoint MUST set its internal		When the TCB is created, each endpoint MUST set its internal
	Cumulative TSN Ack Point to the value of its transmitted Initial TSN		Cumulative TSN Ack Point to the value of its transmitted Initial TSN
	minus one.		minus one.
	Implementation Note: The IP addresses and SCTP port are generally		Implementation Note: The IP addresses and SCTP port are generally
	used as the key to find the TCB within an SCTP instance.		used as the key to find the TCB within an SCTP instance.
	5.1.1. Handle Stream Parameters		5.1.1. Handle Stream Parameters
	In the INIT and INIT ACK chunks, the sender of the chunk MUST		In the INIT and INIT ACK chunks, the sender of the chunk MUST
	indicate the number of outbound streams (OSs) it wishes to have in		indicate the number of outbound streams (OS) it wishes to have in the
	the association, as well as the maximum inbound streams (MISs) it		association, as well as the maximum inbound streams (MIS) it will
	will accept from the other endpoint.		accept from the other endpoint.
	After receiving the stream configuration information from the other		After receiving the stream configuration information from the other
	side, each endpoint MUST perform the following check: If the peer's		side, each endpoint MUST perform the following check: If the peer's
	MIS is less than the endpoint's OS, meaning that the peer is		MIS is less than the endpoint's OS, meaning that the peer is
	incapable of supporting all the outbound streams the endpoint wants		incapable of supporting all the outbound streams the endpoint wants
	to configure, the endpoint MUST use MIS outbound streams and MAY		to configure, the endpoint MUST use MIS outbound streams and MAY
	report any shortage to the upper layer. The upper layer can then		report any shortage to the upper layer. The upper layer can then
	choose to abort the association if the resource shortage is		choose to abort the association if the resource shortage is
	unacceptable.		unacceptable.
	skipping to change at page 63, line 22 ¶		skipping to change at line 2857 ¶
	5.1.2. Handle Address Parameters		5.1.2. Handle Address Parameters
	During the association initialization, an endpoint uses the following		During the association initialization, an endpoint uses the following
	rules to discover and collect the destination transport address(es)		rules to discover and collect the destination transport address(es)
	of its peer.		of its peer.
	A) If there are no address parameters present in the received INIT		A) If there are no address parameters present in the received INIT
	or INIT ACK chunk, the endpoint MUST take the source IP address		or INIT ACK chunk, the endpoint MUST take the source IP address
	from which the chunk arrives and record it, in combination with		from which the chunk arrives and record it, in combination with
	the SCTP source port number, as the only destination transport		the SCTP Source Port Number, as the only destination transport
	address for this peer.		address for this peer.
	B) If there is a Host Name Address parameter present in the received		B) If there is a Host Name Address parameter present in the received
	INIT or INIT ACK chunk, the endpoint MUST immediately send an		INIT or INIT ACK chunk, the endpoint MUST immediately send an
	ABORT chunk and MAY include an "Unresolvable Address" error cause		ABORT chunk and MAY include an "Unresolvable Address" error cause
	to its peer. The ABORT chunk SHOULD be sent to the source IP		to its peer. The ABORT chunk SHOULD be sent to the source IP
	address from which the last peer packet was received.		address from which the last peer packet was received.
	C) If there are only IPv4/IPv6 addresses present in the received		C) If there are only IPv4/IPv6 addresses present in the received
	INIT or INIT ACK chunk, the receiver MUST derive and record all		INIT or INIT ACK chunk, the receiver MUST derive and record all
	the transport addresses from the received chunk AND the source IP		the transport addresses from the received chunk AND the source IP
	address that sent the INIT or INIT ACK chunk. The transport		address that sent the INIT or INIT ACK chunk. The transport
	addresses are derived by the combination of SCTP source port		addresses are derived by the combination of SCTP Source Port
	(from the common header) and the IP Address parameter(s) carried		Number (from the common header) and the IP Address parameter(s)
	in the INIT or INIT ACK chunk and the source IP address of the IP		carried in the INIT or INIT ACK chunk and the source IP address
	datagram. The receiver SHOULD use only these transport addresses		of the IP datagram. The receiver SHOULD use only these transport
	as destination transport addresses when sending subsequent		addresses as destination transport addresses when sending
	packets to its peer.		subsequent packets to its peer.
	D) An INIT or INIT ACK chunk MUST be treated as belonging to an		D) An INIT or INIT ACK chunk MUST be treated as belonging to an
	already established association (or one in the process of being		already established association (or one in the process of being
	established) if the use of any of the valid address parameters		established) if the use of any of the valid address parameters
	contained within the chunk would identify an existing TCB.		contained within the chunk would identify an existing TCB.
	Implementation Note: In some cases (e.g., when the implementation		Implementation Note: In some cases (e.g., when the implementation
	does not control the source IP address that is used for		does not control the source IP address that is used for
	transmitting), an endpoint might need to include in its INIT or INIT		transmitting), an endpoint might need to include in its INIT or INIT
	ACK chunk all possible IP addresses from which packets to the peer		ACK chunk all possible IP addresses from which packets to the peer
	skipping to change at page 64, line 29 ¶		skipping to change at line 2912 ¶
	reinitiation by using a 'Supported Address Types' parameter in the		reinitiation by using a 'Supported Address Types' parameter in the
	new INIT chunk to indicate what types of address it prefers.		new INIT chunk to indicate what types of address it prefers.
	If an SCTP endpoint that only supports either IPv4 or IPv6 receives		If an SCTP endpoint that only supports either IPv4 or IPv6 receives
	IPv4 and IPv6 addresses in an INIT or INIT ACK chunk from its peer,		IPv4 and IPv6 addresses in an INIT or INIT ACK chunk from its peer,
	it MUST use all the addresses belonging to the supported address		it MUST use all the addresses belonging to the supported address
	family. The other addresses MAY be ignored. The endpoint SHOULD NOT		family. The other addresses MAY be ignored. The endpoint SHOULD NOT
	respond with any kind of error indication.		respond with any kind of error indication.
	If an SCTP endpoint lists in the 'Supported Address Types' parameter		If an SCTP endpoint lists in the 'Supported Address Types' parameter
	either IPv4 or IPv6, but uses the other family for sending the packet		either IPv4 or IPv6 but uses the other family for sending the packet
	containing the INIT chunk, or if it also lists addresses of the other		containing the INIT chunk, or if it also lists addresses of the other
	family in the INIT chunk, then the address family that is not listed		family in the INIT chunk, then the address family that is not listed
	in the 'Supported Address Types' parameter SHOULD also be considered		in the 'Supported Address Types' parameter SHOULD also be considered
	as supported by the receiver of the INIT chunk. The receiver of the		as supported by the receiver of the INIT chunk. The receiver of the
	INIT chunk SHOULD NOT respond with any kind of error indication.		INIT chunk SHOULD NOT respond with any kind of error indication.
	5.1.3. Generating State Cookie		5.1.3. Generating State Cookie
	When sending an INIT ACK chunk as a response to an INIT chunk, the		When sending an INIT ACK chunk as a response to an INIT chunk, the
	sender of INIT ACK chunk creates a State Cookie and sends it in the		sender of the INIT ACK chunk creates a State Cookie and sends it in
	State Cookie parameter of the INIT ACK chunk. Inside this State		the State Cookie parameter of the INIT ACK chunk. Inside this State
	Cookie, the sender MUST include a MAC (see [RFC2104] for an example)		Cookie, the sender MUST include a MAC (see [RFC2104] for an example)
	to provide integrity protection on the State Cookie. The State		to provide integrity protection on the State Cookie. The State
	Cookie SHOULD also contain a timestamp on when the State Cookie is		Cookie SHOULD also contain a timestamp on when the State Cookie is
	created, and the lifespan of the State Cookie, along with all the		created and the lifespan of the State Cookie, along with all the
	information necessary for it to establish the association including		information necessary for it to establish the association, including
	the port numbers and the verification tags.		the port numbers and the Verification Tags.
	The method used to generate the MAC is strictly a private matter for		The method used to generate the MAC is strictly a private matter for
	the receiver of the INIT chunk. The use of a MAC is mandatory to		the receiver of the INIT chunk. The use of a MAC is mandatory to
	prevent denial-of-service attacks. MAC algorithms can have different		prevent denial-of-service attacks. MAC algorithms can have different
	performance depending on the platform. Choosing a high performance		performances depending on the platform. Choosing a high-performance
	MAC algorithm increases the resistance against cookie flooding		MAC algorithm increases the resistance against cookie flooding
	attacks. A MAC with acceptable security properties SHOULD be used.		attacks. A MAC with acceptable security properties SHOULD be used.
	The secret key SHOULD be random ([RFC4086] provides some information		The secret key SHOULD be random ([RFC4086] provides some information
	on randomness guidelines). The secret keys need to have an		on randomness guidelines). The secret keys need to have an
	appropriate size. The secret key SHOULD be changed reasonably		appropriate size. The secret key SHOULD be changed reasonably
	frequently (e.g., hourly), and the timestamp in the State Cookie MAY		frequently (e.g., hourly), and the timestamp in the State Cookie MAY
	be used to determine which key is used to verify the MAC.		be used to determine which key is used to verify the MAC.
	If the State Cookie is not encrypted, it MUST NOT contain information		If the State Cookie is not encrypted, it MUST NOT contain information
	which is not being envisioned to be shared.		that is not being envisioned to be shared.
	An implementation SHOULD make the cookie as small as possible to		An implementation SHOULD make the cookie as small as possible to
	ensure interoperability.		ensure interoperability.
	5.1.4. State Cookie Processing		5.1.4. State Cookie Processing
	When an endpoint (in the COOKIE-WAIT state) receives an INIT ACK		When an endpoint (in the COOKIE-WAIT state) receives an INIT ACK
	chunk with a State Cookie parameter, it MUST immediately send a		chunk with a State Cookie parameter, it MUST immediately send a
	COOKIE ECHO chunk to its peer with the received State Cookie. The		COOKIE ECHO chunk to its peer with the received State Cookie. The
	sender MAY also add any pending DATA chunks to the packet after the		sender MAY also add any pending DATA chunks to the packet after the
	COOKIE ECHO chunk.		COOKIE ECHO chunk.
	The endpoint MUST also start the T1-cookie timer after sending the		The endpoint MUST also start the T1-cookie timer after sending the
	COOKIE ECHO chunk. If the timer expires, the endpoint MUST		COOKIE ECHO chunk. If the timer expires, the endpoint MUST
	retransmit the COOKIE ECHO chunk and restart the T1-cookie timer.		retransmit the COOKIE ECHO chunk and restart the T1-cookie timer.
	This is repeated until either a COOKIE ACK chunk is received or		This is repeated until either a COOKIE ACK chunk is received or
	'Max.Init.Retransmits' (see Section 16) is reached causing the peer		'Max.Init.Retransmits' (see Section 16) is reached, causing the peer
	endpoint to be marked unreachable (and thus the association enters		endpoint to be marked unreachable (and thus the association enters
	the CLOSED state).		the CLOSED state).
	5.1.5. State Cookie Authentication		5.1.5. State Cookie Authentication
	When an endpoint receives a COOKIE ECHO chunk from another endpoint		When an endpoint receives a COOKIE ECHO chunk from another endpoint
	with which it has no association, it takes the following actions:		with which it has no association, it takes the following actions:
	1) Compute a MAC using the information carried in the State Cookie		1) Compute a MAC using the information carried in the State Cookie
	and the secret key. The timestamp in the State Cookie MAY be		and the secret key. The timestamp in the State Cookie MAY be
	used to determine which secret key to use. If secrets are kept		used to determine which secret key to use. If secrets are kept
	only for a limited amount of time and the secret key to use is		only for a limited amount of time and the secret key to use is
	not available anymore, the packet containing the COOKIE ECHO		not available anymore, the packet containing the COOKIE ECHO
	chunk MUST be silently discarded. [RFC2104] can be used as a		chunk MUST be silently discarded. [RFC2104] can be used as a
	guideline for generating the MAC,		guideline for generating the MAC.
	2) Authenticate the State Cookie as one that it previously generated		2) Authenticate the State Cookie as one that it previously generated
	by comparing the computed MAC against the one carried in the		by comparing the computed MAC against the one carried in the
	State Cookie. If this comparison fails, the SCTP packet,		State Cookie. If this comparison fails, the SCTP packet,
	including the COOKIE ECHO chunk and any DATA chunks, MUST be		including the COOKIE ECHO chunk and any DATA chunks, MUST be
	silently discarded,		silently discarded.
	3) Compare the port numbers and the Verification Tag contained		3) Compare the port numbers and the Verification Tag contained
	within the COOKIE ECHO chunk to the actual port numbers and the		within the COOKIE ECHO chunk to the actual port numbers and the
	Verification Tag within the SCTP common header of the received		Verification Tag within the SCTP common header of the received
	packet. If these values do not match, the packet MUST be		packet. If these values do not match, the packet MUST be
	silently discarded.		silently discarded.
	4) Compare the creation timestamp in the State Cookie to the current		4) Compare the creation timestamp in the State Cookie to the current
	local time. If the elapsed time is longer than the lifespan		local time. If the elapsed time is longer than the lifespan
	carried in the State Cookie, then the packet, including the		carried in the State Cookie, then the packet, including the
	skipping to change at page 66, line 41 ¶		skipping to change at line 3020 ¶
	COOKIE ACK chunk, the COOKIE ACK chunk MUST appear first in the		COOKIE ACK chunk, the COOKIE ACK chunk MUST appear first in the
	SCTP packet.		SCTP packet.
	If a COOKIE ECHO chunk is received from an endpoint with which the		If a COOKIE ECHO chunk is received from an endpoint with which the
	receiver of the COOKIE ECHO chunk has an existing association, the		receiver of the COOKIE ECHO chunk has an existing association, the
	procedures in Section 5.2 SHOULD be followed.		procedures in Section 5.2 SHOULD be followed.
	5.1.6. An Example of Normal Association Establishment		5.1.6. An Example of Normal Association Establishment
	In the following example, "A" initiates the association and then		In the following example, "A" initiates the association and then
	sends a user message to "Z", then "Z" sends two user messages to "A"		sends a user message to "Z"; then, "Z" sends two user messages to "A"
	later (assuming no bundling or fragmentation occurs):		later (assuming no bundling or fragmentation occurs):
	Endpoint A Endpoint Z		Endpoint A Endpoint Z
	{app sets association with Z}		{app sets association with Z}
	(build TCB)		(build TCB)
	INIT [I-Tag=Tag_A		INIT [I-Tag=Tag_A
	& other info] ------\		& other info] ------\
	(Start T1-init timer) \		(Start T1-init timer) \
	(Enter COOKIE-WAIT state) \---> (compose Cookie_Z)		(Enter COOKIE-WAIT state) \---> (compose Cookie_Z)
	/-- INIT ACK [Veri Tag=Tag_A,		/-- INIT ACK [Veri Tag=Tag_A,
	skipping to change at page 67, line 49 ¶		skipping to change at line 3067 ¶
	\/ Strm=0,Seq=1 & user data 2]		\/ Strm=0,Seq=1 & user data 2]
	<------/\		<------/\
	\		\
	\------>		\------>
	Figure 4: A Setup Example		Figure 4: A Setup Example
	If the T1-init timer expires at "A" after the INIT or COOKIE ECHO		If the T1-init timer expires at "A" after the INIT or COOKIE ECHO
	chunks are sent, the same INIT or COOKIE ECHO chunk with the same		chunks are sent, the same INIT or COOKIE ECHO chunk with the same
	Initiate Tag (i.e., Tag_A) or State Cookie is retransmitted and the		Initiate Tag (i.e., Tag_A) or State Cookie is retransmitted and the
	timer restarted. This is repeated 'Max.Init.Retransmits' times		timer is restarted. This is repeated 'Max.Init.Retransmits' times
	before "A" considers "Z" unreachable and reports the failure to its		before "A" considers "Z" unreachable and reports the failure to its
	upper layer (and thus the association enters the CLOSED state).		upper layer (and thus the association enters the CLOSED state).
	When retransmitting the INIT chunk, the endpoint MUST follow the		When retransmitting the INIT chunk, the endpoint MUST follow the
	rules defined in Section 6.3 to determine the proper timer value.		rules defined in Section 6.3 to determine the proper timer value.
	5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and		5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and
	COOKIE ACK Chunks		COOKIE ACK Chunks
	During the life time of an association (in one of the possible		During the life time of an association (in one of the possible
	states), an endpoint can receive from its peer endpoint one of the		states), an endpoint can receive from its peer endpoint one of the
	setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The		setup chunks (INIT, INIT ACK, COOKIE ECHO, or COOKIE ACK). The
	receiver treats such a setup chunk as a duplicate and process it as		receiver treats such a setup chunk as a duplicate and process it as
	described in this section.		described in this section.
	Note: An endpoint will not receive the chunk unless the chunk was		Note: An endpoint will not receive the chunk unless the chunk was
	sent to an SCTP transport address and is from an SCTP transport		sent to an SCTP transport address and is from an SCTP transport
	address associated with this endpoint. Therefore, the endpoint		address associated with this endpoint. Therefore, the endpoint
	processes such a chunk as part of its current association.		processes such a chunk as part of its current association.
	The following scenarios can cause duplicated or unexpected chunks:		The following scenarios can cause duplicated or unexpected chunks:
	A) The peer has crashed without being detected, restarted itself,		A) the peer has crashed without being detected, restarted itself,
	and sent a new INIT chunk trying to restore the association,		and sent a new INIT chunk trying to restore the association,
	B) Both sides are trying to initialize the association at about the		B) both sides are trying to initialize the association at about the
	same time,		same time,
	C) The chunk is from a stale packet that was used to establish the		C) the chunk is from a stale packet that was used to establish the
	present association or a past association that is no longer in		present association or a past association that is no longer in
	existence,		existence,
	D) The chunk is a false packet generated by an attacker, or		D) the chunk is a false packet generated by an attacker, or
	E) The peer never received the COOKIE ACK chunk and is		E) the peer never received the COOKIE ACK chunk and is
	retransmitting its COOKIE ECHO chunk.		retransmitting its COOKIE ECHO chunk.
	The rules in the following sections are applied in order to identify		The rules in the following sections are applied in order to identify
	and correctly handle these cases.		and correctly handle these cases.
	5.2.1. INIT Chunk Received in COOKIE-WAIT or COOKIE-ECHOED State (Item		5.2.1. INIT Chunk Received in COOKIE-WAIT or COOKIE-ECHOED State (Item
	B)		B)
	This usually indicates an initialization collision, i.e., each		This usually indicates an initialization collision, i.e., each
	endpoint is attempting, at about the same time, to establish an		endpoint is attempting, at about the same time, to establish an
	skipping to change at page 69, line 18 ¶		skipping to change at line 3133 ¶
	2) The packet containing the INIT ACK chunk MUST only be sent to an		2) The packet containing the INIT ACK chunk MUST only be sent to an
	address reported in the incoming INIT chunk.		address reported in the incoming INIT chunk.
	3) The packet containing the INIT ACK chunk SHOULD be sent to the		3) The packet containing the INIT ACK chunk SHOULD be sent to the
	source address of the received packet containing the INIT chunk.		source address of the received packet containing the INIT chunk.
	Upon receipt of an INIT chunk in the COOKIE-ECHOED state, an endpoint		Upon receipt of an INIT chunk in the COOKIE-ECHOED state, an endpoint
	MUST respond with an INIT ACK chunk using the same parameters it sent		MUST respond with an INIT ACK chunk using the same parameters it sent
	in its original INIT chunk (including its Initiate Tag, unchanged),		in its original INIT chunk (including its Initiate Tag, unchanged),
	provided that no NEW address has been added to the forming		provided that no new address has been added to the forming
	association. If the INIT chunk indicates that a new address has been		association. If the INIT chunk indicates that a new address has been
	added to the association, then the entire INIT chunk MUST be		added to the association, then the entire INIT chunk MUST be
	discarded, and the state of the existing association SHOULD NOT be		discarded, and the state of the existing association SHOULD NOT be
	changed. An ABORT chunk SHOULD be sent in response that MAY include		changed. An ABORT chunk SHOULD be sent in a response that MAY
	the error 'Restart of an association with new addresses'. The error		include the "Restart of an Association with New Addresses" error
	SHOULD list the addresses that were added to the restarting		cause. The error SHOULD list the addresses that were added to the
	association.		restarting association.
	When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with		When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
	an INIT ACK chunk, the original parameters are combined with those		an INIT ACK chunk, the original parameters are combined with those
	from the newly received INIT chunk. The endpoint MUST also generate		from the newly received INIT chunk. The endpoint MUST also generate
	a State Cookie with the INIT ACK chunk. The endpoint uses the		a State Cookie with the INIT ACK chunk. The endpoint uses the
	parameters sent in its INIT chunk to calculate the State Cookie.		parameters sent in its INIT chunk to calculate the State Cookie.
	After that, the endpoint MUST NOT change its state, the T1-init timer		After that, the endpoint MUST NOT change its state, the T1-init timer
	MUST be left running, and the corresponding TCB MUST NOT be		MUST be left running, and the corresponding TCB MUST NOT be
	destroyed. The normal procedures for handling State Cookies when a		destroyed. The normal procedures for handling State Cookies when a
	skipping to change at page 70, line 5 ¶		skipping to change at line 3169 ¶
	ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT		ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT
	Unless otherwise stated, upon receipt of an unexpected INIT chunk for		Unless otherwise stated, upon receipt of an unexpected INIT chunk for
	this association, the endpoint MUST generate an INIT ACK chunk with a		this association, the endpoint MUST generate an INIT ACK chunk with a
	State Cookie. Before responding, the endpoint MUST check to see if		State Cookie. Before responding, the endpoint MUST check to see if
	the unexpected INIT chunk adds new addresses to the association. If		the unexpected INIT chunk adds new addresses to the association. If
	new addresses are added to the association, the endpoint MUST respond		new addresses are added to the association, the endpoint MUST respond
	with an ABORT chunk, copying the 'Initiate Tag' of the unexpected		with an ABORT chunk, copying the 'Initiate Tag' of the unexpected
	INIT chunk into the 'Verification Tag' of the outbound packet		INIT chunk into the 'Verification Tag' of the outbound packet
	carrying the ABORT chunk. In the ABORT chunk, the error cause MAY be		carrying the ABORT chunk. In the ABORT chunk, the error cause MAY be
	set to 'restart of an association with new addresses'. The error		set to "Restart of an Association with New Addresses". The error
	SHOULD list the addresses that were added to the restarting		SHOULD list the addresses that were added to the restarting
	association. If no new addresses are added, when responding to the		association. If no new addresses are added, when responding to the
	INIT chunk in the outbound INIT ACK chunk, the endpoint MUST copy its		INIT chunk in the outbound INIT ACK chunk, the endpoint MUST copy its
	current Tie-Tags to a reserved place within the State Cookie and the		current Tie-Tags to a reserved place within the State Cookie and the
	association's TCB. We refer to these locations inside the cookie as		association's TCB. We refer to these locations inside the cookie as
	the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy		the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy
	within an association's TCB as the Local Tag and Peer's Tag. The		within an association's TCB as the Local Tag and Peer's Tag. The
	outbound SCTP packet containing this INIT ACK chunk MUST carry a		outbound SCTP packet containing this INIT ACK chunk MUST carry a
	Verification Tag value equal to the Initiate Tag found in the		Verification Tag value equal to the Initiate Tag found in the
	unexpected INIT chunk. And the INIT ACK chunk MUST contain a new		unexpected INIT chunk. And the INIT ACK chunk MUST contain a new
	Initiate Tag (randomly generated; see Section 5.3.1). Other		Initiate Tag (randomly generated; see Section 5.3.1). Other
	parameters for the endpoint SHOULD be copied from the existing		parameters for the endpoint SHOULD be copied from the existing
	parameters of the association (e.g., number of outbound streams) into		parameters of the association (e.g., number of outbound streams) into
	the INIT ACK chunk and cookie.		the INIT ACK chunk and cookie.
	After sending the INIT ACK or ABORT chunk, the endpoint MUST take no		After sending the INIT ACK or ABORT chunk, the endpoint MUST take no
	further actions; i.e., the existing association, including its		further actions, i.e., the existing association, including its
	current state, and the corresponding TCB MUST NOT be changed.		current state, and the corresponding TCB MUST NOT be changed.
	Only when a TCB exists and the association is not in a COOKIE-WAIT or		Only when a TCB exists and the association is not in a COOKIE-WAIT or
	SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a random		SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a random
	value other than 0. For a normal association INIT chunk (i.e., the		value other than 0. For a normal association INIT chunk (i.e., the
	endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0		endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0
	(indicating that no previous TCB existed).		(indicating that no previous TCB existed).
	5.2.3. Unexpected INIT ACK Chunk		5.2.3. Unexpected INIT ACK Chunk
	If an INIT ACK chunk is received by an endpoint in any state other		If an INIT ACK chunk is received by an endpoint in any state other
	than the COOKIE-WAIT or CLOSED state, the endpoint SHOULD discard the		than the COOKIE-WAIT or CLOSED state, the endpoint SHOULD discard the
	INIT ACK chunk. An unexpected INIT ACK chunk usually indicates the		INIT ACK chunk. An unexpected INIT ACK chunk usually indicates the
	processing of an old or duplicated INIT chunk.		processing of an old or duplicated INIT chunk.
	5.2.4. Handle a COOKIE ECHO Chunk when a TCB Exists		5.2.4. Handle a COOKIE ECHO Chunk When a TCB Exists
	When a COOKIE ECHO chunk is received by an endpoint in any state for		When a COOKIE ECHO chunk is received by an endpoint in any state for
	an existing association (i.e., not in the CLOSED state) the following		an existing association (i.e., not in the CLOSED state), the
	rules are applied:		following rules are applied:
	1) Compute a MAC as described in step 1 of Section 5.1.5,		1) Compute a MAC as described in step 1 of Section 5.1.5.
	2) Authenticate the State Cookie as described in step 2 of		2) Authenticate the State Cookie as described in step 2 of
	Section 5.1.5 (this is case C or D above).		Section 5.1.5 (this is case C or D above).
	3) Compare the timestamp in the State Cookie to the current time.		3) Compare the timestamp in the State Cookie to the current time.
	If the State Cookie is older than the lifespan carried in the		If the State Cookie is older than the lifespan carried in the
	State Cookie and the Verification Tags contained in the State		State Cookie and the Verification Tags contained in the State
	Cookie do not match the current association's Verification Tags,		Cookie do not match the current association's Verification Tags,
	the packet, including the COOKIE ECHO chunk and any DATA chunks,		the packet, including the COOKIE ECHO chunk and any DATA chunks,
	SHOULD be discarded. The endpoint also MUST transmit an ERROR		SHOULD be discarded. The endpoint also MUST transmit an ERROR
	chunk with a "Stale Cookie" error cause to the peer endpoint		chunk with a "Stale Cookie" error cause to the peer endpoint
	(this is case C or D in Section 5.2).		(this is case C or D in Section 5.2).
	If both Verification Tags in the State Cookie match the		If both Verification Tags in the State Cookie match the
	Verification Tags of the current association, consider the State		Verification Tags of the current association, consider the State
	Cookie valid (this is case E in Section 5.2) even if the lifespan		Cookie valid (this is case E in Section 5.2), even if the
	is exceeded.		lifespan is exceeded.
	4) If the State Cookie proves to be valid, unpack the TCB into a		4) If the State Cookie proves to be valid, unpack the TCB into a
	temporary TCB.		temporary TCB.
	5) Refer to Table 12 to determine the correct action to be taken.		5) Refer to Table 12 to determine the correct action to be taken.
	+-----------+------------+---------------+----------------+--------+		+===========+============+===============+================+========+
	| Local Tag | Peer's Tag | Local-Tie-Tag | Peer's-Tie-Tag | Action |		| Local Tag | Peer's Tag | Local-Tie-Tag | Peer's-Tie-Tag | Action |
	+-----------+------------+---------------+----------------+--------+		+===========+============+===============+================+========+
	| X | X | M | M | (A) |		| X | X | M | M | (A) |
	+-----------+------------+---------------+----------------+--------+		+-----------+------------+---------------+----------------+--------+
	| M | X | A | A | (B) |		| M | X | A | A | (B) |
	+-----------+------------+---------------+----------------+--------+		+-----------+------------+---------------+----------------+--------+
	| M | 0 | A | A | (B) |		| M | 0 | A | A | (B) |
	+-----------+------------+---------------+----------------+--------+		+-----------+------------+---------------+----------------+--------+
	| X | M | 0 | 0 | (C) |		| X | M | 0 | 0 | (C) |
	+-----------+------------+---------------+----------------+--------+		+-----------+------------+---------------+----------------+--------+
	| M | M | A | A | (D) |		| M | M | A | A | (D) |
	+-----------+------------+---------------+----------------+--------+		+-----------+------------+---------------+----------------+--------+
	Table 12: Handling of a COOKIE ECHO Chunk when a TCB Exists		Table 12: Handling of a COOKIE ECHO Chunk When a TCB Exists
	Legend:		Legend:
	X - Tag does not match the existing TCB.		X - Tag does not match the existing TCB.
	M - Tag matches the existing TCB.		M - Tag matches the existing TCB.
	0 - Tag unknown (Peer's Tag not known yet / No tie-tag in cookie).		0 - Tag unknown (Peer's Tag not known yet / No Tie-Tag in cookie).
	A - All cases, i.e., M, X, or 0.		A - All cases, i.e., M, X, or 0.
	For any case not shown in Table 12, the cookie SHOULD be silently		For any case not shown in Table 12, the cookie SHOULD be silently
	discarded.		discarded.
	Action		Action:
	A) In this case, the peer might have restarted. When the endpoint		A) In this case, the peer might have restarted. When the endpoint
	recognizes this potential 'restart', the existing session is		recognizes this potential 'restart', the existing session is
	treated the same as if it received an ABORT chunk followed by a		treated the same as if it received an ABORT chunk followed by a
	new COOKIE ECHO chunk with the following exceptions:		new COOKIE ECHO chunk with the following exceptions:
	* Any SCTP DATA chunks MAY be retained (this is an		* Any SCTP DATA chunks MAY be retained (this is an
	implementation-specific option).		implementation-specific option).
	* A notification of RESTART SHOULD be sent to the ULP instead of		* A RESTART notification SHOULD be sent to the ULP instead of a
	a "COMMUNICATION LOST" notification.		COMMUNICATION LOST notification.
	All the congestion control parameters (e.g., cwnd, ssthresh)		All the congestion control parameters (e.g., cwnd, ssthresh)
	related to this peer MUST be reset to their initial values (see		related to this peer MUST be reset to their initial values (see
	Section 6.2.1).		Section 6.2.1).
	After this, the endpoint enters the ESTABLISHED state.		After this, the endpoint enters the ESTABLISHED state.
	If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes		If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
	that the peer has restarted (Action A), it MUST NOT set up a new		that the peer has restarted (Action A), it MUST NOT set up a new
	association but instead resend the SHUTDOWN ACK chunk and send an		association but instead resend the SHUTDOWN ACK chunk and send an
	skipping to change at page 72, line 41 ¶		skipping to change at line 3301 ¶
	send a COOKIE ACK chunk.		send a COOKIE ACK chunk.
	C) In this case, the local endpoint's cookie has arrived late.		C) In this case, the local endpoint's cookie has arrived late.
	Before it arrived, the local endpoint sent an INIT chunk and		Before it arrived, the local endpoint sent an INIT chunk and
	received an INIT ACK chunk and finally sent a COOKIE ECHO chunk		received an INIT ACK chunk and finally sent a COOKIE ECHO chunk
	with the peer's same tag but a new tag of its own. The cookie		with the peer's same tag but a new tag of its own. The cookie
	SHOULD be silently discarded. The endpoint SHOULD NOT change		SHOULD be silently discarded. The endpoint SHOULD NOT change
	states and SHOULD leave any timers running.		states and SHOULD leave any timers running.
	D) When both local and remote tags match, the endpoint SHOULD enter		D) When both local and remote tags match, the endpoint SHOULD enter
	the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It		the ESTABLISHED state if it is in the COOKIE-ECHOED state. It
	SHOULD stop any T1-cookie timer that is running and send a COOKIE		SHOULD stop any T1-cookie timer that is running and send a COOKIE
	ACK chunk.		ACK chunk.
	Note: The "peer's Verification Tag" is the tag received in the		Note: The "peer's Verification Tag" is the tag received in the
	Initiate Tag field of the INIT or INIT ACK chunk.		Initiate Tag field of the INIT or INIT ACK chunk.
	5.2.4.1. An Example of a Association Restart		5.2.4.1. An Example of an Association Restart
	In the following example, "A" initiates the association after a		In the following example, "A" initiates the association after a
	restart has occurred. Endpoint "Z" had no knowledge of the restart		restart has occurred. Endpoint "Z" had no knowledge of the restart
	until the exchange (i.e., Heartbeats had not yet detected the failure		until the exchange (i.e., Heartbeats had not yet detected the failure
	of "A") (assuming no bundling or fragmentation occurs):		of "A") (assuming no bundling or fragmentation occurs):
	Endpoint A Endpoint Z		Endpoint A Endpoint Z
	<-------------- Association is established---------------------->		<-------------- Association is established---------------------->
	Tag=Tag_A Tag=Tag_Z		Tag=Tag_A Tag=Tag_Z
	<--------------------------------------------------------------->		<--------------------------------------------------------------->
	{A crashes and restarts}		{A crashes and restarts}
	{app sets up a association with Z}		{app sets up an association with Z}
	(build TCB)		(build TCB)
	INIT [I-Tag=Tag_A'		INIT [I-Tag=Tag_A'
	& other info] --------\		& other info] --------\
	(Start T1-init timer) \		(Start T1-init timer) \
	(Enter COOKIE-WAIT state) \---> (find an existing TCB,		(Enter COOKIE-WAIT state) \---> (find an existing TCB,
	populate TieTags if needed,		populate TieTags if needed,
	compose Cookie_Z with Tie-Tags		compose Cookie_Z with Tie-Tags
	and other info)		and other info)
	/--- INIT ACK [Veri Tag=Tag_A',		/--- INIT ACK [Veri Tag=Tag_A',
	/ I-Tag=Tag_Z',		/ I-Tag=Tag_Z',
	skipping to change at page 73, line 44 ¶		skipping to change at line 3347 ¶
	Tie-Tags in Cookie_Z match		Tie-Tags in Cookie_Z match
	Tie-Tags in TCB,		Tie-Tags in TCB,
	Tags do not match, i.e.,		Tags do not match, i.e.,
	case X X M M above,		case X X M M above,
	Announce Restart to ULP		Announce Restart to ULP
	and reset association).		and reset association).
	/---- COOKIE ACK		/---- COOKIE ACK
	(Cancel T1-init timer, <------/		(Cancel T1-init timer, <------/
	Enter ESTABLISHED state)		Enter ESTABLISHED state)
	{app sends 1st user data; strm 0}		{app sends 1st user data; strm 0}
	DATA [TSN=initial TSN_A		DATA [TSN=Initial TSN_A
	Strm=0,Seq=0 & user data]--\		Strm=0,Seq=0 & user data]--\
	(Start T3-rtx timer) \		(Start T3-rtx timer) \
	\->		\->
	/--- SACK [TSN Ack=init TSN_A,Block=0]		/--- SACK [TSN Ack=init TSN_A,Block=0]
	(Cancel T3-rtx timer) <------/		(Cancel T3-rtx timer) <------/
	Figure 5: A Restart Example		Figure 5: A Restart Example
	5.2.5. Handle Duplicate COOKIE ACK Chunk		5.2.5. Handle Duplicate COOKIE ACK Chunk
	At any state other than COOKIE-ECHOED, an endpoint SHOULD silently		At any state other than COOKIE-ECHOED, an endpoint SHOULD silently
	discard a received COOKIE ACK chunk.		discard a received COOKIE ACK chunk.
	5.2.6. Handle Stale Cookie Error		5.2.6. Handle Stale Cookie Error
	Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates		Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates
	one of a number of possible events:		one of a number of possible events:
	A) The association failed to completely setup before the State		A) The association failed to completely set up before the State
	Cookie issued by the sender was processed.		Cookie issued by the sender was processed.
	B) An old State Cookie was processed after setup completed.		B) An old State Cookie was processed after setup completed.
	C) An old State Cookie is received from someone that the receiver is		C) An old State Cookie is received from someone that the receiver is
	not interested in having an association with and the ABORT chunk		not interested in having an association with and the ABORT chunk
	was lost.		was lost.
	When processing an ERROR chunk with a "Stale Cookie" error cause an		When processing an ERROR chunk with a "Stale Cookie" error cause, an
	endpoint SHOULD first examine if an association is in the process of		endpoint SHOULD first examine if an association is in the process of
	being set up, i.e., the association is in the COOKIE-ECHOED state.		being set up, i.e., the association is in the COOKIE-ECHOED state.
	In all cases, if the association is not in the COOKIE-ECHOED state,		In all cases, if the association is not in the COOKIE-ECHOED state,
	the ERROR chunk SHOULD be silently discarded.		the ERROR chunk SHOULD be silently discarded.
	If the association is in the COOKIE-ECHOED state, the endpoint MAY		If the association is in the COOKIE-ECHOED state, the endpoint MAY
	elect one of the following three alternatives.		elect one of the following three alternatives.
	1) Send a new INIT chunk to the endpoint to generate a new State		1) Send a new INIT chunk to the endpoint to generate a new State
	Cookie and reattempt the setup procedure.		Cookie and reattempt the setup procedure.
	2) Discard the TCB and report to the upper layer the inability to		2) Discard the TCB and report to the upper layer the inability to
	set up the association.		set up the association.
	3) Send a new INIT chunk to the endpoint, adding a Cookie		3) Send a new INIT chunk to the endpoint, adding a Cookie
	Preservative parameter requesting an extension to the life time		Preservative parameter requesting an extension to the life time
	of the State Cookie. When calculating the time extension, an		of the State Cookie. When calculating the time extension, an
	implementation SHOULD use the RTT information measured based on		implementation SHOULD use the RTT information measured based on
	the previous COOKIE ECHO / ERROR chunk exchange, and SHOULD add		the previous COOKIE ECHO/ERROR chunk exchange and SHOULD add no
	no more than 1 second beyond the measured RTT, due to long State		more than 1 second beyond the measured RTT, due to long State
	Cookie life times making the endpoint more subject to a replay		Cookie life times making the endpoint more subject to a replay
	attack.		attack.
	5.3. Other Initialization Issues		5.3. Other Initialization Issues
	5.3.1. Selection of Tag Value		5.3.1. Selection of Tag Value
	Initiate Tag values SHOULD be selected from the range of 1 to 2^32 -		Initiate Tag values SHOULD be selected from the range of 1 to 2^32 -
	1. It is very important that the Initiate Tag value be randomized to		1. It is very important that the Initiate Tag value be randomized to
	help protect against "man in the middle" and "sequence number"		help protect against off-path attacks. The methods described in
	attacks. The methods described in [RFC4086] can be used for the		[RFC4086] can be used for the Initiate Tag randomization. Careful
	Initiate Tag randomization. Careful selection of Initiate Tags is		selection of Initiate Tags is also necessary to prevent old duplicate
	also necessary to prevent old duplicate packets from previous		packets from previous associations being mistakenly processed as
	associations being mistakenly processed as belonging to the current		belonging to the current association.
	association.
	Moreover, the Verification Tag value used by either endpoint in a		Moreover, the Verification Tag value used by either endpoint in a
	given association MUST NOT change during the life time of an		given association MUST NOT change during the life time of an
	association. A new Verification Tag value MUST be used each time the		association. A new Verification Tag value MUST be used each time the
	endpoint tears down and then reestablishes an association to the same		endpoint tears down and then reestablishes an association to the same
	peer.		peer.
	5.4. Path Verification		5.4. Path Verification
	During association establishment, the two peers exchange a list of		During association establishment, the two peers exchange a list of
	skipping to change at page 77, line 22 ¶		skipping to change at line 3512 ¶
	SHUTDOWN-RECEIVED states. An incoming SACK chunk MAY be processed in		SHUTDOWN-RECEIVED states. An incoming SACK chunk MAY be processed in
	COOKIE-ECHOED. A SACK chunk in the CLOSED state is out of the blue		COOKIE-ECHOED. A SACK chunk in the CLOSED state is out of the blue
	and SHOULD be processed according to the rules in Section 8.4. A		and SHOULD be processed according to the rules in Section 8.4. A
	SACK chunk received in any other state SHOULD be discarded.		SACK chunk received in any other state SHOULD be discarded.
	For transmission efficiency, SCTP defines mechanisms for bundling of		For transmission efficiency, SCTP defines mechanisms for bundling of
	small user messages and fragmentation of large user messages. The		small user messages and fragmentation of large user messages. The
	following diagram depicts the flow of user messages through SCTP.		following diagram depicts the flow of user messages through SCTP.
	In this section, the term "data sender" refers to the endpoint that		In this section, the term "data sender" refers to the endpoint that
	transmits a DATA chunk and the term "data receiver" refers to the		transmits a DATA chunk, and the term "data receiver" refers to the
	endpoint that receives a DATA chunk. A data receiver will transmit		endpoint that receives a DATA chunk. A data receiver will transmit
	SACK chunks.		SACK chunks.
	+-------------------------+		+-------------------------+
	| User Messages |		| User Messages |
	+-------------------------+		+-------------------------+
	SCTP user ^ |		SCTP user ^ |
	==================|==|=======================================		==================|==|=======================================
	| v (1)		| v (1)
	+------------------+ +---------------------+		+------------------+ +---------------------+
	skipping to change at page 78, line 18 ¶		skipping to change at line 3552 ¶
	Association Maximum DATA Chunk Size (AMDCS). The data receiver		Association Maximum DATA Chunk Size (AMDCS). The data receiver
	will normally reassemble the fragmented message from DATA chunks		will normally reassemble the fragmented message from DATA chunks
	before delivery to the user (see Section 6.9 for details).		before delivery to the user (see Section 6.9 for details).
	2) Multiple DATA and control chunks MAY be bundled by the sender		2) Multiple DATA and control chunks MAY be bundled by the sender
	into a single SCTP packet for transmission, as long as the final		into a single SCTP packet for transmission, as long as the final
	size of the SCTP packet does not exceed the current PMTU. The		size of the SCTP packet does not exceed the current PMTU. The
	receiver will unbundle the packet back into the original chunks.		receiver will unbundle the packet back into the original chunks.
	Control chunks MUST come before DATA chunks in the packet.		Control chunks MUST come before DATA chunks in the packet.
	The fragmentation and bundling mechanisms, as detailed in Section 6.9		The fragmentation and bundling mechanisms, as detailed in Sections
	and Section 6.10, are OPTIONAL to implement by the data sender, but		6.9 and 6.10, are OPTIONAL to implement by the data sender, but they
	they MUST be implemented by the data receiver, i.e., an endpoint MUST		MUST be implemented by the data receiver, i.e., an endpoint MUST
	properly receive and process bundled or fragmented data.		properly receive and process bundled or fragmented data.
	6.1. Transmission of DATA Chunks		6.1. Transmission of DATA Chunks
	This section specifies the rules for sending DATA chunks. In		This section specifies the rules for sending DATA chunks. In
	particular, it defines zero window probing, which is required to		particular, it defines zero window probing, which is required to
	avoid the indefinite stalling of an association in case of a loss of		avoid the indefinite stalling of an association in case of a loss of
	packets containing SACK chunks performing window updates.		packets containing SACK chunks performing window updates.
	This document is specified as if there is a single retransmission		This document is specified as if there is a single retransmission
	skipping to change at page 78, line 48 ¶		skipping to change at line 3582 ¶
	any destination transport address if its peer's rwnd indicates		any destination transport address if its peer's rwnd indicates
	that the peer has no buffer space (i.e., rwnd is smaller than the		that the peer has no buffer space (i.e., rwnd is smaller than the
	size of the next DATA chunk; see Section 6.2.1), except for zero		size of the next DATA chunk; see Section 6.2.1), except for zero
	window probes.		window probes.
	A zero window probe is a DATA chunk sent when the receiver has no		A zero window probe is a DATA chunk sent when the receiver has no
	buffer space. This rule allows the sender to probe for a change		buffer space. This rule allows the sender to probe for a change
	in rwnd that the sender missed due to the SACK chunks having been		in rwnd that the sender missed due to the SACK chunks having been
	lost in transit from the data receiver to the data sender. A		lost in transit from the data receiver to the data sender. A
	zero window probe MUST only be sent when the cwnd allows (see		zero window probe MUST only be sent when the cwnd allows (see
	Rule B below). A zero window probe SHOULD only be sent when all		rule B below). A zero window probe SHOULD only be sent when all
	outstanding DATA chunks have been cumulatively acknowledged and		outstanding DATA chunks have been cumulatively acknowledged and
	no DATA chunks are in flight. Senders MUST support zero window		no DATA chunks are in flight. Senders MUST support zero window
	probing.		probing.
	If the sender continues to receive SACK chunks from the peer		If the sender continues to receive SACK chunks from the peer
	while doing zero window probing, the unacknowledged window probes		while doing zero window probing, the unacknowledged window probes
	SHOULD NOT increment the error counter for the association or any		SHOULD NOT increment the error counter for the association or any
	destination transport address. This is because the receiver		destination transport address. This is because the receiver
	could keep its window closed for an indefinite time. Section 6.2		could keep its window closed for an indefinite time. Section 6.2
	describes the receiver behavior when it advertises a zero window.		describes the receiver behavior when it advertises a zero window.
	skipping to change at page 79, line 41 ¶		skipping to change at line 3623 ¶
	C) When the time comes for the sender to transmit, before sending		C) When the time comes for the sender to transmit, before sending
	new DATA chunks, the sender MUST first transmit any DATA chunks		new DATA chunks, the sender MUST first transmit any DATA chunks
	that are marked for retransmission (limited by the current cwnd).		that are marked for retransmission (limited by the current cwnd).
	D) When the time comes for the sender to transmit new DATA chunks,		D) When the time comes for the sender to transmit new DATA chunks,
	the protocol parameter 'Max.Burst' SHOULD be used to limit the		the protocol parameter 'Max.Burst' SHOULD be used to limit the
	number of packets sent. The limit MAY be applied by adjusting		number of packets sent. The limit MAY be applied by adjusting
	cwnd temporarily, as follows:		cwnd temporarily, as follows:
	if ((flightsize + Max.Burst * PMDCS) < cwnd)		if ((flightsize + Max.Burst * PMDCS) < cwnd)
	cwnd = flightsize + Max.Burst * PMDCS;		cwnd = flightsize + Max.Burst * PMDCS
	Or, it MAY be applied by strictly limiting the number of packets		Or, it MAY be applied by strictly limiting the number of packets
	emitted by the output routine. When calculating the number of		emitted by the output routine. When calculating the number of
	packets to transmit, and particularly when using the formula		packets to transmit, and particularly when using the formula
	above, cwnd SHOULD NOT be changed permanently.		above, cwnd SHOULD NOT be changed permanently.
	E) Then, the sender can send as many new DATA chunks as rule A and		E) Then, the sender can send as many new DATA chunks as rule A and
	rule B allow.		rule B allow.
	Multiple DATA chunks committed for transmission MAY be bundled in a		Multiple DATA chunks committed for transmission MAY be bundled in a
	skipping to change at page 80, line 22 ¶		skipping to change at line 3650 ¶
	congestion or retransmission).		congestion or retransmission).
	Before an endpoint transmits a DATA chunk, if any received DATA		Before an endpoint transmits a DATA chunk, if any received DATA
	chunks have not been acknowledged (e.g., due to delayed ack), the		chunks have not been acknowledged (e.g., due to delayed ack), the
	sender SHOULD create a SACK chunk and bundle it with the outbound		sender SHOULD create a SACK chunk and bundle it with the outbound
	DATA chunk, as long as the size of the final SCTP packet does not		DATA chunk, as long as the size of the final SCTP packet does not
	exceed the current PMTU. See Section 6.2.		exceed the current PMTU. See Section 6.2.
	When the window is full (i.e., transmission is disallowed by rule A		When the window is full (i.e., transmission is disallowed by rule A
	and/or rule B), the sender MAY still accept send requests from its		and/or rule B), the sender MAY still accept send requests from its
	upper layer, but MUST transmit no more DATA chunks until some or all		upper layer but MUST transmit no more DATA chunks until some or all
	of the outstanding DATA chunks are acknowledged and transmission is		of the outstanding DATA chunks are acknowledged and transmission is
	allowed by rule A and rule B again.		allowed by rule A and rule B again.
	Whenever a transmission or retransmission is made to any address, if		Whenever a transmission or retransmission is made to any address, if
	the T3-rtx timer of that address is not currently running, the sender		the T3-rtx timer of that address is not currently running, the sender
	MUST start that timer. If the timer for that address is already		MUST start that timer. If the timer for that address is already
	running, the sender MUST restart the timer if the earliest (i.e.,		running, the sender MUST restart the timer if the earliest (i.e.,
	lowest TSN) outstanding DATA chunk sent to that address is being		lowest TSN) outstanding DATA chunk sent to that address is being
	retransmitted. Otherwise, the data sender MUST NOT restart the		retransmitted. Otherwise, the data sender MUST NOT restart the
	timer.		timer.
	When starting or restarting the T3-rtx timer, the timer value SHOULD		When starting or restarting the T3-rtx timer, the timer value SHOULD
	be adjusted according to the timer rules defined in Section 6.3.2 and		be adjusted according to the timer rules defined in Sections 6.3.2
	Section 6.3.3.		and 6.3.3.
	The data sender MUST NOT use a TSN that is more than 2^31 - 1 above		The data sender MUST NOT use a TSN that is more than 2^31 - 1 above
	the beginning TSN of the current send window.		the beginning TSN of the current send window.
	For each stream, the data sender MUST NOT have more than 2^16 - 1		For each stream, the data sender MUST NOT have more than 2^16 - 1
	ordered user messages in the current send window.		ordered user messages in the current send window.
	Whenever the sender of a DATA chunk can benefit from the		Whenever the sender of a DATA chunk can benefit from the
	corresponding SACK chunk being sent back without delay, the sender		corresponding SACK chunk being sent back without delay, the sender
	MAY set the I bit in the DATA chunk header. Please note that why the		MAY set the I bit in the DATA chunk header. Please note that why the
	skipping to change at page 81, line 34 ¶		skipping to change at line 3710 ¶
	incoming DATA chunk. In either case, if such a DATA chunk is		incoming DATA chunk. In either case, if such a DATA chunk is
	dropped, the receiver MUST immediately send back a SACK chunk with		dropped, the receiver MUST immediately send back a SACK chunk with
	the current receive window showing only DATA chunks received and		the current receive window showing only DATA chunks received and
	accepted so far. The dropped DATA chunk(s) MUST NOT be included in		accepted so far. The dropped DATA chunk(s) MUST NOT be included in
	the SACK chunk, as they were not accepted. The receiver MUST also		the SACK chunk, as they were not accepted. The receiver MUST also
	have an algorithm for advertising its receive window to avoid		have an algorithm for advertising its receive window to avoid
	receiver silly window syndrome (SWS), as described in [RFC1122]. The		receiver silly window syndrome (SWS), as described in [RFC1122]. The
	algorithm can be similar to the one described in Section 4.2.3.3 of		algorithm can be similar to the one described in Section 4.2.3.3 of
	[RFC1122].		[RFC1122].
	The guidelines on delayed acknowledgement algorithm specified in		The guidelines on the delayed acknowledgement algorithm specified in
	Section 4.2 of [RFC5681] SHOULD be followed. Specifically, an		Section 4.2 of [RFC5681] SHOULD be followed. Specifically, an
	acknowledgement SHOULD be generated for at least every second packet		acknowledgement SHOULD be generated for at least every second packet
	(not every second DATA chunk) received, and SHOULD be generated		(not every second DATA chunk) received and SHOULD be generated within
	within 200 ms of the arrival of any unacknowledged DATA chunk. In		200 ms of the arrival of any unacknowledged DATA chunk. In some
	some situations, it might be beneficial for an SCTP transmitter to be		situations, it might be beneficial for an SCTP transmitter to be more
	more conservative than the algorithms detailed in this document		conservative than the algorithms detailed in this document allow.
	allow. However, an SCTP transmitter MUST NOT be more aggressive in		However, an SCTP transmitter MUST NOT be more aggressive in sending
	sending SACK chunks than the following algorithms allow.		SACK chunks than the following algorithms allow.
	An SCTP receiver MUST NOT generate more than one SACK chunk for every		An SCTP receiver MUST NOT generate more than one SACK chunk for every
	incoming packet, other than to update the offered window as the		incoming packet, other than to update the offered window as the
	receiving application consumes new data. When the window opens up,		receiving application consumes new data. When the window opens up,
	an SCTP receiver SHOULD send additional SACK chunks to update the		an SCTP receiver SHOULD send additional SACK chunks to update the
	window even if no new data is received. The receiver MUST avoid		window even if no new data is received. The receiver MUST avoid
	sending a large number of window updates -- in particular, large		sending a large number of window updates -- in particular, large
	bursts of them. One way to achieve this is to send a window update		bursts of them. One way to achieve this is to send a window update
	only if the window can be increased by at least a quarter of the		only if the window can be increased by at least a quarter of the
	receive buffer size of the association.		receive buffer size of the association.
	skipping to change at page 86, line 6 ¶		skipping to change at line 3923 ¶
	iii) If the SACK chunk is missing a TSN that was previously		iii) If the SACK chunk is missing a TSN that was previously
	acknowledged via a Gap Ack Block (e.g., the data receiver		acknowledged via a Gap Ack Block (e.g., the data receiver
	reneged on the data), then consider the corresponding DATA		reneged on the data), then consider the corresponding DATA
	that might be possibly missing: Count one miss indication		that might be possibly missing: Count one miss indication
	towards Fast Retransmit as described in Section 7.2.4, and		towards Fast Retransmit as described in Section 7.2.4, and
	if no retransmit timer is running for the destination		if no retransmit timer is running for the destination
	address to which the DATA chunk was originally transmitted,		address to which the DATA chunk was originally transmitted,
	then T3-rtx is started for that destination address.		then T3-rtx is started for that destination address.
	iv) If the Cumulative TSN Ack matches or exceeds the Fast		iv) If the Cumulative TSN Ack matches or exceeds the Fast
	Recovery exitpoint (Section 7.2.4), Fast Recovery is		Recovery exit point (Section 7.2.4), Fast Recovery is
	exited.		exited.
	6.3. Management of Retransmission Timer		6.3. Management of Retransmission Timer
	An SCTP endpoint uses a retransmission timer T3-rtx to ensure data		An SCTP endpoint uses a retransmission timer T3-rtx to ensure data
	delivery in the absence of any feedback from its peer. The duration		delivery in the absence of any feedback from its peer. The duration
	of this timer is referred to as RTO (retransmission timeout).		of this timer is referred to as RTO (retransmission timeout).
	When an endpoint's peer is multi-homed, the endpoint will calculate a		When an endpoint's peer is multi-homed, the endpoint will calculate a
	separate RTO for each different destination transport address of its		separate RTO for each different destination transport address of its
	skipping to change at page 86, line 34 ¶		skipping to change at line 3951 ¶
	6.3.1. RTO Calculation		6.3.1. RTO Calculation
	The rules governing the computation of SRTT, RTTVAR, and RTO are as		The rules governing the computation of SRTT, RTTVAR, and RTO are as
	follows:		follows:
	C1) Until an RTT measurement has been made for a packet sent to the		C1) Until an RTT measurement has been made for a packet sent to the
	given destination transport address, set RTO to the protocol		given destination transport address, set RTO to the protocol
	parameter 'RTO.Initial'.		parameter 'RTO.Initial'.
	C2) When the first RTT measurement R is made, perform		C2) When the first RTT measurement R is made, perform:
	SRTT = R;		SRTT = R
	RTTVAR = R/2;		RTTVAR = R/2
	RTO = SRTT + 4 * RTTVAR;		RTO = SRTT + 4 * RTTVAR
	C3) When a new RTT measurement R' is made, perform:		C3) When a new RTT measurement R' is made, perform:
	RTTVAR = (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|;		RTTVAR = (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
	SRTT = (1 - RTO.Alpha) * SRTT + RTO.Alpha * R';		SRTT = (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
	Note: The value of SRTT used in the update to RTTVAR is its		Note: The value of SRTT used in the update to RTTVAR is its
	value before updating SRTT itself using the second assignment.		value before updating SRTT itself using the second assignment.
	After the computation, update		After the computation, update:
	RTO = SRTT + 4 * RTTVAR;		RTO = SRTT + 4 * RTTVAR
	C4) When data is in flight and when allowed by rule C5 below, a new		C4) When data is in flight and when allowed by rule C5 below, a new
	RTT measurement MUST be made each round trip. Furthermore, new		RTT measurement MUST be made each round trip. Furthermore, new
	RTT measurements SHOULD be made no more than once per round trip		RTT measurements SHOULD be made no more than once per round trip
	for a given destination transport address. There are two		for a given destination transport address. There are two
	reasons for this recommendation: First, it appears that		reasons for this recommendation: First, it appears that
	measuring more frequently often does not in practice yield any		measuring more frequently often does not in practice yield any
	significant benefit [ALLMAN99]; second, if measurements are made		significant benefit [ALLMAN99]; second, if measurements are made
	more often, then the values of 'RTO.Alpha' and 'RTO.Beta' in		more often, then the values of 'RTO.Alpha' and 'RTO.Beta' in
	rule C3 above SHOULD be adjusted so that SRTT and RTTVAR still		rule C3 above SHOULD be adjusted so that SRTT and RTTVAR still
	adjust to changes at roughly the same rate (in terms of how many		adjust to changes at roughly the same rate (in terms of how many
	round trips it takes them to reflect new values) as they would		round trips it takes them to reflect new values) as they would
	if making only one measurement per round-trip and using		if making only one measurement per round trip and using
	'RTO.Alpha' and 'RTO.Beta' as given in rule C3. However, the		'RTO.Alpha' and 'RTO.Beta' as given in rule C3. However, the
	exact nature of these adjustments remains a research issue.		exact nature of these adjustments remains a research issue.
	C5) Karn's algorithm: RTT measurements MUST NOT be made using chunks		C5) Karn's algorithm: RTT measurements MUST NOT be made using chunks
	that were retransmitted (and thus for which it is ambiguous		that were retransmitted (and thus for which it is ambiguous
	whether the reply was for the first instance of the chunk or for		whether the reply was for the first instance of the chunk or for
	a later instance).		a later instance).
	RTT measurements SHOULD only be made using a DATA chunk with TSN		RTT measurements SHOULD only be made using a DATA chunk with TSN
	r, if no DATA chunk with TSN less than or equal to r was		r if no DATA chunk with TSN less than or equal to r was
	retransmitted since the DATA chunk with TSN r was sent first.		retransmitted since the DATA chunk with TSN r was sent first.
	C6) Whenever RTO is computed, if it is less than 'RTO.Min' seconds		C6) Whenever RTO is computed, if it is less than 'RTO.Min' seconds,
	then it is rounded up to 'RTO.Min' seconds. The reason for this		then it is rounded up to 'RTO.Min' seconds. The reason for this
	rule is that RTOs that do not have a high minimum value are		rule is that RTOs that do not have a high minimum value are
	susceptible to unnecessary timeouts [ALLMAN99].		susceptible to unnecessary timeouts [ALLMAN99].
	C7) A maximum value MAY be placed on RTO provided it is at least		C7) A maximum value MAY be placed on RTO, provided it is at least
	'RTO.max' seconds.		'RTO.Max' seconds.
	There is no requirement for the clock granularity G used for		There is no requirement for the clock granularity G used for
	computing RTT measurements and the different state variables, other		computing RTT measurements and the different state variables, other
	than:		than:
	G1) Whenever RTTVAR is computed, if RTTVAR == 0, then adjust RTTVAR		G1) Whenever RTTVAR is computed, if RTTVAR == 0, then adjust RTTVAR
	= G.		= G.
	Experience [ALLMAN99] has shown that finer clock granularities (less		Experience [ALLMAN99] has shown that finer clock granularities (less
	than 100 msec) perform somewhat better than more coarse		than 100 msec) perform somewhat better than more coarse
	skipping to change at page 89, line 11 ¶		skipping to change at line 4068 ¶
	(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]		(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
	Figure 8: Timer Rule Examples		Figure 8: Timer Rule Examples
	6.3.3. Handle T3-rtx Expiration		6.3.3. Handle T3-rtx Expiration
	Whenever the retransmission timer T3-rtx expires for a destination		Whenever the retransmission timer T3-rtx expires for a destination
	address, do the following:		address, do the following:
	E1) For the destination address for which the timer expires, adjust		E1) For the destination address for which the timer expires, adjust
	its ssthresh with rules defined in Section 7.2.3 and set the		its ssthresh with rules defined in Section 7.2.3 and set cwnd =
	cwnd = PMDCS.		PMDCS.
	E2) For the destination address for which the timer expires, set RTO		E2) For the destination address for which the timer expires, set RTO
	= RTO * 2 ("back off the timer"). The maximum value discussed		= RTO * 2 ("back off the timer"). The maximum value discussed
	in rule C7 above ('RTO.max') MAY be used to provide an upper		in rule C7 above ('RTO.Max') MAY be used to provide an upper
	bound to this doubling operation.		bound to this doubling operation.
	E3) Determine how many of the earliest (i.e., lowest TSN)		E3) Determine how many of the earliest (i.e., lowest TSN)
	outstanding DATA chunks for the address for which the T3-rtx has		outstanding DATA chunks for the address for which the T3-rtx has
	expired will fit into a single SCTP packet, subject to the PMTU		expired will fit into a single SCTP packet, subject to the PMTU
	corresponding to the destination transport address to which the		corresponding to the destination transport address to which the
	retransmission is being sent (this might be different from the		retransmission is being sent (this might be different from the
	address for which the timer expires; see Section 6.4). Call		address for which the timer expires; see Section 6.4). Call
	this value K. Bundle and retransmit those K DATA chunks in a		this value K. Bundle and retransmit those K DATA chunks in a
	single packet to the destination endpoint.		single packet to the destination endpoint.
	E4) Start the retransmission timer T3-rtx on the destination address		E4) Start the retransmission timer T3-rtx on the destination address
	to which the retransmission is sent, if rule R1 above indicates		to which the retransmission is sent if rule R1 above indicates
	to do so. The RTO to be used for starting T3-rtx SHOULD be the		to do so. The RTO to be used for starting T3-rtx SHOULD be the
	one for the destination address to which the retransmission is		one for the destination address to which the retransmission is
	sent, which, when the receiver is multi-homed, might be		sent, which, when the receiver is multi-homed, might be
	different from the destination address for which the timer		different from the destination address for which the timer
	expired (see Section 6.4 below).		expired (see Section 6.4 below).
	After retransmitting, once a new RTT measurement is obtained (which		After retransmitting, once a new RTT measurement is obtained (which
	can happen only when new data has been sent and acknowledged, per		can happen only when new data has been sent and acknowledged, per
	rule C5, or for a measurement made from a HEARTBEAT chunk; see		rule C5, or for a measurement made from a HEARTBEAT chunk; see
	Section 8.3), the computation in rule C3 is performed, including the		Section 8.3), the computation in rule C3 is performed, including the
	skipping to change at page 90, line 21 ¶		skipping to change at line 4125 ¶
	rule R1 indicates to do so.		rule R1 indicates to do so.
	6.4. Multi-Homed SCTP Endpoints		6.4. Multi-Homed SCTP Endpoints
	An SCTP endpoint is considered multi-homed if there is more than one		An SCTP endpoint is considered multi-homed if there is more than one
	transport address that can be used as a destination address to reach		transport address that can be used as a destination address to reach
	that endpoint.		that endpoint.
	Moreover, the ULP of an endpoint selects one of the multiple		Moreover, the ULP of an endpoint selects one of the multiple
	destination addresses of a multi-homed peer endpoint as the primary		destination addresses of a multi-homed peer endpoint as the primary
	path (see Section 5.1.2 and Section 11.1 for details).		path (see Sections 5.1.2 and 11.1 for details).
	By default, an endpoint SHOULD always transmit to the primary path,		By default, an endpoint SHOULD always transmit to the primary path,
	unless the SCTP user explicitly specifies the destination transport		unless the SCTP user explicitly specifies the destination transport
	address (and possibly source transport address) to use.		address (and possibly source transport address) to use.
	An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK,		An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK,
	HEARTBEAT ACK) in response to control chunks to the same destination		and HEARTBEAT ACK) in response to control chunks to the same
	transport address from which it received the control chunk to which		destination transport address from which it received the control
	it is replying.		chunk to which it is replying.
	The selection of the destination transport address for packets		The selection of the destination transport address for packets
	containing SACK chunks is implementation dependent. However, an		containing SACK chunks is implementation dependent. However, an
	endpoint SHOULD NOT vary the destination transport address of a SACK		endpoint SHOULD NOT vary the destination transport address of a SACK
	chunk when it receives DATA chunks coming from the same source		chunk when it receives DATA chunks coming from the same source
	address.		address.
	When acknowledging multiple DATA chunks received in packets from		When acknowledging multiple DATA chunks received in packets from
	different source addresses in a single SACK chunk, the SACK chunk MAY		different source addresses in a single SACK chunk, the SACK chunk MAY
	be transmitted to one of the destination transport addresses from		be transmitted to one of the destination transport addresses from
	skipping to change at page 91, line 29 ¶		skipping to change at line 4178 ¶
	destination address and the old destination address to which the data		destination address and the old destination address to which the data
	chunk was last sent is adjusted accordingly.		chunk was last sent is adjusted accordingly.
	6.4.1. Failover from an Inactive Destination Address		6.4.1. Failover from an Inactive Destination Address
	Some of the transport addresses of a multi-homed SCTP endpoint might		Some of the transport addresses of a multi-homed SCTP endpoint might
	become inactive due to either the occurrence of certain error		become inactive due to either the occurrence of certain error
	conditions (see Section 8.2) or adjustments from the SCTP user.		conditions (see Section 8.2) or adjustments from the SCTP user.
	When there is outbound data to send and the primary path becomes		When there is outbound data to send and the primary path becomes
	inactive (e.g., due to failures), or where the SCTP user explicitly		inactive (e.g., due to failures) or where the SCTP user explicitly
	requests to send data to an inactive destination transport address,		requests to send data to an inactive destination transport address
	before reporting an error to its ULP, the SCTP endpoint SHOULD try to		before reporting an error to its ULP, the SCTP endpoint SHOULD try to
	send the data to an alternate active destination transport address if		send the data to an alternate active destination transport address if
	one exists.		one exists.
	When retransmitting data that timed out, if the endpoint is multi-		When retransmitting data that timed out, if the endpoint is multi-
	homed, it needs to consider each source-destination address pair in		homed, it needs to consider each source-destination address pair in
	its retransmission selection policy. When retransmitting timed-out		its retransmission selection policy. When retransmitting timed-out
	data, the endpoint SHOULD attempt to pick the most divergent source-		data, the endpoint SHOULD attempt to pick the most divergent source-
	destination pair from the original source-destination pair to which		destination pair from the original source-destination pair to which
	the packet was transmitted.		the packet was transmitted.
	skipping to change at page 92, line 19 ¶		skipping to change at line 4209 ¶
	SHOULD acknowledge the reception of the DATA chunk following the		SHOULD acknowledge the reception of the DATA chunk following the
	normal procedure, immediately send an ERROR chunk with cause set to		normal procedure, immediately send an ERROR chunk with cause set to
	"Invalid Stream Identifier" (see Section 3.3.10), and discard the		"Invalid Stream Identifier" (see Section 3.3.10), and discard the
	DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK		DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK
	chunk in the same packet.		chunk in the same packet.
	The Stream Sequence Number in all the outgoing streams MUST start		The Stream Sequence Number in all the outgoing streams MUST start
	from 0 when the association is established. The Stream Sequence		from 0 when the association is established. The Stream Sequence
	Number of an outgoing stream MUST be incremented by 1 for each		Number of an outgoing stream MUST be incremented by 1 for each
	ordered user message sent on that outgoing stream. In particular,		ordered user message sent on that outgoing stream. In particular,
	when the Stream Sequence Number reaches the value 65535 the next		when the Stream Sequence Number reaches the value 65535, the next
	Stream Sequence Number MUST be set to 0. For unordered user messages		Stream Sequence Number MUST be set to 0. For unordered user
	the Stream Sequence Number MUST NOT be changed.		messages, the Stream Sequence Number MUST NOT be changed.
	6.6. Ordered and Unordered Delivery		6.6. Ordered and Unordered Delivery
	Within a stream, an endpoint MUST deliver DATA chunks received with		Within a stream, an endpoint MUST deliver DATA chunks received with
	the U flag set to 0 to the upper layer according to the order of		the U flag set to 0 to the upper layer according to the order of
	their Stream Sequence Number. If DATA chunks arrive out of order of		their Stream Sequence Number. If DATA chunks arrive out of order of
	their Stream Sequence Number, the endpoint MUST hold the received		their Stream Sequence Number, the endpoint MUST hold the received
	DATA chunks from delivery to the ULP until they are reordered.		DATA chunks from delivery to the ULP until they are reordered.
	However, an SCTP endpoint can indicate that no ordered delivery is		However, an SCTP endpoint can indicate that no ordered delivery is
	skipping to change at page 93, line 32 ¶		skipping to change at line 4271 ¶
	Multiple gaps can be reported in one single SACK chunk (see		Multiple gaps can be reported in one single SACK chunk (see
	Section 3.3.4).		Section 3.3.4).
	When its peer is multi-homed, the SCTP endpoint SHOULD always try to		When its peer is multi-homed, the SCTP endpoint SHOULD always try to
	send the SACK chunk to the same destination address from which the		send the SACK chunk to the same destination address from which the
	last DATA chunk was received.		last DATA chunk was received.
	Upon the reception of a SACK chunk, the endpoint MUST remove all DATA		Upon the reception of a SACK chunk, the endpoint MUST remove all DATA
	chunks that have been acknowledged by the SACK chunk's Cumulative TSN		chunks that have been acknowledged by the SACK chunk's Cumulative TSN
	Ack from its transmit queue. All DATA chunks with TSNs not included		Ack from its transmit queue. All DATA chunks with TSNs not included
	in the Gap Ack Blocks that are smaller than the highest acknowledged		in the Gap Ack Blocks that are smaller than the highest-acknowledged
	TSN reported in the SACK chunk MUST be treated as "missing" by the		TSN reported in the SACK chunk MUST be treated as "missing" by the
	sending endpoint. The number of "missing" reports for each		sending endpoint. The number of "missing" reports for each
	outstanding DATA chunk MUST be recorded by the data sender to make		outstanding DATA chunk MUST be recorded by the data sender to make
	retransmission decisions. See Section 7.2.4 for details.		retransmission decisions. See Section 7.2.4 for details.
	The following example shows the use of SACK chunk to report a gap.		The following example shows the use of SACK chunk to report a gap.
	Endpoint A Endpoint Z		Endpoint A Endpoint Z
	{App sends 3 messages; strm 0}		{App sends 3 messages; strm 0}
	DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)		DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
	skipping to change at page 94, line 20 ¶		skipping to change at line 4294 ¶
	DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)		DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
	DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,		DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
	immediately send ack)		immediately send ack)
	/----- SACK [TSN Ack=6,Block=1,		/----- SACK [TSN Ack=6,Block=1,
	/ Start=2,End=2]		/ Start=2,End=2]
	<-----/		<-----/
	(remove 6 from out-queue,		(remove 6 from out-queue,
	and mark 7 as "1" missing report)		and mark 7 as "1" missing report)
	Figure 9: Reporting a Gap using SACK Chunk		Figure 9: Reporting a Gap Using SACK Chunk
	The maximum number of Gap Ack Blocks that can be reported within a		The maximum number of Gap Ack Blocks that can be reported within a
	single SACK chunk is limited by the current PMTU. When a single SACK		single SACK chunk is limited by the current PMTU. When a single SACK
	chunk cannot cover all the Gap Ack Blocks needed to be reported due		chunk cannot cover all the Gap Ack Blocks needed to be reported due
	to the PMTU limitation, the endpoint MUST send only one SACK chunk.		to the PMTU limitation, the endpoint MUST send only one SACK chunk.
	This single SACK chunk MUST report the Gap Ack Blocks from the lowest		This single SACK chunk MUST report the Gap Ack Blocks from the lowest
	to highest TSNs, within the size limit set by the PMTU, and leave the		to highest TSNs, within the size limit set by the PMTU, and leave the
	remaining highest TSN numbers unacknowledged.		remaining highest TSN numbers unacknowledged.
	6.8. CRC32c Checksum Calculation		6.8. CRC32c Checksum Calculation
	When sending an SCTP packet, the endpoint MUST strengthen the data		When sending an SCTP packet, the endpoint MUST strengthen the data
	integrity of the transmission by including the CRC32c checksum value		integrity of the transmission by including the CRC32c checksum value
	calculated on the packet, as described below.		calculated on the packet, as described below.
	After the packet is constructed (containing the SCTP common header		After the packet is constructed (containing the SCTP common header
	and one or more control or DATA chunks), the transmitter MUST		and one or more control or DATA chunks), the transmitter MUST:
	1) fill in the proper Verification Tag in the SCTP common header and		1) fill in the proper Verification Tag in the SCTP common header and
	initialize the checksum field to 0,		initialize the checksum field to 0,
	2) calculate the CRC32c checksum of the whole packet, including the		2) calculate the CRC32c checksum of the whole packet, including the
	SCTP common header and all the chunks (refer to Appendix A for		SCTP common header and all the chunks (refer to Appendix A for
	details of the CRC32c algorithm); and		details of the CRC32c algorithm), and
	3) put the resultant value into the checksum field in the common		3) put the resultant value into the checksum field in the common
	header, and leave the rest of the bits unchanged.		header and leave the rest of the bits unchanged.
	When an SCTP packet is received, the receiver MUST first check the		When an SCTP packet is received, the receiver MUST first check the
	CRC32c checksum as follows:		CRC32c checksum as follows:
	1) Store the received CRC32c checksum value aside.		1) Store the received CRC32c checksum value aside.
	2) Replace the 32 bits of the checksum field in the received SCTP		2) Replace the 32 bits of the checksum field in the received SCTP
	packet with 0 and calculate a CRC32c checksum value of the whole		packet with 0 and calculate a CRC32c checksum value of the whole
	received packet.		received packet.
	skipping to change at page 95, line 33 ¶		skipping to change at line 4356 ¶
	endpoint supports fragmentation, it MUST fragment a user message if		endpoint supports fragmentation, it MUST fragment a user message if
	the size of the user message to be sent causes the outbound SCTP		the size of the user message to be sent causes the outbound SCTP
	packet size to exceed the current PMTU. An endpoint that does not		packet size to exceed the current PMTU. An endpoint that does not
	support fragmentation and is requested to send a user message such		support fragmentation and is requested to send a user message such
	that the outbound SCTP packet size would exceed the current PMTU MUST		that the outbound SCTP packet size would exceed the current PMTU MUST
	return an error to its upper layer and MUST NOT attempt to send the		return an error to its upper layer and MUST NOT attempt to send the
	user message.		user message.
	An SCTP implementation MAY provide a mechanism to the upper layer		An SCTP implementation MAY provide a mechanism to the upper layer
	that disables fragmentation when sending DATA chunks. When		that disables fragmentation when sending DATA chunks. When
	fragmentation of DATA chunks is disabeled, the SCTP implementation		fragmentation of DATA chunks is disabled, the SCTP implementation
	MUST behave in the same way an implementation that does not support		MUST behave in the same way an implementation that does not support
	fragmentation, i.e., it rejects calls that would result in sending		fragmentation, i.e., it rejects calls that would result in sending
	SCTP packets that exceed the current PMTU.		SCTP packets that exceed the current PMTU.
	Implementation Note: In this error case, the SEND primitive discussed		Implementation Note: In this error case, the SEND primitive discussed
	in Section 11.1 would need to return an error to the upper layer.		in Section 11.1.5 would need to return an error to the upper layer.
	If its peer is multi-homed, the endpoint SHOULD choose a DATA chunk		If its peer is multi-homed, the endpoint SHOULD choose a DATA chunk
	size smaller than or equal to the AMDCS.		size smaller than or equal to the AMDCS.
	Once a user message is fragmented, it cannot be re-fragmented.		Once a user message is fragmented, it cannot be re-fragmented.
	Instead, if the PMTU has been reduced, then IP fragmentation MUST be		Instead, if the PMTU has been reduced, then IP fragmentation MUST be
	used. Therefore, an SCTP association can fail if IP fragmentation is		used. Therefore, an SCTP association can fail if IP fragmentation is
	not working on any path. Please see Section 7.3 for details of PMTU		not working on any path. Please see Section 7.3 for details of PMTU
	discovery.		discovery.
	skipping to change at page 96, line 25 ¶		skipping to change at line 4393 ¶
	smaller than or equal to the AMDCS.		smaller than or equal to the AMDCS.
	2) The transmitter MUST then assign, in sequence, a separate TSN to		2) The transmitter MUST then assign, in sequence, a separate TSN to
	each of the DATA chunks in the series. The transmitter assigns		each of the DATA chunks in the series. The transmitter assigns
	the same Stream Sequence Number to each of the DATA chunks. If		the same Stream Sequence Number to each of the DATA chunks. If
	the user indicates that the user message is to be delivered using		the user indicates that the user message is to be delivered using
	unordered delivery, then the U flag of each DATA chunk of the		unordered delivery, then the U flag of each DATA chunk of the
	user message MUST be set to 1.		user message MUST be set to 1.
	3) The transmitter MUST also set the B/E bits of the first DATA		3) The transmitter MUST also set the B/E bits of the first DATA
	chunk in the series to '10', the B/E bits of the last DATA chunk		chunk in the series to 10, the B/E bits of the last DATA chunk in
	in the series to '01', and the B/E bits of all other DATA chunks		the series to 01, and the B/E bits of all other DATA chunks in
	in the series to '00'.		the series to 00.
	An endpoint MUST recognize fragmented DATA chunks by examining the B/		An endpoint MUST recognize fragmented DATA chunks by examining the B/
	E bits in each of the received DATA chunks, and queue the fragmented		E bits in each of the received DATA chunks and queue the fragmented
	DATA chunks for reassembly. Once the user message is reassembled,		DATA chunks for reassembly. Once the user message is reassembled,
	SCTP passes the reassembled user message to the specific stream for		SCTP passes the reassembled user message to the specific stream for
	possible reordering and final dispatching.		possible reordering and final dispatching.
	If the data receiver runs out of buffer space while still waiting for		If the data receiver runs out of buffer space while still waiting for
	more fragments to complete the reassembly of the message, it SHOULD		more fragments to complete the reassembly of the message, it SHOULD
	dispatch part of its inbound message through a partial delivery API		dispatch part of its inbound message through a partial delivery API
	(see Section 11), freeing some of its receive buffer space so that		(see Section 11), freeing some of its receive buffer space so that
	the rest of the message can be received.		the rest of the message can be received.
	skipping to change at page 97, line 21 ¶		skipping to change at line 4434 ¶
	DATA chunks are transmitted before SHUTDOWN or SHUTDOWN ACK chunks,		DATA chunks are transmitted before SHUTDOWN or SHUTDOWN ACK chunks,
	DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK chunks.		DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK chunks.
	Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk		Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk
	is a chunk that is not completely contained in the SCTP packet; i.e.,		is a chunk that is not completely contained in the SCTP packet; i.e.,
	the SCTP packet is too short to contain all the bytes of the chunk as		the SCTP packet is too short to contain all the bytes of the chunk as
	indicated by the chunk length.		indicated by the chunk length.
	An endpoint MUST process received chunks in their order in the		An endpoint MUST process received chunks in their order in the
	packet. The receiver uses the Chunk Length field to determine the		packet. The receiver uses the Chunk Length field to determine the
	end of a chunk and beginning of the next chunk taking account of the		end of a chunk and beginning of the next chunk, taking account of the
	fact that all chunks end on a 4-byte boundary. If the receiver		fact that all chunks end on a 4-byte boundary. If the receiver
	detects a partial chunk, it MUST drop the chunk.		detects a partial chunk, it MUST drop the chunk.
	An endpoint MUST NOT bundle INIT, INIT ACK, or SHUTDOWN COMPLETE		An endpoint MUST NOT bundle INIT, INIT ACK, or SHUTDOWN COMPLETE
	chunks with any other chunks.		chunks with any other chunks.
	7. Congestion Control		7. Congestion Control
	Congestion control is one of the basic functions in SCTP. To manage		Congestion control is one of the basic functions in SCTP. To manage
	congestion, the mechanisms and algorithms in this section are to be		congestion, the mechanisms and algorithms in this section are to be
	employed.		employed.
	Implementation Note: As far as its specific performance requirements		Implementation Note: As far as its specific performance requirements
	are met, an implementation is always allowed to adopt a more		are met, an implementation is always allowed to adopt a more
	conservative congestion control algorithm than the one defined below.		conservative congestion control algorithm than the one defined below.
	The congestion control algorithms used by SCTP are based on		The congestion control algorithms used by SCTP are based on
	[RFC5681]. This section describes how the algorithms defined in		[RFC5681]. This section describes how the algorithms defined in
	[RFC5681] are adapted for use in SCTP. We first list differences in		[RFC5681] are adapted for use in SCTP. We first list differences in
	protocol designs between TCP and SCTP, and then describe SCTP's		protocol designs between TCP and SCTP and then describe SCTP's
	congestion control scheme. The description will use the same		congestion control scheme. The description will use the same
	terminology as in TCP congestion control whenever appropriate.		terminology as in TCP congestion control whenever appropriate.
	SCTP congestion control is always applied to the entire association,		SCTP congestion control is always applied to the entire association
	and not to individual streams.		and not to individual streams.
	7.1. SCTP Differences from TCP Congestion Control		7.1. SCTP Differences from TCP Congestion Control
	Gap Ack Blocks in the SCTP SACK chunk carry the same semantic meaning		Gap Ack Blocks in the SCTP SACK chunk carry the same semantic meaning
	as the TCP SACK. TCP considers the information carried in the SACK		as the TCP SACK. TCP considers the information carried in the SACK
	as advisory information only. SCTP considers the information carried		as advisory information only. SCTP considers the information carried
	in the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any		in the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any
	DATA chunk that has been acknowledged by a SACK chunk, including DATA		DATA chunk that has been acknowledged by a SACK chunk, including DATA
	that arrived at the receiving end out of order, is not considered		that arrived at the receiving end out of order, is not considered
	skipping to change at page 98, line 25 ¶		skipping to change at line 4481 ¶
	Cumulative TSN Ack field in the SACK chunk). Consequently, the value		Cumulative TSN Ack field in the SACK chunk). Consequently, the value
	of cwnd controls the amount of outstanding data, rather than (as in		of cwnd controls the amount of outstanding data, rather than (as in
	the case of non-SACK TCP) the upper bound between the highest		the case of non-SACK TCP) the upper bound between the highest
	acknowledged sequence number and the latest DATA chunk that can be		acknowledged sequence number and the latest DATA chunk that can be
	sent within the congestion window. SCTP SACK leads to different		sent within the congestion window. SCTP SACK leads to different
	implementations of Fast Retransmit and Fast Recovery than non-SACK		implementations of Fast Retransmit and Fast Recovery than non-SACK
	TCP. As an example, see [FALL96].		TCP. As an example, see [FALL96].
	The biggest difference between SCTP and TCP, however, is multi-		The biggest difference between SCTP and TCP, however, is multi-
	homing. SCTP is designed to establish robust communication		homing. SCTP is designed to establish robust communication
	associations between two endpoints each of which might be reachable		associations between two endpoints, each of which might be reachable
	by more than one transport address. Potentially different addresses		by more than one transport address. Potentially different addresses
	might lead to different data paths between the two endpoints; thus,		might lead to different data paths between the two endpoints; thus,
	ideally one needs a separate set of congestion control parameters for		ideally, one needs a separate set of congestion control parameters
	each of the paths. The treatment here of congestion control for		for each of the paths. The treatment here of congestion control for
	multi-homed receivers is new with SCTP and might require refinement		multi-homed receivers is new with SCTP and might require refinement
	in the future. The current algorithms make the following		in the future. The current algorithms make the following
	assumptions:		assumptions:
	* The sender usually uses the same destination address until being		* The sender usually uses the same destination address until being
	instructed by the upper layer to do otherwise; however, SCTP MAY		instructed by the upper layer to do otherwise; however, SCTP MAY
	change to an alternate destination in the event an address is		change to an alternate destination in the event an address is
	marked inactive (see Section 8.2). Also, SCTP MAY retransmit to a		marked inactive (see Section 8.2). Also, SCTP MAY retransmit to a
	different transport address than the original transmission.		different transport address than the original transmission.
	skipping to change at page 99, line 6 ¶		skipping to change at line 4511 ¶
	timeout.		timeout.
	* For each of the destination addresses, an endpoint does slow start		* For each of the destination addresses, an endpoint does slow start
	upon the first transmission to that address.		upon the first transmission to that address.
	Note: TCP guarantees in-sequence delivery of data to its upper-layer		Note: TCP guarantees in-sequence delivery of data to its upper-layer
	protocol within a single TCP session. This means that when TCP		protocol within a single TCP session. This means that when TCP
	notices a gap in the received sequence number, it waits until the gap		notices a gap in the received sequence number, it waits until the gap
	is filled before delivering the data that was received with sequence		is filled before delivering the data that was received with sequence
	numbers higher than that of the missing data. On the other hand,		numbers higher than that of the missing data. On the other hand,
	SCTP can deliver data to its upper-layer protocol even if there is a		SCTP can deliver data to its upper-layer protocol, even if there is a
	gap in TSN if the Stream Sequence Numbers are in sequence for a		gap in TSN if the Stream Sequence Numbers are in sequence for a
	particular stream (i.e., the missing DATA chunks are for a different		particular stream (i.e., the missing DATA chunks are for a different
	stream) or if unordered delivery is indicated. Although this does		stream) or if unordered delivery is indicated. Although this does
	not affect cwnd, it might affect rwnd calculation.		not affect cwnd, it might affect rwnd calculation.
	7.2. SCTP Slow-Start and Congestion Avoidance		7.2. SCTP Slow-Start and Congestion Avoidance
	The slow-start and congestion avoidance algorithms MUST be used by an		The slow-start and congestion avoidance algorithms MUST be used by an
	endpoint to control the amount of data being injected into the		endpoint to control the amount of data being injected into the
	network. The congestion control in SCTP is employed in regard to the		network. The congestion control in SCTP is employed in regard to the
	skipping to change at page 99, line 44 ¶		skipping to change at line 4549 ¶
	Note: This variable is maintained on a per-destination-address		Note: This variable is maintained on a per-destination-address
	basis.		basis.
	* Slow-start threshold (ssthresh, in bytes), which is used by the		* Slow-start threshold (ssthresh, in bytes), which is used by the
	sender to distinguish slow-start and congestion avoidance phases.		sender to distinguish slow-start and congestion avoidance phases.
	Note: This variable is maintained on a per-destination-address		Note: This variable is maintained on a per-destination-address
	basis.		basis.
	SCTP also requires one additional control variable,		SCTP also requires one additional control variable,
	partial_bytes_acked, which is used during congestion avoidance phase		partial_bytes_acked, which is used during the congestion avoidance
	to facilitate cwnd adjustment.		phase to facilitate cwnd adjustment.
	Unlike TCP, an SCTP sender MUST keep a set of these control variables		Unlike TCP, an SCTP sender MUST keep a set of the control variables
	cwnd, ssthresh, and partial_bytes_acked for EACH destination address		cwnd, ssthresh, and partial_bytes_acked for EACH destination address
	of its peer (when its peer is multi-homed). When calculating one of		of its peer (when its peer is multi-homed). When calculating one of
	these variables, the length of the DATA chunk including the padding		these variables, the length of the DATA chunk, including the padding,
	SHOULD be used.		SHOULD be used.
	Only one rwnd is kept for the whole association (no matter if the		Only one rwnd is kept for the whole association (no matter if the
	peer is multi-homed or has a single address).		peer is multi-homed or has a single address).
	7.2.1. Slow-Start		7.2.1. Slow-Start
	Beginning data transmission into a network with unknown conditions or		Beginning data transmission into a network with unknown conditions or
	after a sufficiently long idle period requires SCTP to probe the		after a sufficiently long idle period requires SCTP to probe the
	network to determine the available capacity. The slow-start		network to determine the available capacity. The slow-start
	algorithm is used for this purpose at the beginning of a transfer, or		algorithm is used for this purpose at the beginning of a transfer or
	after repairing loss detected by the retransmission timer.		after repairing loss detected by the retransmission timer.
	* The initial cwnd before data transmission MUST be set to min(4 *		* The initial cwnd before data transmission MUST be set to min(4 *
	PMDCS, max(2 * PMDCS, 4404)) bytes if the peer address is an IPv4		PMDCS, max(2 * PMDCS, 4404)) bytes if the peer address is an IPv4
	address and to min(4 * PMDCS, max(2 * PMDCS, 4344)) bytes if the		address and to min(4 * PMDCS, max(2 * PMDCS, 4344)) bytes if the
	peer address is an IPv6 address.		peer address is an IPv6 address.
	* The initial cwnd after a retransmission timeout MUST be no more		* The initial cwnd after a retransmission timeout MUST be no more
	than PMDCS, and only one packet is allowed to be in flight until		than PMDCS, and only one packet is allowed to be in flight until
	successful acknowledgement.		successful acknowledgement.
	* The initial value of ssthresh SHOULD be arbitrarily high (e.g.,		* The initial value of ssthresh SHOULD be arbitrarily high (e.g.,
	the size of the largest possible advertised window).		the size of the largest-possible advertised window).
	* Whenever cwnd is greater than zero, the endpoint is allowed to		* Whenever cwnd is greater than zero, the endpoint is allowed to
	have cwnd bytes of data outstanding on that transport address. A		have cwnd bytes of data outstanding on that transport address. A
	limited overbooking as described in Section 6.1 B) SHOULD be		limited overbooking as described in rule B in Section 6.1 SHOULD
	supported.		be supported.
	* When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST		* When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
	use the slow-start algorithm to increase cwnd only if the current		use the slow-start algorithm to increase cwnd only if the current
	congestion window is being fully utilized, and the data sender is		congestion window is being fully utilized and the data sender is
	not in Fast Recovery. Only when these two conditions are met can		not in Fast Recovery. Only when these two conditions are met can
	the cwnd be increased; otherwise, the cwnd MUST NOT be increased.		the cwnd be increased; otherwise, the cwnd MUST NOT be increased.
	If these conditions are met, then cwnd MUST be increased by, at		If these conditions are met, then cwnd MUST be increased by, at
	most, the lesser of		most, the lesser of
	1. the total size of the previously outstanding DATA chunk(s)		1. the total size of the previously outstanding DATA chunk(s)
	acknowledged, and		acknowledged and
	2. L times the destination's PMDCS.		2. L times the destination's PMDCS.
	The first upper bound protects against the ACK-Splitting attack		The first upper bound protects against the ACK-Splitting attack
	outlined in [SAVAGE99]. The positive integer L SHOULD be 1, and		outlined in [SAVAGE99]. The positive integer L SHOULD be 1 and
	MAY be larger than 1. See [RFC3465] for details of choosing L.		MAY be larger than 1. See [RFC3465] for details of choosing L.
	In instances where its peer endpoint is multi-homed, if an		In instances where its peer endpoint is multi-homed, if an
	endpoint receives a SACK chunk that results in updating the cwnd,		endpoint receives a SACK chunk that results in updating the cwnd,
	then it SHOULD update its cwnd (or cwnds) apportioned to the		then it SHOULD update its cwnd (or cwnds) apportioned to the
	destination addresses to which it transmitted the acknowledged		destination addresses to which it transmitted the acknowledged
	data.		data.
	* While the endpoint does not transmit data on a given transport		* While the endpoint does not transmit data on a given transport
	address, the cwnd of the transport address SHOULD be adjusted to		address, the cwnd of the transport address SHOULD be adjusted to
	skipping to change at page 103, line 5 ¶		skipping to change at line 4698 ¶
	In the absence of data loss, an endpoint performs delayed		In the absence of data loss, an endpoint performs delayed
	acknowledgement. However, whenever an endpoint notices a hole in the		acknowledgement. However, whenever an endpoint notices a hole in the
	arriving TSN sequence, it SHOULD start sending a SACK chunk back		arriving TSN sequence, it SHOULD start sending a SACK chunk back
	every time a packet arrives carrying data until the hole is filled.		every time a packet arrives carrying data until the hole is filled.
	Whenever an endpoint receives a SACK chunk that indicates that some		Whenever an endpoint receives a SACK chunk that indicates that some
	TSNs are missing, it SHOULD wait for two further miss indications		TSNs are missing, it SHOULD wait for two further miss indications
	(via subsequent SACK chunks for a total of three missing reports) on		(via subsequent SACK chunks for a total of three missing reports) on
	the same TSNs before taking action with regard to Fast Retransmit.		the same TSNs before taking action with regard to Fast Retransmit.
	Miss indications SHOULD follow the HTNA (Highest TSN Newly		Miss indications SHOULD follow the Highest TSN Newly Acknowledged
	Acknowledged) algorithm. For each incoming SACK chunk, miss		(HTNA) algorithm. For each incoming SACK chunk, miss indications are
	indications are incremented only for missing TSNs prior to the		incremented only for missing TSNs prior to the HTNA in the SACK
	highest TSN newly acknowledged in the SACK chunk. A newly		chunk. A newly acknowledged DATA chunk is one not previously
	acknowledged DATA chunk is one not previously acknowledged in a SACK		acknowledged in a SACK chunk. If an endpoint is in Fast Recovery and
	chunk. If an endpoint is in Fast Recovery and a SACK chunks arrives		a SACK chunks arrives that advances the Cumulative TSN Ack Point, the
	that advances the Cumulative TSN Ack Point, the miss indications are		miss indications are incremented for all TSNs reported missing in the
	incremented for all TSNs reported missing in the SACK chunk.		SACK chunk.
	When the third consecutive miss indication is received for a TSN(s),		When the third consecutive miss indication is received for one or
	the data sender does the following:		more TSNs, the data sender does the following:
	1) Mark the DATA chunk(s) with three miss indications for		1) Mark the DATA chunk(s) with three miss indications for
	retransmission.		retransmission.
	2) If not in Fast Recovery, adjust the ssthresh and cwnd of the		2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
	destination address(es) to which the missing DATA chunks were		destination address(es) to which the missing DATA chunks were
	last sent, according to the formula described in Section 7.2.3.		last sent, according to the formula described in Section 7.2.3.
	3) If not in Fast Recovery, determine how many of the earliest		3) If not in Fast Recovery, determine how many of the earliest
	(i.e., lowest TSN) DATA chunks marked for retransmission will fit		(i.e., lowest TSN) DATA chunks marked for retransmission will fit
	into a single packet, subject to constraint of the PMTU of the		into a single packet, subject to constraint of the PMTU of the
	destination transport address to which the packet is being sent.		destination transport address to which the packet is being sent.
	Call this value K. Retransmit those K DATA chunks in a single		Call this value K. Retransmit those K DATA chunks in a single
	packet. When a Fast Retransmit is being performed, the sender		packet. When a Fast Retransmit is being performed, the sender
	SHOULD ignore the value of cwnd and SHOULD NOT delay		SHOULD ignore the value of cwnd and SHOULD NOT delay
	retransmission for this single packet.		retransmission for this single packet.
	4) Restart the T3-rtx timer only if the last SACK chunk acknowledged		4) Restart the T3-rtx timer only if the last SACK chunk acknowledged
	the lowest outstanding TSN number sent to that address, or the		the lowest outstanding TSN number sent to that address or the
	endpoint is retransmitting the first outstanding DATA chunk sent		endpoint is retransmitting the first outstanding DATA chunk sent
	to that address.		to that address.
	5) Mark the DATA chunk(s) as being fast retransmitted and thus		5) Mark the DATA chunk(s) as being fast retransmitted and thus
	ineligible for a subsequent Fast Retransmit. Those TSNs marked		ineligible for a subsequent Fast Retransmit. Those TSNs marked
	for retransmission due to the Fast-Retransmit algorithm that did		for retransmission due to the Fast-Retransmit algorithm that did
	not fit in the sent datagram carrying K other TSNs are also		not fit in the sent datagram carrying K other TSNs are also
	marked as ineligible for a subsequent Fast Retransmit. However,		marked as ineligible for a subsequent Fast Retransmit. However,
	as they are marked for retransmission they will be retransmitted		as they are marked for retransmission, they will be retransmitted
	later on as soon as cwnd allows.		later on as soon as cwnd allows.
	6) If not in Fast Recovery, enter Fast Recovery and mark the highest		6) If not in Fast Recovery, enter Fast Recovery and mark the highest
	outstanding TSN as the Fast Recovery exit point. When a SACK		outstanding TSN as the Fast Recovery exit point. When a SACK
	chunk acknowledges all TSNs up to and including this exit point,		chunk acknowledges all TSNs up to and including this exit point,
	Fast Recovery is exited. While in Fast Recovery, the ssthresh		Fast Recovery is exited. While in Fast Recovery, the ssthresh
	and cwnd SHOULD NOT change for any destinations due to a		and cwnd SHOULD NOT change for any destinations due to a
	subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the		subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the
	cwnd further due to a subsequent Fast Retransmit).		cwnd further due to a subsequent Fast Retransmit).
	Note: Before the above adjustments, if the received SACK chunk also		Note: Before the above adjustments, if the received SACK chunk also
	acknowledges new DATA chunks and advances the Cumulative TSN Ack		acknowledges new DATA chunks and advances the Cumulative TSN Ack
	Point, the cwnd adjustment rules defined in Section 7.2.1 and		Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
	Section 7.2.2 MUST be applied first.		MUST be applied first.
	7.2.5. Reinitialization		7.2.5. Reinitialization
	During the lifetime of an SCTP association events can happen, which		During the lifetime of an SCTP association, events can happen that
	result in using the network under unknown new conditions. When		result in using the network under unknown new conditions. When
	detected by an SCTP implementation, the congestion control MUST be		detected by an SCTP implementation, the congestion control MUST be
	reinitialized.		reinitialized.
	7.2.5.1. Change of Differentiated Services Code Points		7.2.5.1. Change of Differentiated Services Code Points
	SCTP implementations MAY allow an application to configure the		SCTP implementations MAY allow an application to configure the
	Differentiated Services Code Point (DSCP) used for sending packets.		Differentiated Services Code Point (DSCP) used for sending packets.
	If a DSCP change might result in outgoing packets being queued in		If a DSCP change might result in outgoing packets being queued in
	different queues, the congestion control parameters for all affected		different queues, the congestion control parameters for all affected
	skipping to change at page 104, line 45 ¶		skipping to change at line 4787 ¶
	[RFC8899], [RFC8201], and [RFC1191] specify "Packetization Layer Path		[RFC8899], [RFC8201], and [RFC1191] specify "Packetization Layer Path
	MTU Discovery", whereby an endpoint maintains an estimate of PMTU		MTU Discovery", whereby an endpoint maintains an estimate of PMTU
	along a given Internet path and refrains from sending packets along		along a given Internet path and refrains from sending packets along
	that path that exceed the PMTU, other than occasional attempts to		that path that exceed the PMTU, other than occasional attempts to
	probe for a change in the PMTU. [RFC8899] is thorough in its		probe for a change in the PMTU. [RFC8899] is thorough in its
	discussion of the PMTU discovery mechanism and strategies for		discussion of the PMTU discovery mechanism and strategies for
	determining the current end-to-end PMTU setting as well as detecting		determining the current end-to-end PMTU setting as well as detecting
	changes in this value.		changes in this value.
	An endpoint SHOULD apply these techniques, and SHOULD do so on a per-		An endpoint SHOULD apply these techniques and SHOULD do so on a per-
	destination-address basis.		destination-address basis.
	There are two important SCTP-specific points regarding PMTU		There are two important SCTP-specific points regarding PMTU
	discovery:		discovery:
	1) SCTP associations can span multiple addresses. An endpoint MUST		1) SCTP associations can span multiple addresses. An endpoint MUST
	maintain separate PMTU estimates for each destination address of		maintain separate PMTU estimates for each destination address of
	its peer.		its peer.
	2) The sender SHOULD track an AMDCS that will be the smallest PMDCS		2) The sender SHOULD track an AMDCS that will be the smallest PMDCS
	discovered for all of the peer's destination addresses. When		discovered for all of the peer's destination addresses. When
	fragmenting messages into multiple parts this AMDCS SHOULD be		fragmenting messages into multiple parts, this AMDCS SHOULD be
	used to calculate the size of each DATA chunk. This will allow		used to calculate the size of each DATA chunk. This will allow
	retransmissions to be seamlessly sent to an alternate address		retransmissions to be seamlessly sent to an alternate address
	without encountering IP fragmentation.		without encountering IP fragmentation.
	8. Fault Management		8. Fault Management
	8.1. Endpoint Failure Detection		8.1. Endpoint Failure Detection
	An endpoint SHOULD keep a counter on the total number of consecutive		An endpoint SHOULD keep a counter on the total number of consecutive
	retransmissions to its peer (this includes data retransmissions to		retransmissions to its peer (this includes data retransmissions to
	skipping to change at page 106, line 50 ¶		skipping to change at line 4886 ¶
	chosen and used as the new destination transport address.		chosen and used as the new destination transport address.
	8.3. Path Heartbeat		8.3. Path Heartbeat
	By default, an SCTP endpoint SHOULD monitor the reachability of the		By default, an SCTP endpoint SHOULD monitor the reachability of the
	idle destination transport address(es) of its peer by sending a		idle destination transport address(es) of its peer by sending a
	HEARTBEAT chunk periodically to the destination transport		HEARTBEAT chunk periodically to the destination transport
	address(es). The sending of HEARTBEAT chunks MAY begin upon reaching		address(es). The sending of HEARTBEAT chunks MAY begin upon reaching
	the ESTABLISHED state and is discontinued after sending either a		the ESTABLISHED state and is discontinued after sending either a
	SHUTDOWN chunk or SHUTDOWN ACK chunk. A receiver of a HEARTBEAT		SHUTDOWN chunk or SHUTDOWN ACK chunk. A receiver of a HEARTBEAT
	chunks MUST respond to a HEARTBEAT chunk with a HEARTBEAT ACK chunk		chunk MUST respond to a HEARTBEAT chunk with a HEARTBEAT ACK chunk
	after entering the COOKIE-ECHOED state (sender of the INIT chunk) or		after entering the COOKIE-ECHOED state (sender of the INIT chunk) or
	the ESTABLISHED state (receiver of the INIT chunk), up until reaching		the ESTABLISHED state (receiver of the INIT chunk), up until reaching
	the SHUTDOWN-SENT state (sender of the SHUTDOWN chunk) or the		the SHUTDOWN-SENT state (sender of the SHUTDOWN chunk) or the
	SHUTDOWN-ACK-SENT state (receiver of the SHUTDOWN chunk).		SHUTDOWN-ACK-SENT state (receiver of the SHUTDOWN chunk).
	A destination transport address is considered "idle" if no new chunk		A destination transport address is considered "idle" if no new chunk
	that can be used for updating path RTT (usually including first		that can be used for updating path RTT (usually including first
	transmission DATA, INIT, COOKIE ECHO, or HEARTBEAT chunks, etc.) and		transmission DATA, INIT, COOKIE ECHO, or HEARTBEAT chunks, etc.) and
	no HEARTBEAT chunk has been sent to it within the current heartbeat		no HEARTBEAT chunk has been sent to it within the current heartbeat
	period of that address. This applies to both active and inactive		period of that address. This applies to both active and inactive
	skipping to change at page 107, line 48 ¶		skipping to change at line 4933 ¶
	The sender of the HEARTBEAT chunk SHOULD include in the Heartbeat		The sender of the HEARTBEAT chunk SHOULD include in the Heartbeat
	Information field of the chunk the current time when the packet is		Information field of the chunk the current time when the packet is
	sent and the destination address to which the packet is sent.		sent and the destination address to which the packet is sent.
	Implementation Note: An alternative implementation of the heartbeat		Implementation Note: An alternative implementation of the heartbeat
	mechanism that can be used is to increment the error counter variable		mechanism that can be used is to increment the error counter variable
	every time a HEARTBEAT chunk is sent to a destination. Whenever a		every time a HEARTBEAT chunk is sent to a destination. Whenever a
	HEARTBEAT ACK chunk arrives, the sender SHOULD clear the error		HEARTBEAT ACK chunk arrives, the sender SHOULD clear the error
	counter of the destination that the HEARTBEAT chunk was sent to.		counter of the destination that the HEARTBEAT chunk was sent to.
	This in effect would clear the previously stroked error (and any		This, in effect, would clear the previously stroked error (and any
	other error counts as well).		other error counts as well).
	The receiver of the HEARTBEAT chunk SHOULD immediately respond with a		The receiver of the HEARTBEAT chunk SHOULD immediately respond with a
	HEARTBEAT ACK chunk that contains the Heartbeat Information TLV,		HEARTBEAT ACK chunk that contains the Heartbeat Information TLV,
	together with any other received TLVs, copied unchanged from the		together with any other received TLVs, copied unchanged from the
	received HEARTBEAT chunk.		received HEARTBEAT chunk.
	Upon the receipt of the HEARTBEAT ACK chunk, the sender of the		Upon the receipt of the HEARTBEAT ACK chunk, the sender of the
	HEARTBEAT chunk SHOULD clear the error counter of the destination		HEARTBEAT chunk SHOULD clear the error counter of the destination
	transport address to which the HEARTBEAT chunk was sent and mark the		transport address to which the HEARTBEAT chunk was sent and mark the
	skipping to change at page 108, line 27 ¶		skipping to change at line 4958 ¶
	SHOULD also clear the association overall error count (as defined in		SHOULD also clear the association overall error count (as defined in
	Section 8.1).		Section 8.1).
	The receiver of the HEARTBEAT ACK chunk SHOULD also perform an RTT		The receiver of the HEARTBEAT ACK chunk SHOULD also perform an RTT
	measurement for that destination transport address using the time		measurement for that destination transport address using the time
	value carried in the HEARTBEAT ACK chunk.		value carried in the HEARTBEAT ACK chunk.
	On an idle destination address that is allowed to heartbeat, it is		On an idle destination address that is allowed to heartbeat, it is
	RECOMMENDED that a HEARTBEAT chunk is sent once per RTO of that		RECOMMENDED that a HEARTBEAT chunk is sent once per RTO of that
	destination address plus the protocol parameter 'HB.interval', with		destination address plus the protocol parameter 'HB.interval', with
	jittering of +/- 50% of the RTO value, and exponential backoff of the		jittering of +/- 50% of the RTO value and exponential backoff of the
	RTO if the previous HEARTBEAT chunk is unanswered.		RTO if the previous HEARTBEAT chunk is unanswered.
	A primitive is provided for the SCTP user to change the 'HB.interval'		A primitive is provided for the SCTP user to change the 'HB.interval'
	and turn on or off the heartbeat on a given destination address. The		and turn on or off the heartbeat on a given destination address. The
	'HB.interval' set by the SCTP user is added to the RTO of that		'HB.interval' set by the SCTP user is added to the RTO of that
	destination (including any exponential backoff). Only one heartbeat		destination (including any exponential backoff). Only one heartbeat
	SHOULD be sent each time the heartbeat timer expires (if multiple		SHOULD be sent each time the heartbeat timer expires (if multiple
	destinations are idle). It is an implementation decision on how to		destinations are idle). It is an implementation decision on how to
	choose which of the candidate idle destinations to heartbeat to (if		choose which of the candidate idle destinations to heartbeat to (if
	more than one destination is idle).		more than one destination is idle).
	skipping to change at page 109, line 7 ¶		skipping to change at line 4984 ¶
	ABORT chunk for any reason and the ABORT chunk is lost, the local		ABORT chunk for any reason and the ABORT chunk is lost, the local
	endpoint will only discover the lost ABORT chunk by sending a DATA		endpoint will only discover the lost ABORT chunk by sending a DATA
	chunk or HEARTBEAT chunk (thus causing the peer to send another ABORT		chunk or HEARTBEAT chunk (thus causing the peer to send another ABORT
	chunk). This is to be considered when tuning the heartbeat timer.		chunk). This is to be considered when tuning the heartbeat timer.
	If the sending of HEARTBEAT chunks is disabled, only sending DATA		If the sending of HEARTBEAT chunks is disabled, only sending DATA
	chunks to the association will discover a lost ABORT chunk from the		chunks to the association will discover a lost ABORT chunk from the
	peer.		peer.
	8.4. Handle "Out of the Blue" Packets		8.4. Handle "Out of the Blue" Packets
	An SCTP packet is called an "out of the blue" (OOTB) packet if it is		An SCTP packet is called an "Out of the Blue" (OOTB) packet if it is
	correctly formed (i.e., passed the receiver's CRC32c check; see		correctly formed (i.e., passed the receiver's CRC32c check; see
	Section 6.8), but the receiver is not able to identify the		Section 6.8), but the receiver is not able to identify the
	association to which this packet belongs.		association to which this packet belongs.
	The receiver of an OOTB packet does the following:		The receiver of an OOTB packet does the following:
	1) If the OOTB packet is to or from a non-unicast address, a		1) If the OOTB packet is to or from a non-unicast address, a
	receiver SHOULD silently discard the packet. Otherwise,		receiver SHOULD silently discard the packet. Otherwise,
	2) If the OOTB packet contains an ABORT chunk, the receiver MUST		2) If the OOTB packet contains an ABORT chunk, the receiver MUST
	skipping to change at page 109, line 45 ¶		skipping to change at line 5022 ¶
	chunk. When sending the SHUTDOWN COMPLETE chunk, the receiver of		chunk. When sending the SHUTDOWN COMPLETE chunk, the receiver of
	the OOTB packet MUST fill in the Verification Tag field of the		the OOTB packet MUST fill in the Verification Tag field of the
	outbound packet with the Verification Tag received in the		outbound packet with the Verification Tag received in the
	SHUTDOWN ACK chunk and set the T bit in the Chunk Flags to		SHUTDOWN ACK chunk and set the T bit in the Chunk Flags to
	indicate that the Verification Tag is reflected. Otherwise,		indicate that the Verification Tag is reflected. Otherwise,
	6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver		6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver
	SHOULD silently discard the packet and take no further action.		SHOULD silently discard the packet and take no further action.
	Otherwise,		Otherwise,
	7) If the packet contains a ERROR chunk with the "Stale Cookie"		7) If the packet contains an ERROR chunk with the "Stale Cookie"
	error cause or a COOKIE ACK chunk, the SCTP packet SHOULD be		error cause or a COOKIE ACK chunk, the SCTP packet SHOULD be
	silently discarded. Otherwise,		silently discarded. Otherwise,
	8) The receiver SHOULD respond to the sender of the OOTB packet with		8) The receiver SHOULD respond to the sender of the OOTB packet with
	an ABORT chunk. When sending the ABORT chunk, the receiver of		an ABORT chunk. When sending the ABORT chunk, the receiver of
	the OOTB packet MUST fill in the Verification Tag field of the		the OOTB packet MUST fill in the Verification Tag field of the
	outbound packet with the value found in the Verification Tag		outbound packet with the value found in the Verification Tag
	field of the OOTB packet and set the T bit in the Chunk Flags to		field of the OOTB packet and set the T bit in the Chunk Flags to
	indicate that the Verification Tag is reflected. After sending		indicate that the Verification Tag is reflected. After sending
	this ABORT chunk, the receiver of the OOTB packet MUST discard		this ABORT chunk, the receiver of the OOTB packet MUST discard
	skipping to change at page 110, line 26 ¶		skipping to change at line 5052 ¶
	When sending an SCTP packet, the endpoint MUST fill in the		When sending an SCTP packet, the endpoint MUST fill in the
	Verification Tag field of the outbound packet with the tag value in		Verification Tag field of the outbound packet with the tag value in
	the Initiate Tag parameter of the INIT or INIT ACK chunk received		the Initiate Tag parameter of the INIT or INIT ACK chunk received
	from its peer.		from its peer.
	When receiving an SCTP packet, the endpoint MUST ensure that the		When receiving an SCTP packet, the endpoint MUST ensure that the
	value in the Verification Tag field of the received SCTP packet		value in the Verification Tag field of the received SCTP packet
	matches its own tag. If the received Verification Tag value does not		matches its own tag. If the received Verification Tag value does not
	match the receiver's own tag value, the receiver MUST silently		match the receiver's own tag value, the receiver MUST silently
	discard the packet and MUST NOT process it any further except for		discard the packet and MUST NOT process it any further, except for
	those cases listed in Section 8.5.1 below.		those cases listed in Section 8.5.1 below.
	8.5.1. Exceptions in Verification Tag Rules		8.5.1. Exceptions in Verification Tag Rules
	A) Rules for packets carrying an INIT chunk:		A) Rules for packets carrying an INIT chunk:
	* The sender MUST set the Verification Tag of the packet to 0.		* The sender MUST set the Verification Tag of the packet to 0.
	* When an endpoint receives an SCTP packet with the Verification		* When an endpoint receives an SCTP packet with the Verification
	Tag set to 0, it SHOULD verify that the packet contains only an		Tag set to 0, it SHOULD verify that the packet contains only an
	INIT chunk. Otherwise, the receiver MUST silently discard the		INIT chunk. Otherwise, the receiver MUST silently discard the
	packet.		packet.
	B) Rules for packets carrying an ABORT chunk:		B) Rules for packets carrying an ABORT chunk:
	* The endpoint MUST always fill in the Verification Tag field of		* The endpoint MUST always fill in the Verification Tag field of
	the outbound packet with the destination endpoint's tag value,		the outbound packet with the destination endpoint's tag value
	if it is known.		if it is known.
	* If the ABORT chunk is sent in response to an OOTB packet, the		* If the ABORT chunk is sent in response to an OOTB packet, the
	endpoint MUST follow the procedure described in Section 8.4.		endpoint MUST follow the procedure described in Section 8.4.
	* The receiver of an ABORT chunk MUST accept the packet if the		* The receiver of an ABORT chunk MUST accept the packet if the
	Verification Tag field of the packet matches its own tag and		Verification Tag field of the packet matches its own tag and
	the T bit is not set OR if it is set to its peer's tag and the		the T bit is not set OR if it is set to its Peer's Tag and the
	T bit is set in the Chunk Flags. Otherwise, the receiver MUST		T bit is set in the Chunk Flags. Otherwise, the receiver MUST
	silently discard the packet and take no further action.		silently discard the packet and take no further action.
	C) Rules for packets carrying a SHUTDOWN COMPLETE chunk:		C) Rules for packets carrying a SHUTDOWN COMPLETE chunk:
	* When sending a SHUTDOWN COMPLETE chunk, if the receiver of the		* When sending a SHUTDOWN COMPLETE chunk, if the receiver of the
	SHUTDOWN ACK chunk has a TCB, then the destination endpoint's		SHUTDOWN ACK chunk has a TCB, then the destination endpoint's
	tag MUST be used, and the T bit MUST NOT be set. Only where no		tag MUST be used and the T bit MUST NOT be set. Only where no
	TCB exists SHOULD the sender use the Verification Tag from the		TCB exists SHOULD the sender use the Verification Tag from the
	SHUTDOWN ACK chunk, and MUST set the T bit.		SHUTDOWN ACK chunk and MUST set the T bit.
	* The receiver of a SHUTDOWN COMPLETE chunk accepts the packet if		* The receiver of a SHUTDOWN COMPLETE chunk accepts the packet if
	the Verification Tag field of the packet matches its own tag		the Verification Tag field of the packet matches its own tag
	and the T bit is not set OR if it is set to its peer's tag and		and the T bit is not set OR if it is set to its Peer's Tag and
	the T bit is set in the Chunk Flags. Otherwise, the receiver		the T bit is set in the Chunk Flags. Otherwise, the receiver
	MUST silently discard the packet and take no further action.		MUST silently discard the packet and take no further action.
	An endpoint MUST ignore the SHUTDOWN COMPLETE chunk if it is		An endpoint MUST ignore the SHUTDOWN COMPLETE chunk if it is
	not in the SHUTDOWN-ACK-SENT state.		not in the SHUTDOWN-ACK-SENT state.
	D) Rules for packets carrying a COOKIE ECHO chunk:		D) Rules for packets carrying a COOKIE ECHO chunk:
	* When sending a COOKIE ECHO chunk, the endpoint MUST use the		* When sending a COOKIE ECHO chunk, the endpoint MUST use the
	value of the Initiate Tag received in the INIT ACK chunk.		value of the Initiate Tag received in the INIT ACK chunk.
	* The receiver of a COOKIE ECHO chunk follows the procedures in		* The receiver of a COOKIE ECHO chunk follows the procedures in
	Section 5.		Section 5.
	E) Rules for packets carrying a SHUTDOWN ACK chunk:		E) Rules for packets carrying a SHUTDOWN ACK chunk:
	* If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the		* If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state, the
	procedures in Section 8.4 SHOULD be followed; in other words,		procedures in Section 8.4 SHOULD be followed; in other words,
	it is treated as an OOTB packet.		it is treated as an OOTB packet.
	9. Termination of Association		9. Termination of Association
	An endpoint SHOULD terminate its association when it exits from		An endpoint SHOULD terminate its association when it exits from
	service. An association can be terminated by either abort or		service. An association can be terminated by either abort or
	shutdown. An abort of an association is abortive by definition in		shutdown. An abort of an association is abortive by definition in
	that any data pending on either end of the association is discarded		that any data pending on either end of the association is discarded
	and not delivered to the peer. A shutdown of an association is		and not delivered to the peer. A shutdown of an association is
	considered a graceful close where all data in queue by either		considered a graceful close where all data in queue by either
	endpoint is delivered to the respective peers. However, in the case		endpoint is delivered to the respective peers. However, in the case
	of a shutdown, SCTP does not support a half-open state (like TCP)		of a shutdown, SCTP does not support a half-open state (like TCP),
	wherein one side might continue sending data while the other end is		wherein one side might continue sending data while the other end is
	closed. When either endpoint performs a shutdown, the association on		closed. When either endpoint performs a shutdown, the association on
	each peer will stop accepting new data from its user and only deliver		each peer will stop accepting new data from its user and only deliver
	data in queue at the time of sending or receiving the SHUTDOWN chunk.		data in queue at the time of sending or receiving the SHUTDOWN chunk.
	9.1. Abort of an Association		9.1. Abort of an Association
	When an endpoint decides to abort an existing association, it MUST		When an endpoint decides to abort an existing association, it MUST
	send an ABORT chunk to its peer endpoint. The sender MUST fill in		send an ABORT chunk to its peer endpoint. The sender MUST fill in
	the peer's Verification Tag in the outbound packet and MUST NOT		the peer's Verification Tag in the outbound packet and MUST NOT
	skipping to change at page 112, line 36 ¶		skipping to change at line 5152 ¶
	9.2. Shutdown of an Association		9.2. Shutdown of an Association
	Using the SHUTDOWN primitive (see Section 11.1), the upper layer of		Using the SHUTDOWN primitive (see Section 11.1), the upper layer of
	an endpoint in an association can gracefully close the association.		an endpoint in an association can gracefully close the association.
	This will allow all outstanding DATA chunks from the peer of the		This will allow all outstanding DATA chunks from the peer of the
	shutdown initiator to be delivered before the association terminates.		shutdown initiator to be delivered before the association terminates.
	Upon receipt of the SHUTDOWN primitive from its upper layer, the		Upon receipt of the SHUTDOWN primitive from its upper layer, the
	endpoint enters the SHUTDOWN-PENDING state and remains there until		endpoint enters the SHUTDOWN-PENDING state and remains there until
	all outstanding data has been acknowledged by its peer. The endpoint		all outstanding data has been acknowledged by its peer. The endpoint
	accepts no new data from its upper layer, but retransmits data to the		accepts no new data from its upper layer but retransmits data to the
	peer endpoint if necessary to fill gaps.		peer endpoint if necessary to fill gaps.
	Once all its outstanding data has been acknowledged, the endpoint		Once all its outstanding data has been acknowledged, the endpoint
	sends a SHUTDOWN chunk to its peer including in the Cumulative TSN		sends a SHUTDOWN chunk to its peer, including in the Cumulative TSN
	Ack field the last sequential TSN it has received from the peer. It		Ack field the last sequential TSN it has received from the peer. It
	SHOULD then start the T2-shutdown timer and enter the SHUTDOWN-SENT		SHOULD then start the T2-shutdown timer and enter the SHUTDOWN-SENT
	state. If the timer expires, the endpoint MUST resend the SHUTDOWN		state. If the timer expires, the endpoint MUST resend the SHUTDOWN
	chunk with the updated last sequential TSN received from its peer.		chunk with the updated last sequential TSN received from its peer.
	The rules in Section 6.3 MUST be followed to determine the proper		The rules in Section 6.3 MUST be followed to determine the proper
	timer value for T2-shutdown. To indicate any gaps in TSN, the		timer value for T2-shutdown. To indicate any gaps in TSN, the
	endpoint MAY also bundle a SACK chunk with the SHUTDOWN chunk in the		endpoint MAY also bundle a SACK chunk with the SHUTDOWN chunk in the
	same SCTP packet.		same SCTP packet.
	skipping to change at page 113, line 41 ¶		skipping to change at line 5203 ¶
	receiver MUST continue to follow normal data transmission procedures		receiver MUST continue to follow normal data transmission procedures
	defined in Section 6, until all outstanding DATA chunks are		defined in Section 6, until all outstanding DATA chunks are
	acknowledged; however, the SHUTDOWN chunk receiver MUST NOT accept		acknowledged; however, the SHUTDOWN chunk receiver MUST NOT accept
	new data from its SCTP user.		new data from its SCTP user.
	While in the SHUTDOWN-SENT state, the SHUTDOWN chunk sender MUST		While in the SHUTDOWN-SENT state, the SHUTDOWN chunk sender MUST
	immediately respond to each received packet containing one or more		immediately respond to each received packet containing one or more
	DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer.		DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer.
	If a SHUTDOWN chunk by itself cannot acknowledge all of the received		If a SHUTDOWN chunk by itself cannot acknowledge all of the received
	DATA chunks (i.e., there are TSNs that can be acknowledged that are		DATA chunks (i.e., there are TSNs that can be acknowledged that are
	larger than the cumulative TSN, and thus gaps exist in the TSN		larger than the cumulative TSN and thus gaps exist in the TSN
	sequence), or if duplicate TSNs have been received, then a SACK chunk		sequence) or if duplicate TSNs have been received, then a SACK chunk
	MUST also be sent.		MUST also be sent.
	The sender of the SHUTDOWN chunk MAY also start an overall guard		The sender of the SHUTDOWN chunk MAY also start an overall guard
	timer T5-shutdown-guard to bound the overall time for the shutdown		timer T5-shutdown-guard to bound the overall time for the shutdown
	sequence. At the expiration of this timer, the sender SHOULD abort		sequence. At the expiration of this timer, the sender SHOULD abort
	the association by sending an ABORT chunk. If the T5-shutdown-guard		the association by sending an ABORT chunk. If the T5-shutdown-guard
	timer is used, it SHOULD be set to the RECOMMENDED value of 5 times		timer is used, it SHOULD be set to the RECOMMENDED value of 5 times
	'RTO.Max'.		'RTO.Max'.
	If the receiver of the SHUTDOWN chunk has no more outstanding DATA		If the receiver of the SHUTDOWN chunk has no more outstanding DATA
	skipping to change at page 115, line 13 ¶		skipping to change at line 5271 ¶
	in Section 8.4. The sender of the INIT chunk lets T1-init continue		in Section 8.4. The sender of the INIT chunk lets T1-init continue
	running and remains in the COOKIE-WAIT or COOKIE-ECHOED state.		running and remains in the COOKIE-WAIT or COOKIE-ECHOED state.
	Normal T1-init timer expiration will cause the INIT or COOKIE chunk		Normal T1-init timer expiration will cause the INIT or COOKIE chunk
	to be retransmitted and thus start a new association.		to be retransmitted and thus start a new association.
	If a SHUTDOWN chunk is received in the COOKIE-WAIT or COOKIE ECHOED		If a SHUTDOWN chunk is received in the COOKIE-WAIT or COOKIE ECHOED
	state, the SHUTDOWN chunk SHOULD be silently discarded.		state, the SHUTDOWN chunk SHOULD be silently discarded.
	If an endpoint is in the SHUTDOWN-SENT state and receives a SHUTDOWN		If an endpoint is in the SHUTDOWN-SENT state and receives a SHUTDOWN
	chunk from its peer, the endpoint SHOULD respond immediately with a		chunk from its peer, the endpoint SHOULD respond immediately with a
	SHUTDOWN ACK chunk to its peer, and move into the SHUTDOWN-ACK-SENT		SHUTDOWN ACK chunk to its peer and move into the SHUTDOWN-ACK-SENT
	state restarting its T2-shutdown timer.		state, restarting its T2-shutdown timer.
	If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a		If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a
	SHUTDOWN ACK, it MUST stop the T2-shutdown timer, send a SHUTDOWN		SHUTDOWN ACK, it MUST stop the T2-shutdown timer, send a SHUTDOWN
	COMPLETE chunk to its peer, and remove all record of the association.		COMPLETE chunk to its peer, and remove all record of the association.
	10. ICMP Handling		10. ICMP Handling
	Whenever an ICMP message is received by an SCTP endpoint, the		Whenever an ICMP message is received by an SCTP endpoint, the
	following procedures MUST be followed to ensure proper utilization of		following procedures MUST be followed to ensure proper utilization of
	the information being provided by layer 3.		the information being provided by layer 3.
	skipping to change at page 116, line 21 ¶		skipping to change at line 5319 ¶
	the peer, continue with ICMP7. If the ICMP message is too		the peer, continue with ICMP7. If the ICMP message is too
	short or the chunk type or the Initiate Tag does not match,		short or the chunk type or the Initiate Tag does not match,
	silently discard the packet.		silently discard the packet.
	ICMP7) If the ICMP message is either an ICMPv6 message of type		ICMP7) If the ICMP message is either an ICMPv6 message of type
	"Packet Too Big" or an ICMPv4 message of type "Destination		"Packet Too Big" or an ICMPv4 message of type "Destination
	Unreachable" and code "Fragmentation Needed", an		Unreachable" and code "Fragmentation Needed", an
	implementation SHOULD process this information as defined for		implementation SHOULD process this information as defined for
	PMTU discovery.		PMTU discovery.
	ICMP8) If the ICMP code is an "Unrecognized Next Header Type		ICMP8) If the ICMP code is "Unrecognized Next Header Type
	Encountered" or a "Protocol Unreachable", an implementation		Encountered" or "Protocol Unreachable", an implementation
	MUST treat this message as an abort with the T bit set if it		MUST treat this message as an abort with the T bit set if it
	does not contain an INIT chunk. If it does contain an INIT		does not contain an INIT chunk. If it does contain an INIT
	chunk and the association is in the COOKIE-WAIT state, handle		chunk and the association is in the COOKIE-WAIT state, handle
	the ICMP message like an ABORT chunk.		the ICMP message like an ABORT chunk.
	ICMP9) If the ICMP type is "Destination Unreachable", the		ICMP9) If the ICMP type is "Destination Unreachable", the
	implementation MAY move the destination to the unreachable		implementation MAY move the destination to the unreachable
	state or, alternatively, increment the path error counter.		state or, alternatively, increment the path error counter.
	SCTP MAY provide information to the upper layer indicating		SCTP MAY provide information to the upper layer indicating
	the reception of ICMP messages when reporting a network		the reception of ICMP messages when reporting a network
	status change.		status change.
	These procedures differ from [RFC1122] and from its requirements for		These procedures differ from [RFC1122] and from its requirements for
	processing of port-unreachable messages and the requirements that an		processing of port-unreachable messages and the requirements that an
	implementation MUST abort associations in response to a "protocol		implementation MUST abort associations in response to a protocol
	unreachable" message. Port-unreachable messages are not processed,		unreachable message. Port-unreachable messages are not processed,
	since an implementation will send an ABORT chunk, not a port		since an implementation will send an ABORT chunk, not a port-
	unreachable. The stricter handling of the "protocol unreachable"		unreachable message. The stricter handling of the protocol
	message is due to security concerns for hosts that do not support		unreachable message is due to security concerns for hosts that do not
	SCTP.		support SCTP.
	11. Interface with Upper Layer		11. Interface with Upper Layer
	The Upper Layer Protocols (ULPs) request services by passing		The Upper Layer Protocols (ULPs) request services by passing
	primitives to SCTP and receive notifications from SCTP for various		primitives to SCTP and receive notifications from SCTP for various
	events.		events.
	The primitives and notifications described in this section can be		The primitives and notifications described in this section can be
	used as a guideline for implementing SCTP. The following functional		used as a guideline for implementing SCTP. The following functional
	description of ULP interface primitives is shown for illustrative		description of ULP interface primitives is shown for illustrative
	purposes. Different SCTP implementations can have different ULP		purposes. Different SCTP implementations can have different ULP
	interfaces. However, all SCTP implementations are expected to		interfaces. However, all SCTP implementations are expected to
	provide a certain minimum set of services to guarantee that all SCTP		provide a certain minimum set of services to guarantee that all SCTP
	implementations can support the same protocol hierarchy.		implementations can support the same protocol hierarchy.
	Please note that this section is informational only.		Please note that this section is informational only.
	[RFC6458] and the Socket API Considerations section of [RFC7053]		[RFC6458] and Section 7 ("Socket API Considerations") of [RFC7053]
	define an extension of the socket API for SCTP as described in this		define an extension of the socket API for SCTP as described in this
	document.		document.
	11.1. ULP-to-SCTP		11.1. ULP-to-SCTP
	The following sections functionally characterize a ULP/SCTP		The following sections functionally characterize a ULP/SCTP
	interface. The notation used is similar to most procedure or		interface. The notation used is similar to most procedure or
	function calls in high-level languages.		function calls in high-level languages.
	The ULP primitives described below specify the basic functions that		The ULP primitives described below specify the basic functions that
	SCTP performs to support inter-process communication. Individual		SCTP performs to support inter-process communication. Individual
	implementations define their own exact format, and provide		implementations define their own exact format and provide
	combinations or subsets of the basic functions in single calls.		combinations or subsets of the basic functions in single calls.
	11.1.1. Initialize		11.1.1. Initialize
	INITIALIZE ([local port],[local eligible address list])		INITIALIZE ([local port],[local eligible address list])
	-> local SCTP instance name		-> local SCTP instance name
	This primitive allows SCTP to initialize its internal data structures		This primitive allows SCTP to initialize its internal data structures
	and allocate necessary resources for setting up its operation		and allocate necessary resources for setting up its operation
	environment. Once SCTP is initialized, ULP can communicate directly		environment. Once SCTP is initialized, ULP can communicate directly
	skipping to change at page 118, line 22 ¶		skipping to change at line 5413 ¶
	ASSOCIATE(local SCTP instance name,		ASSOCIATE(local SCTP instance name,
	initial destination transport addr list, outbound stream count)		initial destination transport addr list, outbound stream count)
	-> association id [,destination transport addr list]		-> association id [,destination transport addr list]
	[,outbound stream count]		[,outbound stream count]
	This primitive allows the upper layer to initiate an association to a		This primitive allows the upper layer to initiate an association to a
	specific peer endpoint.		specific peer endpoint.
	The peer endpoint is specified by one or more of the transport		The peer endpoint is specified by one or more of the transport
	addresses that defines the endpoint (see Section 2.3). If the local		addresses that defines the endpoint (see Section 1.3). If the local
	SCTP instance has not been initialized, the ASSOCIATE is considered		SCTP instance has not been initialized, the ASSOCIATE is considered
	an error.		an error.
	An association id, which is a local handle to the SCTP association,		An association id, which is a local handle to the SCTP association,
	will be returned on successful establishment of the association. If		will be returned on successful establishment of the association. If
	SCTP is not able to open an SCTP association with the peer endpoint,		SCTP is not able to open an SCTP association with the peer endpoint,
	an error is returned.		an error is returned.
	Other association parameters can be returned, including the complete		Other association parameters can be returned, including the complete
	destination transport addresses of the peer as well as the outbound		destination transport addresses of the peer as well as the outbound
	stream count of the local endpoint. One of the transport addresses		stream count of the local endpoint. One of the transport addresses
	from the returned destination addresses will be selected by the local		from the returned destination addresses will be selected by the local
	endpoint as default primary path for sending SCTP packets to this		endpoint as the default primary path for sending SCTP packets to this
	peer. The returned "destination transport addr list" can be used by		peer. The returned "destination transport addr list" can be used by
	the ULP to change the default primary path or to force sending a		the ULP to change the default primary path or to force sending a
	packet to a specific transport address.		packet to a specific transport address.
	Implementation Note: If ASSOCIATE primitive is implemented as a		Implementation Note: If the ASSOCIATE primitive is implemented as a
	blocking function call, the ASSOCIATE primitive can return		blocking function call, the ASSOCIATE primitive can return
	association parameters in addition to the association id upon		association parameters in addition to the association id upon
	successful establishment. If ASSOCIATE primitive is implemented as a		successful establishment. If ASSOCIATE primitive is implemented as a
	non-blocking call, only the association id is returned and		non-blocking call, only the association id is returned and
	association parameters are passed using the COMMUNICATION UP		association parameters are passed using the COMMUNICATION UP
	notification.		notification.
	Mandatory attributes:		Mandatory attributes:
	local SCTP instance name: obtained from the INITIALIZE operation.		local SCTP instance name: obtained from the INITIALIZE operation.
	skipping to change at page 120, line 4 ¶		skipping to change at line 5487 ¶
	code is returned.		code is returned.
	Mandatory attributes:		Mandatory attributes:
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	Optional attributes:		Optional attributes:
	Upper Layer Abort Reason: reason of the abort to be passed to the		Upper Layer Abort Reason: reason of the abort to be passed to the
	peer.		peer.
	11.1.5. Send		11.1.5. Send
	SEND(association id, buffer address, byte count [,context]		SEND(association id, buffer address, byte count [,context]
	[,stream id] [,life time] [,destination transport address]		[,stream id] [,life time] [,destination transport address]
	[,unordered flag] [,no-bundle flag] [,payload protocol-id]		[,unordered flag] [,no-bundle flag] [,payload protocol-id]
	[,sack-immediately flag]) -> result		[,sack-immediately flag]) -> result
	This is the main method to send user data via SCTP.		This is the main method to send user data via SCTP.
	Mandatory attributes:		Mandatory attributes:
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	buffer address: the location where the user message to be		buffer address: the location where the user message to be
	transmitted is stored.		transmitted is stored.
	byte count: the size of the user data in number of bytes.		byte count: the size of the user data in number of bytes.
	Optional attributes:		Optional attributes:
	context: an optional information provided that will be carried in		context: optional information provided that will be carried in
	the sending failure notification to the ULP if the		the SEND FAILURE notification to the ULP if the transportation
	transportation of this user message fails.		of this user message fails.
	stream id: to indicate which stream to send the data on. If not		stream id: indicates which stream to send the data on. If not
	specified, stream 0 will be used.		specified, stream 0 will be used.
	life time: specifies the life time of the user data. The user		life time: specifies the life time of the user data. The user
	data will not be sent by SCTP after the life time expires.		data will not be sent by SCTP after the life time expires.
	This parameter can be used to avoid efforts to transmit stale		This parameter can be used to avoid efforts to transmit stale
	user messages. SCTP notifies the ULP if the data cannot be		user messages. SCTP notifies the ULP if the data cannot be
	initiated to transport (i.e., sent to the destination via		initiated to transport (i.e., sent to the destination via
	SCTP's SEND primitive) within the life time variable. However,		SCTP's SEND primitive) within the life time variable. However,
	the user data will be transmitted if SCTP has attempted to		the user data will be transmitted if SCTP has attempted to
	transmit a chunk before the life time expired.		transmit a chunk before the life time expired.
	Implementation Note: In order to better support the data life		Implementation Note: In order to better support the data life
	time option, the transmitter can hold back the assigning of the		time option, the transmitter can hold back the assigning of the
	TSN number to an outbound DATA chunk to the last moment. And,		TSN number to an outbound DATA chunk to the last moment. And,
	for implementation simplicity, once a TSN number has been		for implementation simplicity, once a TSN number has been
	assigned the sender considers the send of this DATA chunk as		assigned, the sender considers the send of this DATA chunk as
	committed, overriding any life time option attached to the DATA		committed, overriding any life time option attached to the DATA
	chunk.		chunk.
	destination transport address: specified as one of the		destination transport address: specified as one of the
	destination transport addresses of the peer endpoint to which		destination transport addresses of the peer endpoint to which
	this packet is sent. Whenever possible, SCTP uses this		this packet is sent. Whenever possible, SCTP uses this
	destination transport address for sending the packets, instead		destination transport address for sending the packets, instead
	of the current primary path.		of the current primary path.
	unordered flag: this flag, if present, indicates that the user		unordered flag: this flag, if present, indicates that the user
	skipping to change at page 121, line 15 ¶		skipping to change at line 5546 ¶
	peer (i.e., the U flag is set to 1 on all DATA chunks carrying		peer (i.e., the U flag is set to 1 on all DATA chunks carrying
	this message).		this message).
	no-bundle flag: instructs SCTP not to delay the sending of DATA		no-bundle flag: instructs SCTP not to delay the sending of DATA
	chunks for this user data just to allow it to be bundled with		chunks for this user data just to allow it to be bundled with
	other outbound DATA chunks. When faced with network		other outbound DATA chunks. When faced with network
	congestion, SCTP might still bundle the data, even when this		congestion, SCTP might still bundle the data, even when this
	flag is present.		flag is present.
	payload protocol-id: a 32-bit unsigned integer that is to be		payload protocol-id: a 32-bit unsigned integer that is to be
	passed to the peer indicating the type of payload protocol data		passed to the peer, indicating the type of payload protocol
	being transmitted. Note that the upper layer is responsible		data being transmitted. Note that the upper layer is
	for the host to network byte order conversion of this field,		responsible for the host to network byte order conversion of
	which is passed by SCTP as 4 bytes of opaque data.		this field, which is passed by SCTP as 4 bytes of opaque data.
	sack-immediately flag: set the I bit on the last DATA chunk used		sack-immediately flag: set the I bit on the last DATA chunk used
	for the user message to be transmitted.		for the user message to be transmitted.
	11.1.6. Set Primary		11.1.6. Set Primary
	SETPRIMARY(association id, destination transport address,		SETPRIMARY(association id, destination transport address,
	[source transport address]) -> result		[source transport address]) -> result
	Instructs the local SCTP to use the specified destination transport		Instructs the local SCTP to use the specified destination transport
	address as the primary path for sending packets.		address as the primary path for sending packets.
	The result of attempting this operation is returned. If the		The result of attempting this operation is returned. If the
	specified destination transport address is not present in the		specified destination transport address is not present in the
	"destination transport address list" returned earlier in an associate		"destination transport address list" returned earlier in an ASSOCIATE
	command or communication up notification, an error is returned.		primitive or COMMUNICATION UP notification, an error is returned.
	Mandatory attributes:		Mandatory attributes:
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	destination transport address: specified as one of the transport		destination transport address: specified as one of the transport
	addresses of the peer endpoint, which is used as the primary		addresses of the peer endpoint, which is used as the primary
	address for sending packets. This overrides the current		address for sending packets. This overrides the current
	primary address information maintained by the local SCTP		primary address information maintained by the local SCTP
	endpoint.		endpoint.
	skipping to change at page 122, line 4 ¶		skipping to change at line 5582 ¶
	address for sending packets. This overrides the current		address for sending packets. This overrides the current
	primary address information maintained by the local SCTP		primary address information maintained by the local SCTP
	endpoint.		endpoint.
	Optional attributes:		Optional attributes:
	source transport address: optionally, some implementations can		source transport address: optionally, some implementations can
	allow you to set the default source address placed in all		allow you to set the default source address placed in all
	outgoing IP datagrams.		outgoing IP datagrams.
	11.1.7. Receive		11.1.7. Receive
	RECEIVE(association id, buffer address, buffer size [,stream id])		RECEIVE(association id, buffer address, buffer size [,stream id])
	-> byte count [,transport address] [,stream id]		-> byte count [,transport address] [,stream id]
	[,stream sequence number] [,partial flag] [,payload protocol-id]		[,stream sequence number] [,partial flag] [,payload protocol-id]
	This primitive reads the first user message in the SCTP in-queue into		This primitive reads the first user message in the SCTP in-queue into
	the buffer specified by ULP, if there is one available. The size of		the buffer specified by ULP, if there is one available. The size of
	the message read, in bytes, will be returned. It might, depending on		the message read, in bytes, will be returned. It might, depending on
	the specific implementation, also return other information such as		the specific implementation, also return other information, such as
	the sender's address, the stream id on which it is received, whether		the sender's address, the stream id on which it is received, whether
	there are more messages available for retrieval, etc. For ordered		there are more messages available for retrieval, etc. For ordered
	messages, their Stream Sequence Number might also be returned.		messages, their Stream Sequence Number might also be returned.
	Depending upon the implementation, if this primitive is invoked when		Depending upon the implementation, if this primitive is invoked when
	no message is available the implementation returns an indication of		no message is available, the implementation returns an indication of
	this condition or blocks the invoking process until data does become		this condition or blocks the invoking process until data does become
	available.		available.
	Mandatory attributes:		Mandatory attributes:
	association id: local handle to the SCTP association		association id: local handle to the SCTP association.
	buffer address: the memory location indicated by the ULP to store		buffer address: the memory location indicated by the ULP to store
	the received message.		the received message.
	buffer size: the maximum size of data to be received, in bytes.		buffer size: the maximum size of data to be received, in bytes.
	Optional attributes:		Optional attributes:
	stream id: to indicate which stream to receive the data on.		stream id: to indicate which stream to receive the data on.
	stream sequence number: the Stream Sequence Number assigned by		stream sequence number: the Stream Sequence Number assigned by
	skipping to change at page 124, line 22 ¶		skipping to change at line 5697 ¶
	This value is added to the RTO of the destination transport		This value is added to the RTO of the destination transport
	address. This value, if present, affects all destinations.		address. This value, if present, affects all destinations.
	11.1.10. Request Heartbeat		11.1.10. Request Heartbeat
	REQUESTHEARTBEAT(association id, destination transport address)		REQUESTHEARTBEAT(association id, destination transport address)
	-> result		-> result
	Instructs the local endpoint to perform a heartbeat on the specified		Instructs the local endpoint to perform a heartbeat on the specified
	destination transport address of the given association. The returned		destination transport address of the given association. The returned
	result indicates whether the transmission of the HEARTBEAT chunk		result indicates whether the transmission of the HEARTBEAT chunk to
	chunk to the destination address is successful.		the destination address is successful.
	Mandatory attributes:		Mandatory attributes:
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	destination transport address: the transport address of the		destination transport address: the transport address of the
	association on which a heartbeat is issued.		association on which a heartbeat is issued.
	Optional attributes:		Optional attributes:
	None.		None.
	skipping to change at page 125, line 42 ¶		skipping to change at line 5765 ¶
	-> result		-> result
	This primitive allows the local SCTP to customize the protocol		This primitive allows the local SCTP to customize the protocol
	parameters.		parameters.
	Mandatory attributes:		Mandatory attributes:
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	protocol parameter list: the specific names and values of the		protocol parameter list: the specific names and values of the
	protocol parameters (e.g., 'Association.Max.Retrans' (see		protocol parameters (e.g., 'Association.Max.Retrans' (see
	Section 16), or other parameters like the DSCP) that the SCTP		Section 16) or other parameters like the DSCP) that the SCTP
	user wishes to customize.		user wishes to customize.
	Optional attributes:		Optional attributes:
	destination transport address: some of the protocol parameters		destination transport address: some of the protocol parameters
	might be set on a per destination transport address basis.		might be set on a per-destination-transport-address basis.
	11.1.14. Receive Unsent Message		11.1.14. Receive Unsent Message
	RECEIVE_UNSENT(data retrieval id, buffer address, buffer size		RECEIVE_UNSENT(data retrieval id, buffer address, buffer size
	[,stream id] [, stream sequence number] [,partial flag]		[,stream id] [, stream sequence number] [,partial flag]
	[,payload protocol-id])		[,payload protocol-id])
	This primitive reads a user message, which has never been sent, into		This primitive reads a user message that has never been sent into the
	the buffer specified by ULP.		buffer specified by ULP.
	Mandatory attributes:		Mandatory attributes:
	data retrieval id: the identification passed to the ULP in the		data retrieval id: the identification passed to the ULP in the
	failure notification.		SEND FAILURE notification.
	buffer address: the memory location indicated by the ULP to store		buffer address: the memory location indicated by the ULP to store
	the received message.		the received message.
	buffer size: the maximum size of data to be received, in bytes.		buffer size: the maximum size of data to be received, in bytes.
	Optional attributes:		Optional attributes:
	stream id: this is a return value that is set to indicate which		stream id: this is a return value that is set to indicate which
	stream the data was sent to.		stream the data was sent to.
	stream sequence number: this value is returned indicating the		stream sequence number: this value is returned, indicating the
	Stream Sequence Number that was associated with the message.		Stream Sequence Number that was associated with the message.
	partial flag: if this returned flag is set to 1, then this		partial flag: if this returned flag is set to 1, then this
	message is a partial delivery of the whole message. When this		message is a partial delivery of the whole message. When this
	flag is set, the stream id and stream sequence number		flag is set, the stream id and stream sequence number
	accompanies this primitive. When this flag is set to 0, it		accompanies this primitive. When this flag is set to 0, it
	indicates that no more deliveries will be received for this		indicates that no more deliveries will be received for this
	stream sequence number.		stream sequence number.
	payload protocol-id: The 32 bit unsigned integer that was set to		payload protocol-id: The 32-bit unsigned integer that was set to
	be sent to the peer indicating the type of payload protocol of		be sent to the peer, indicating the type of payload protocol of
	the received data.		the received data.
	11.1.15. Receive Unacknowledged Message		11.1.15. Receive Unacknowledged Message
	RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,		RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,
	[,stream id] [,stream sequence number] [,partial flag]		[,stream id] [,stream sequence number] [,partial flag]
	[,payload protocol-id])		[,payload protocol-id])
	This primitive reads a user message, which has been sent and has not		This primitive reads a user message that has been sent and has not
	been acknowledged by the peer, into the buffer specified by ULP.		been acknowledged by the peer into the buffer specified by ULP.
	Mandatory attributes:		Mandatory attributes:
	data retrieval id: the identification passed to the ULP in the		data retrieval id: the identification passed to the ULP in the
	failure notification.		SEND FAILURE notification.
	buffer address: the memory location indicated by the ULP to store		buffer address: the memory location indicated by the ULP to store
	the received message.		the received message.
	buffer size: the maximum size of data to be received, in bytes.		buffer size: the maximum size of data to be received, in bytes.
	Optional attributes:		Optional attributes:
	stream id: this is a return value that is set to indicate which		stream id: this is a return value that is set to indicate which
	stream the data was sent to.		stream the data was sent to.
	stream sequence number: this value is returned indicating the		stream sequence number: this value is returned, indicating the
	Stream Sequence Number that was associated with the message.		Stream Sequence Number that was associated with the message.
	partial flag: if this returned flag is set to 1, then this		partial flag: if this returned flag is set to 1, then this
	message is a partial delivery of the whole message. When this		message is a partial delivery of the whole message. When this
	flag is set, the stream id and stream sequence number		flag is set, the stream id and stream sequence number
	accompanies this primitive. When this flag is set to 0, it		accompanies this primitive. When this flag is set to 0, it
	indicates that no more deliveries will be received for this		indicates that no more deliveries will be received for this
	stream sequence number.		stream sequence number.
	payload protocol-id: the 32-bit unsigned integer that was sent to		payload protocol-id: the 32-bit unsigned integer that was sent to
	skipping to change at page 128, line 23 ¶		skipping to change at line 5889 ¶
	If a message cannot be delivered, SCTP invokes this notification on		If a message cannot be delivered, SCTP invokes this notification on
	the ULP.		the ULP.
	The following might optionally be passed with the notification:		The following might optionally be passed with the notification:
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	data retrieval id: an identification used to retrieve unsent and		data retrieval id: an identification used to retrieve unsent and
	unacknowledged data.		unacknowledged data.
	mode: Indicate whether no part of the message never has been sent or		mode: indicates whether no part of the message never has been sent
	if at least part of it has been sent but it is not completely		or if at least part of it has been sent but it is not completely
	acknowledged.		acknowledged.
	cause code: indicating the reason of the failure, e.g., size too		cause code: indicating the reason of the failure, e.g., size too
	large, message life time expiration, etc.		large, message life time expiration, etc.
	context: optional information associated with this message (see		context: optional information associated with this message (see
	Section 11.1.5).		Section 11.1.5).
	11.2.3. NETWORK STATUS CHANGE Notification		11.2.3. NETWORK STATUS CHANGE Notification
	skipping to change at page 128, line 51 ¶		skipping to change at line 5917 ¶
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	destination transport address: this indicates the destination		destination transport address: this indicates the destination
	transport address of the peer endpoint affected by the change.		transport address of the peer endpoint affected by the change.
	new-status: this indicates the new status.		new-status: this indicates the new status.
	11.2.4. COMMUNICATION UP Notification		11.2.4. COMMUNICATION UP Notification
	This notification is used when SCTP becomes ready to send or receive		This notification is used when SCTP becomes ready to send or receive
	user messages, or when a lost communication to an endpoint is		user messages or when a lost communication to an endpoint is
	restored.		restored.
	Implementation Note: If the ASSOCIATE primitive is implemented as a		Implementation Note: If the ASSOCIATE primitive is implemented as a
	blocking function call, the association parameters are returned as a		blocking function call, the association parameters are returned as a
	result of the ASSOCIATE primitive itself. In that case,		result of the ASSOCIATE primitive itself. In that case, the
	COMMUNICATION UP notification is optional at the association		COMMUNICATION UP notification is optional at the association
	initiator's side.		initiator's side.
	The following is passed with the notification:		The following is passed with the notification:
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	status: This indicates what type of event has occurred.		status: this indicates what type of event has occurred.
	destination transport address list: the complete set of transport		destination transport address list: the complete set of transport
	addresses of the peer.		addresses of the peer.
	outbound stream count: the maximum number of streams allowed to be		outbound stream count: the maximum number of streams allowed to be
	used in this association by the ULP.		used in this association by the ULP.
	inbound stream count: the number of streams the peer endpoint has		inbound stream count: the number of streams the peer endpoint has
	requested with this association (this might not be the same number		requested with this association (this might not be the same number
	as 'outbound stream count').		as 'outbound stream count').
	skipping to change at page 130, line 42 ¶		skipping to change at line 6002 ¶
	association id: local handle to the SCTP association.		association id: local handle to the SCTP association.
	12. Security Considerations		12. Security Considerations
	12.1. Security Objectives		12.1. Security Objectives
	As a common transport protocol designed to reliably carry time-		As a common transport protocol designed to reliably carry time-
	sensitive user messages, such as billing or signaling messages for		sensitive user messages, such as billing or signaling messages for
	telephony services, between two networked endpoints, SCTP has the		telephony services, between two networked endpoints, SCTP has the
	following security objectives.		following security objectives:
	* availability of reliable and timely data transport services		* availability of reliable and timely data transport services
	* integrity of the user-to-user information carried by SCTP		* integrity of the user-to-user information carried by SCTP
	12.2. SCTP Responses to Potential Threats		12.2. SCTP Responses to Potential Threats
	SCTP could potentially be used in a wide variety of risk situations.		SCTP could potentially be used in a wide variety of risk situations.
	It is important for operators of systems running SCTP to analyze		It is important for operators of systems running SCTP to analyze
	their particular situations and decide on the appropriate counter-		their particular situations and decide on the appropriate counter-
	skipping to change at page 131, line 36 ¶		skipping to change at line 6039 ¶
	additional integrity protection is required. If this additional		additional integrity protection is required. If this additional
	protection were provided in the application layer, the SCTP header		protection were provided in the application layer, the SCTP header
	would remain vulnerable to deliberate integrity attacks. While the		would remain vulnerable to deliberate integrity attacks. While the
	existing SCTP mechanisms for detection of packet replays are		existing SCTP mechanisms for detection of packet replays are
	considered sufficient for normal operation, stronger protections are		considered sufficient for normal operation, stronger protections are
	needed to protect SCTP when the operating environment contains		needed to protect SCTP when the operating environment contains
	significant risk of deliberate attacks from a sophisticated		significant risk of deliberate attacks from a sophisticated
	adversary.		adversary.
	The SCTP Authentication extension SCTP-AUTH [RFC4895] MAY be used		The SCTP Authentication extension SCTP-AUTH [RFC4895] MAY be used
	when the threat environment requires stronger integrity protections,		when the threat environment requires stronger integrity protections
	but does not require confidentiality.		but does not require confidentiality.
	12.2.3. Protecting Confidentiality		12.2.3. Protecting Confidentiality
	In most cases, the risk of breach of confidentiality applies to the		In most cases, the risk of breach of confidentiality applies to the
	signaling data payload, not to the SCTP or lower-layer protocol		signaling data payload, not to the SCTP or lower-layer protocol
	overheads. If that is true, encryption of the SCTP user data only		overheads. If that is true, encryption of the SCTP user data only
	might be considered. As with the supplementary checksum service,		might be considered. As with the supplementary checksum service,
	user data encryption MAY be performed by the SCTP user application.		user data encryption MAY be performed by the SCTP user application.
	[RFC6083] MAY be used for this. Alternately, the user application		[RFC6083] MAY be used for this. Alternately, the user application
	MAY use an implementation-specific API to request that the IP		MAY use an implementation-specific API to request that the IP
	Encapsulating Security Payload (ESP) [RFC4303] be used to provide		Encapsulating Security Payload (ESP) [RFC4303] be used to provide
	confidentiality and integrity.		confidentiality and integrity.
	Particularly for mobile users, the requirement for confidentiality		Particularly for mobile users, the requirement for confidentiality
	might include the masking of IP addresses and ports. In this case,		might include the masking of IP addresses and ports. In this case,
	ESP SHOULD be used instead of application-level confidentiality. If		ESP SHOULD be used instead of application-level confidentiality. If
	ESP is used to protect confidentiality of SCTP traffic, an ESP		ESP is used to protect confidentiality of SCTP traffic, an ESP
	cryptographic transform that includes cryptographic integrity		cryptographic transform that includes cryptographic integrity
	protection MUST be used, because if there is a confidentiality threat		protection MUST be used, because, if there is a confidentiality
	there will also be a strong integrity threat.		threat, there will also be a strong integrity threat.
	Regardless of where confidentiality is provided, the Internet Key		Regardless of where confidentiality is provided, the Internet Key
	Exchange Protocol version 2 (IKEv2) [RFC7296] SHOULD be used for key		Exchange Protocol version 2 (IKEv2) [RFC7296] SHOULD be used for key
	management of ESP.		management of ESP.
	Operators might consult [RFC4301] for more information on the		Operators might consult [RFC4301] for more information on the
	security services available at and immediately above the Internet		security services available at and immediately above the Internet
	Protocol layer.		Protocol layer.
	12.2.4. Protecting against Blind Denial-of-Service Attacks		12.2.4. Protecting against Blind Denial-of-Service Attacks
	skipping to change at page 133, line 7 ¶		skipping to change at line 6105 ¶
	acceptance of new work.		acceptance of new work.
	* identification and removal of duplicate or stale queued requests		* identification and removal of duplicate or stale queued requests
	for service.		for service.
	* not responding to unexpected packets sent to non-unicast		* not responding to unexpected packets sent to non-unicast
	addresses.		addresses.
	Network equipment is expected to be capable of generating an alarm		Network equipment is expected to be capable of generating an alarm
	and log if a suspicious increase in traffic occurs. The log provides		and log if a suspicious increase in traffic occurs. The log provides
	information such as the identity of the incoming link and source		information, such as the identity of the incoming link and source
	address(es) used, which will help the network or SCTP system operator		address(es) used, which will help the network or SCTP system operator
	to take protective measures. Procedures are expected to be in place		to take protective measures. Procedures are expected to be in place
	for the operator to act on such alarms if a clear pattern of abuse		for the operator to act on such alarms if a clear pattern of abuse
	emerges.		emerges.
	The design of SCTP is resistant to flooding attacks, particularly in		The design of SCTP is resistant to flooding attacks, particularly in
	its use of a four-way startup handshake, its use of a cookie to defer		its use of a four-way startup handshake, its use of a cookie to defer
	commitment of resources at the responding SCTP node until the		commitment of resources at the responding SCTP node until the
	handshake is completed, and its use of a Verification Tag to prevent		handshake is completed, and its use of a Verification Tag to prevent
	insertion of extraneous packets into the flow of an established		insertion of extraneous packets into the flow of an established
	skipping to change at page 133, line 49 ¶		skipping to change at line 6147 ¶
	* by deliberately allowing the impersonation to be detected, thereby		* by deliberately allowing the impersonation to be detected, thereby
	provoking counter-measures that cause the impersonated node to be		provoking counter-measures that cause the impersonated node to be
	locked out of the target SCTP node.		locked out of the target SCTP node.
	* by interfering with an established association by inserting		* by interfering with an established association by inserting
	extraneous content such as a SHUTDOWN chunk.		extraneous content such as a SHUTDOWN chunk.
	SCTP reduces the risk of blind masquerade attacks through IP spoofing		SCTP reduces the risk of blind masquerade attacks through IP spoofing
	by use of the four-way startup handshake. Because the initial		by use of the four-way startup handshake. Because the initial
	exchange is memory-less, no lockout mechanism is triggered by blind		exchange is memoryless, no lockout mechanism is triggered by blind
	masquerade attacks. In addition, the packet containing the INIT ACK		masquerade attacks. In addition, the packet containing the INIT ACK
	chunk with the State Cookie is transmitted back to the IP address		chunk with the State Cookie is transmitted back to the IP address
	from which it received the packet containing the INIT chunk. Thus,		from which it received the packet containing the INIT chunk. Thus,
	the attacker would not receive the INIT ACK chunk containing the		the attacker would not receive the INIT ACK chunk containing the
	State Cookie. SCTP protects against insertion of extraneous packets		State Cookie. SCTP protects against insertion of extraneous packets
	into the flow of an established association by use of the		into the flow of an established association by use of the
	Verification Tag.		Verification Tag.
	Logging of received INIT chunks and abnormalities such as unexpected		Logging of received INIT chunks and abnormalities, such as unexpected
	INIT ACK chunks might be considered as a way to detect patterns of		INIT ACK chunks, might be considered as a way to detect patterns of
	hostile activity. However, the potential usefulness of such logging		hostile activity. However, the potential usefulness of such logging
	has to be weighed against the increased SCTP startup processing it		has to be weighed against the increased SCTP startup processing it
	implies, rendering the SCTP node more vulnerable to flooding attacks.		implies, rendering the SCTP node more vulnerable to flooding attacks.
	Logging is pointless without the establishment of operating		Logging is pointless without the establishment of operating
	procedures to review and analyze the logs on a routine basis.		procedures to review and analyze the logs on a routine basis.
	12.2.4.3. Improper Monopolization of Services		12.2.4.3. Improper Monopolization of Services
	Attacks under this heading are performed openly and legitimately by		Attacks under this heading are performed openly and legitimately by
	the attacker. They are directed against fellow users of the target		the attacker. They are directed against fellow users of the target
	SCTP node or of the shared resources between the attacker and the		SCTP node or of the shared resources between the attacker and the
	target node. Possible attacks include the opening of a large number		target node. Possible attacks include the opening of a large number
	of associations between the attacker's node and the target, or		of associations between the attacker's node and the target or
	transfer of large volumes of information within a legitimately		transfer of large volumes of information within a legitimately
	established association.		established association.
	Policy limits are expected to be placed on the number of associations		Policy limits are expected to be placed on the number of associations
	per adjoining SCTP node. SCTP user applications are expected to be		per adjoining SCTP node. SCTP user applications are expected to be
	capable of detecting large volumes of illegitimate or "no-op"		capable of detecting large volumes of illegitimate or "no-op"
	messages within a given association and either logging or terminating		messages within a given association and either logging or terminating
	the association as a result, based on local policy.		the association as a result, based on local policy.
	12.3. SCTP Interactions with Firewalls		12.3. SCTP Interactions with Firewalls
	skipping to change at page 134, line 46 ¶		skipping to change at line 6193 ¶
	fragment of a fragmented SCTP packet and unambiguously determine		fragment of a fragmented SCTP packet and unambiguously determine
	whether it corresponds to an INIT chunk (for further information,		whether it corresponds to an INIT chunk (for further information,
	please refer to [RFC1858]). Accordingly, we stress the requirements,		please refer to [RFC1858]). Accordingly, we stress the requirements,
	as stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled		as stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
	with any other chunk in a packet and (2) a packet containing an INIT		with any other chunk in a packet and (2) a packet containing an INIT
	chunk MUST have a zero Verification Tag. The receiver of an INIT		chunk MUST have a zero Verification Tag. The receiver of an INIT
	chunk MUST silently discard the INIT chunk and all further chunks if		chunk MUST silently discard the INIT chunk and all further chunks if
	the INIT chunk is bundled with other chunks or the packet has a non-		the INIT chunk is bundled with other chunks or the packet has a non-
	zero Verification Tag.		zero Verification Tag.
	12.4. Protection of Non-SCTP-Capable Hosts		12.4. Protection of Non-SCTP-capable Hosts
	To provide a non-SCTP-capable host with the same level of protection		To provide a non-SCTP-capable host with the same level of protection
	against attacks as for SCTP-capable ones, all SCTP implementations		against attacks as for SCTP-capable ones, all SCTP implementations
	MUST implement the ICMP handling described in Section 10.		MUST implement the ICMP handling described in Section 10.
	When an SCTP implementation receives a packet containing multiple		When an SCTP implementation receives a packet containing multiple
	control or DATA chunks and the processing of the packet would result		control or DATA chunks and the processing of the packet would result
	in sending multiple chunks in response, the sender of the response		in sending multiple chunks in response, the sender of the response
	chunk(s) MUST NOT send more than one packet containing chunks other		chunk(s) MUST NOT send more than one packet containing chunks other
	than DATA chunks. This requirement protects the network for		than DATA chunks. This requirement protects the network for
	triggering a packet burst in response to a single packet. If		triggering a packet burst in response to a single packet. If
	bundling is supported, multiple response chunks that fit into a		bundling is supported, multiple response chunks that fit into a
	single packet MAY be bundled together into one single response		single packet MAY be bundled together into one single response
	packet. If bundling is not supported, then the sender MUST NOT send		packet. If bundling is not supported, then the sender MUST NOT send
	more than one response chunk and MUST discard all other responses.		more than one response chunk and MUST discard all other responses.
	Note that this rule does not apply to a SACK chunk, since a SACK		Note that this rule does not apply to a SACK chunk, since a SACK
	chunk is, in itself, a response to DATA chunks and a SACK chunk does		chunk is, in itself, a response to DATA chunks, and a SACK chunk does
	not require a response of more DATA chunks.		not require a response of more DATA chunks.
	An SCTP implementation MUST abort the association if it receives a		An SCTP implementation MUST abort the association if it receives a
	SACK chunk acknowledging a TSN that has not been sent.		SACK chunk acknowledging a TSN that has not been sent.
	An SCTP implementation that receives an INIT chunk that would require		An SCTP implementation that receives an INIT chunk that would require
	a large packet in response, due to the inclusion of multiple		a large packet in response, due to the inclusion of multiple
	"Unrecognized Parameter" parameters, MAY (at its discretion) elect to		"Unrecognized Parameter" parameters, MAY (at its discretion) elect to
	omit some or all of the "Unrecognized Parameter" parameters to reduce		omit some or all of the "Unrecognized Parameter" parameters to reduce
	the size of the INIT ACK chunk. Due to a combination of the size of		the size of the INIT ACK chunk. Due to a combination of the size of
	skipping to change at page 136, line 4 ¶		skipping to change at line 6244 ¶
	This section details a set of parameters that are expected to be		This section details a set of parameters that are expected to be
	contained within the TCB for an implementation. This section is for		contained within the TCB for an implementation. This section is for
	illustrative purposes and is not considered to be requirements on an		illustrative purposes and is not considered to be requirements on an
	implementation or as an exhaustive list of all parameters inside an		implementation or as an exhaustive list of all parameters inside an
	SCTP TCB. Each implementation might need its own additional		SCTP TCB. Each implementation might need its own additional
	parameters for optimization.		parameters for optimization.
	14.1. Parameters Necessary for the SCTP Instance		14.1. Parameters Necessary for the SCTP Instance
	Associations: A list of current associations and mappings to the		Associations: A list of current associations and mappings to the
	data consumers for each association. This might be in the form of		data consumers for each association. This might be in
	a hash table or other implementation-dependent structure. The		the form of a hash table or other implementation-
	data consumers might be process identification information such as		dependent structure. The data consumers might be
	file descriptors, named pipe pointer, or table pointers dependent		process identification information, such as file
	on how SCTP is implemented.		descriptors, named pipe pointer, or table pointers
			dependent on how SCTP is implemented.
	Secret Key: A secret key used by this endpoint to compute the MAC.		Secret Key: A secret key used by this endpoint to compute the MAC.
	This SHOULD be a cryptographic quality random number with a		This SHOULD be a cryptographic quality random number
	sufficient length. Discussion in [RFC4086] can be helpful in		with a sufficient length. Discussion in [RFC4086] can
	selection of the key.		be helpful in selection of the key.
	Address List: The list of IP addresses that this instance has bound.		Address List: The list of IP addresses that this instance has bound.
	This information is passed to one's peer(s) in INIT and INIT ACK		This information is passed to one's peer(s) in INIT
	chunks.		and INIT ACK chunks.
	SCTP Port: The local SCTP port number to which the endpoint is		SCTP Port: The local SCTP port number to which the endpoint is
	bound.		bound.
	14.2. Parameters Necessary per Association (i.e., the TCB)		14.2. Parameters Necessary per Association (i.e., the TCB)
	Peer Verification Tag: Tag value to be sent in every packet and is		Peer Verification Tag: Tag value to be sent in every packet and is
	received in the INIT or INIT ACK chunk.		received in the INIT or INIT ACK chunk.
	My Verification Tag: Tag expected in every inbound packet and sent		My Verification Tag: Tag expected in every inbound packet and sent
	in the INIT or INIT ACK chunk.		in the INIT or INIT ACK chunk.
	State: COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, SHUTDOWN-PENDING,		State: COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, SHUTDOWN-
	SHUTDOWN-SENT, SHUTDOWN-RECEIVED, SHUTDOWN-ACK-SENT.		PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, SHUTDOWN-
			ACK-SENT.
	Note: No "CLOSED" state is illustrated since if a association is		Note: No "CLOSED" state is illustrated, since, if an
	"CLOSED" its TCB SHOULD be removed.		association is "CLOSED", its TCB SHOULD be removed.
	Peer Transport Address List: A list of SCTP transport addresses to		Peer Transport Address List: A list of SCTP transport addresses to
	which the peer is bound. This information is derived from the		which the peer is bound. This information is derived
	INIT or INIT ACK chunk and is used to associate an inbound packet		from the INIT or INIT ACK chunk and is used to
	with a given association. Normally, this information is hashed or		associate an inbound packet with a given association.
	keyed for quick lookup and access of the TCB.		Normally, this information is hashed or keyed for
			quick lookup and access of the TCB.
	Primary Path: This is the current primary destination transport		Primary Path: This is the current primary destination transport
	address of the peer endpoint. It might also specify a source		address of the peer endpoint. It might also specify a
	transport address on this endpoint.		source transport address on this endpoint.
	Overall Error Count: The overall association error count.		Overall Error Count: The overall association error count.
	Overall Error Threshold: The threshold for this association that if		Overall Error Threshold: The threshold for this association that, if
	the Overall Error Count reaches will cause this association to be		the Overall Error Count reaches, will cause this
	torn down.		association to be torn down.
	Peer Rwnd: Current calculated value of the peer's rwnd.		Peer Rwnd: Current calculated value of the peer's rwnd.
	Next TSN: The next TSN number to be assigned to a new DATA chunk.		Next TSN: The next TSN number to be assigned to a new DATA
	This is sent in the INIT or INIT ACK chunk to the peer and		chunk. This is sent in the INIT or INIT ACK chunk to
	incremented each time a DATA chunk is assigned a TSN (normally		the peer and incremented each time a DATA chunk is
	just prior to transmit or during fragmentation).		assigned a TSN (normally, just prior to transmit or
			during fragmentation).
	Last Rcvd TSN: This is the last TSN received in sequence. This		Last Rcvd TSN: This is the last TSN received in sequence. This
	value is set initially by taking the peer's initial TSN, received		value is set initially by taking the peer's Initial
	in the INIT or INIT ACK chunk, and subtracting one from it.		TSN, received in the INIT or INIT ACK chunk, and
			subtracting one from it.
	Mapping Array: An array of bits or bytes indicating which out-of-		Mapping Array: An array of bits or bytes indicating which out-of-
	order TSNs have been received (relative to the Last Rcvd TSN). If		order TSNs have been received (relative to the Last
	no gaps exist, i.e., no out-of-order packets have been received,		Rcvd TSN). If no gaps exist, i.e., no out-of-order
	this array will be set to all zero. This structure might be in		packets have been received, this array will be set to
	the form of a circular buffer or bit array.		all zero. This structure might be in the form of a
			circular buffer or bit array.
	Ack State: This flag indicates if the next received packet is to be		Ack State: This flag indicates if the next received packet is to
	responded to with a SACK chunk. This is initialized to 0. When a		be responded to with a SACK chunk. This is
	packet is received it is incremented. If this value reaches 2 or		initialized to 0. When a packet is received, it is
	more, a SACK chunk is sent and the value is reset to 0. Note:		incremented. If this value reaches 2 or more, a SACK
	This is used only when no DATA chunks are received out of order.		chunk is sent and the value is reset to 0. Note: This
	When DATA chunks are out of order, SACK chunks are not delayed		is used only when no DATA chunks are received out of
	(see Section 6).		order. When DATA chunks are out of order, SACK chunks
			are not delayed (see Section 6).
	Inbound Streams: An array of structures to track the inbound		Inbound Streams: An array of structures to track the inbound
	streams, normally including the next sequence number expected and		streams, normally including the next sequence number
	possibly the stream number.		expected and possibly the stream number.
	Outbound Streams: An array of structures to track the outbound		Outbound Streams: An array of structures to track the outbound
	streams, normally including the next sequence number to be sent on		streams, normally including the next sequence number
	the stream.		to be sent on the stream.
	Reasm Queue: A reassembly queue.		Reasm Queue: A reassembly queue.
	Receive Buffer: A buffer to store received user data which has not		Receive Buffer: A buffer to store received user data that has not
	been delivered to the upper layer.		been delivered to the upper layer.
	Local Transport Address List: The list of local IP addresses bound		Local Transport Address List: The list of local IP addresses bound
	in to this association.		in to this association.
	Association Maximum DATA Chunk Size: The smallest Path Maximum DATA		Association Maximum DATA Chunk Size: The smallest Path Maximum DATA
	Chunk Size of all destination addresses.		Chunk Size of all destination addresses.
	14.3. Per Transport Address Data		14.3. Per Transport Address Data
	For each destination transport address in the peer's address list		For each destination transport address in the peer's address list
	derived from the INIT or INIT ACK chunk, a number of data elements		derived from the INIT or INIT ACK chunk, a number of data elements
	need to be maintained including:		need to be maintained, including:
	Error Count: The current error count for this destination.		Error Count: The current error count for this destination.
	Error Threshold: Current error threshold for this destination, i.e.,		Error Threshold: Current error threshold for this destination, i.e.,
	what value marks the destination down if error count reaches this		what value marks the destination down if error count
	value.		reaches this value.
	cwnd: The current congestion window.		cwnd: The current congestion window.
	ssthresh: The current ssthresh value.		ssthresh: The current ssthresh value.
	RTO: The current retransmission timeout value.		RTO: The current retransmission timeout value.
	SRTT: The current smoothed round-trip time.		SRTT: The current smoothed round-trip time.
	RTTVAR: The current RTT variation.		RTTVAR: The current RTT variation.
	partial bytes acked: The tracking method for increase of cwnd when		partial bytes acked: The tracking method for increase of cwnd when
	in congestion avoidance mode (see Section 7.2.2).		in congestion avoidance mode (see Section 7.2.2).
	state: The current state of this destination, i.e., DOWN, UP, ALLOW-		state: The current state of this destination, i.e., DOWN, UP,
	HEARTBEAT, NO-HEARTBEAT, etc.		ALLOW-HEARTBEAT, NO-HEARTBEAT, etc.
	PMTU: The current known PMTU.		PMTU: The current known PMTU.
	PMDCS: The current known PMDCS.		PMDCS: The current known PMDCS.
	Per Destination Timer: A timer used by each destination.		Per Destination Timer: A timer used by each destination.
	RTO-Pending: A flag used to track if one of the DATA chunks sent to		RTO-Pending: A flag used to track if one of the DATA chunks sent to
	this address is currently being used to compute an RTT. If this		this address is currently being used to compute an
	flag is 0, the next DATA chunk sent to this destination is		RTT. If this flag is 0, the next DATA chunk sent to
	expected to be used to compute an RTT and this flag is expected to		this destination is expected to be used to compute an
	be set. Every time the RTT calculation completes (i.e., the DATA		RTT and this flag is expected to be set. Every time
	chunk is acknowledged), clear this flag.		the RTT calculation completes (i.e., the DATA chunk is
			acknowledged), clear this flag.
	last-time: The time to which this destination was last sent. This		last-time: The time to which this destination was last sent.
	can used be to determine if the sending of a HEARTBEAT chunk is		This can be used to determine if the sending of a
	needed.		HEARTBEAT chunk is needed.
	14.4. General Parameters Needed		14.4. General Parameters Needed
	Out Queue: A queue of outbound DATA chunks.		Out Queue: A queue of outbound DATA chunks.
	In Queue: A queue of inbound DATA chunks.		In Queue: A queue of inbound DATA chunks.
	15. IANA Considerations		15. IANA Considerations
	This document defines five registries that IANA maintains:		This document defines five registries that IANA maintains:
	skipping to change at page 139, line 26 ¶		skipping to change at line 6410 ¶
	* through definition of additional chunk flags,		* through definition of additional chunk flags,
	* through definition of additional parameter types,		* through definition of additional parameter types,
	* through definition of additional cause codes within ERROR chunks,		* through definition of additional cause codes within ERROR chunks,
	or		or
	* through definition of additional payload protocol identifiers.		* through definition of additional payload protocol identifiers.
	IANA is requested to perform the following updates for the above five		IANA has performed the following updates for the above five
	registries:		registries:
	* In the Chunk Types Registry replace in the Reference section the		* In the "Chunk Types" registry, IANA has replaced the registry
	reference to [RFC4960] and [RFC6096] by a reference to this		reference to [RFC4960] and [RFC6096] with a reference to this
	document.		document.
	Replace in the Notes section the reference to Section 3.2 of		In addition, in the Notes section, the reference to Section 3.2 of
	[RFC6096] by a reference to Section 15.2 of this document.		[RFC6096] has been updated with a reference to Section 15.2 of
			this document.
	Finally replace each reference to [RFC4960] by a reference to this		Finally, each reference to [RFC4960] has been replaced with a
	document for the following chunk types:		reference to this document for the following chunk types:
	- Payload Data (DATA)		- Payload Data (DATA)
	- Initiation (INIT)		- Initiation (INIT)
	- Initiation Acknowledgement (INIT ACK)		- Initiation Acknowledgement (INIT ACK)
	- Selective Acknowledgement (SACK)		- Selective Acknowledgement (SACK)
	- Heartbeat Request (HEARTBEAT)		- Heartbeat Request (HEARTBEAT)
	skipping to change at page 140, line 4 ¶		skipping to change at line 6437 ¶
	- Initiation Acknowledgement (INIT ACK)		- Initiation Acknowledgement (INIT ACK)
	- Selective Acknowledgement (SACK)		- Selective Acknowledgement (SACK)
	- Heartbeat Request (HEARTBEAT)		- Heartbeat Request (HEARTBEAT)
	- Heartbeat Acknowledgement (HEARTBEAT ACK)		- Heartbeat Acknowledgement (HEARTBEAT ACK)
	- Abort (ABORT)		- Abort (ABORT)
	- Shutdown (SHUTDOWN)		- Shutdown (SHUTDOWN)
	- Shutdown Acknowledgement (SHUTDOWN ACK)		- Shutdown Acknowledgement (SHUTDOWN ACK)
	- Operation Error (ERROR)		- Operation Error (ERROR)
	- State Cookie (COOKIE ECHO)		- State Cookie (COOKIE ECHO)
	- Cookie Acknowledgement (COOKIE ACK)		- Cookie Acknowledgement (COOKIE ACK)
	- Reserved for Explicit Congestion Notification Echo (ECNE)		- Reserved for Explicit Congestion Notification Echo (ECNE)
	- Reserved for Congestion Window Reduced (CWR)		- Reserved for Congestion Window Reduced (CWR)
	- Shutdown Complete (SHUTDOWN COMPLETE)		- Shutdown Complete (SHUTDOWN COMPLETE)
	- Reserved for IETF-defined Chunk Extensions		- Reserved for IETF-defined Chunk Extensions
	* In the Chunk Parameter Types Registry replace in the Reference		* In the "Chunk Parameter Types" registry, IANA has replaced the
	section the reference to [RFC4960] by a reference to this		registry reference to [RFC4960] with a reference to this document.
	document.
	Replace each reference to [RFC4960] by a reference to this		IANA has changed the name of the "Unrecognized Parameters" chunk
	document for the following chunk parameter types:		parameter type to "Unrecognized Parameter" in the "Chunk Parameter
			Types" registry.
			In addition, each reference to [RFC4960] has been replaced with a
			reference to this document for the following chunk parameter
			types:
	- Heartbeat Info		- Heartbeat Info
	- IPv4 Address		- IPv4 Address
	- IPv6 Address		- IPv6 Address
	- State Cookie		- State Cookie
	- Unrecognized Parameters		- Unrecognized Parameter
	- Cookie Preservative		- Cookie Preservative
	- Host Name Address		- Host Name Address
	- Supported Address Types		- Supported Address Types
	Add a reference to this document for the following chunk parameter		IANA has added a reference to this document for the following
	type:		chunk parameter type:
	- Reserved for ECN Capable (0x8000)		- Reserved for ECN Capable (0x8000)
	* In the Chunk Flags Registry replace in the Reference section the		Also, IANA has added the value 65535 to be reserved for IETF-
	reference to [RFC6096] by a reference to this document.		defined extensions.
	Replace each reference to [RFC4960] by a reference to this		* In the "Chunk Flags" registry, IANA replaced the registry
	document for the following DATA chunk flags:		reference to [RFC6096] with a reference to this document.
			In addition, each reference to [RFC4960] has been replaced with a
			reference to this document for the following DATA chunk flags:
	- E bit		- E bit
	- B bit		- B bit
	- U bit		- U bit
	Replace each reference to [RFC4960] by a reference to this		IANA has also replaced the reference to [RFC7053] with a reference
	document for the following ABORT chunk flags:		to this document for the following DATA chunk flag:
			- I bit
			IANA has replaced the reference to [RFC4960] with a reference to
			this document for the following ABORT chunk flag:
	- T bit		- T bit
	Replace each reference to [RFC4960] by a reference to this		IANA has replaced the reference to [RFC4960] with a reference to
	document for the following SHUTDOWN COMPLETE chunk flags:		this document for the following SHUTDOWN COMPLETE chunk flag:
	- T bit		- T bit
	* In the Error Cause Codes Registry replace in the Reference section		* In the "Error Cause Codes" registry, IANA has replaced the
	the reference to [RFC6096] by a reference to this document.		registry reference to [RFC4960] with a reference to this document.
	Replace each reference to [RFC4960] by a reference to this		IANA has changed the name of the "User Initiated Abort" error
	document for the following cause codes:		cause to "User-Initiated Abort" and the name of the "Stale Cookie
			Error" error cause to "Stale Cookie" in the "Error Cause Codes"
			registry.
			In addition, each reference to [RFC4960] has been replaced with a
			reference to this document for the following cause codes:
	- Invalid Stream Identifier		- Invalid Stream Identifier
	- Missing Mandatory Parameter		- Missing Mandatory Parameter
	- Stale Cookie Error		- Stale Cookie
	- Out of Resource		- Out of Resource
	- Unresolvable Address		- Unresolvable Address
	- Unrecognized Chunk Type		- Unrecognized Chunk Type
	- Invalid Mandatory Parameter		- Invalid Mandatory Parameter
	- Unrecognized Parameters		- Unrecognized Parameters
	- No User Data		- No User Data
	- Cookie Received While Shutting Down		- Cookie Received While Shutting Down
	- Restart of an Association with New Addressess		- Restart of an Association with New Addresses
	Replace each reference to [RFC4460] by a reference to this
	document for the following cause codes:
	- User Initiated Abort		IANA has also replaced each reference to [RFC4460] with a
			reference to this document for the following cause codes:
			- User-Initiated Abort
	- Protocol Violation		- Protocol Violation
	* In the SCTP Payload Protocol Identifiers Registry replace in the		* In the "SCTP Payload Protocol Identifiers" registry, IANA has
	Reference section the reference to [RFC6096] by a reference to		replaced the registry reference to [RFC4960] with a reference to
	this document.		this document.
	Replace each reference to [RFC4960] by a reference to this		IANA has replaced the reference to [RFC4960] with a reference to
	document for the following SCTP payload protocol identifiers:		this document for the following SCTP payload protocol identifier:
	- Reserved by SCTP		- Reserved by SCTP
	SCTP requires that the IANA Port Numbers registry be opened for SCTP		SCTP requires that the IANA "Port Numbers" registry be opened for
	port registrations, Section 15.6 describes how. An IESG-appointed		SCTP port registrations; Section 15.6 describes how. An IESG-
	Expert Reviewer supports IANA in evaluating SCTP port allocation		appointed Expert Reviewer supports IANA in evaluating SCTP port
	requests.		allocation requests.
	IANA is requested to perform the following update for the Port Number		In the "Service Name and Transport Protocol Port Number Registry",
	registry. Replace each reference to [RFC4960] by a reference to this		IANA has replaced each reference to [RFC4960] with a reference to
	document for the following SCTP port numbers:		this document for the following SCTP port numbers:
	* 9 (discard)		* 9 (discard)
	* 20 (ftp-data)		* 20 (ftp-data)
	* 21 (ftp)		* 21 (ftp)
	* 22 (ssh)		* 22 (ssh)
	* 80 (http)		* 80 (http)
	* 179 (bgp)		* 179 (bgp)
	* 443 (https)		* 443 (https)
	Furthermore, IANA is requested to replace in the HTTP Digest		Furthermore, in the "Hypertext Transfer Protocol (HTTP) Digest
	Algorithm Values registry the reference to Appendix B of [RFC4960] to		Algorithm Values" registry, IANA has replaced the reference to
	Appendix A of this document.		Appendix B of [RFC4960] with a reference to Appendix A of this
			document.
	IANA is also requested to replace in the ONC RPC Netids registry,		In addition, in the "ONC RPC Netids (Standards Action)" registry,
	each of the reference to [RFC4960] by a reference to this document		IANA has replaced each reference to [RFC4960] with a reference to
	for the following netids:		this document for the following netids:
	* sctp		* sctp
	* sctp6		* sctp6
	IANA is finally requested to replace in the IPFIX Information		In the "IPFIX Information Elements" registry, IANA has replaced each
	Elements registry, each of the reference to [RFC4960] by a reference		reference to [RFC4960] with a reference to this document for the
	to this document for the following elements with the name:		following elements with the name:
	* sourceTransportPort		* sourceTransportPort
	* destinationTransportPort		* destinationTransportPort
	* collectorTransportPort		* collectorTransportPort
	* exporterTransportPort		* exporterTransportPort
	* postNAPTSourceTransportPort		* postNAPTSourceTransportPort
	skipping to change at page 144, line 5 ¶		skipping to change at line 6645 ¶
	d) A detailed procedural description of the use of the new chunk		d) A detailed procedural description of the use of the new chunk
	type within the operation of the protocol.		type within the operation of the protocol.
	The last chunk type (255) is reserved for future extension if		The last chunk type (255) is reserved for future extension if
	necessary.		necessary.
	For each new chunk type, IANA creates a registration table for the		For each new chunk type, IANA creates a registration table for the
	chunk flags of that type. The procedure for registering particular		chunk flags of that type. The procedure for registering particular
	chunk flags is described in Section 15.2.		chunk flags is described in Section 15.2.
	15.2. IETF Chunk Flags Registration		15.2. IETF-Defined Chunk Flags Registration
	The assignment of new chunk flags is done through an RFC Required		The assignment of new chunk flags is done through an RFC Required
	action, as defined in [RFC8126]. Documentation for the chunk flags		action, as defined in [RFC8126]. Documentation for the chunk flags
	MUST contain the following information:		MUST contain the following information:
	a) A name for the new chunk flag.		a) A name for the new chunk flag.
	b) A detailed procedural description of the use of the new chunk		b) A detailed procedural description of the use of the new chunk
	flag within the operation of the protocol. It MUST be considered		flag within the operation of the protocol. It MUST be considered
	that implementations not supporting the flag will send 0 on		that implementations not supporting the flag will send 0 on
	transmit and just ignore it on receipt.		transmit and just ignore it on receipt.
	IANA selects a chunk flags value. This MUST be one of 0x01, 0x02,		IANA selects a chunk flags value. This MUST be one of 0x01, 0x02,
	0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within		0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within
	the chunk flag values for the specific chunk type.		the chunk flag values for the specific chunk type.
	15.3. IETF-Defined Chunk Parameter Extension		15.3. IETF-Defined Chunk Parameter Extension
	The assignment of new chunk parameter type codes is done through an		The assignment of new chunk parameter type codes is done through an
	IETF Review action as defined in [RFC8126]. Documentation of the		IETF Review action, as defined in [RFC8126]. Documentation of the
	chunk parameter MUST contain the following information:		chunk parameter MUST contain the following information:
	a) Name of the parameter type.		a) Name of the parameter type.
	b) Detailed description of the structure of the parameter field.		b) Detailed description of the structure of the parameter field.
	This structure MUST conform to the general Type-Length-Value		This structure MUST conform to the general Type-Length-Value
	format described in Section 3.2.1.		format described in Section 3.2.1.
	c) Detailed definition of each component of the parameter value.		c) Detailed definition of each component of the parameter value.
	d) Detailed description of the intended use of this parameter type,		d) Detailed description of the intended use of this parameter type
	and an indication of whether and under what circumstances		and an indication of whether and under what circumstances
	multiple instances of this parameter type can be found within the		multiple instances of this parameter type can be found within the
	same chunk.		same chunk.
	e) Each parameter type MUST be unique across all chunks.		e) Each parameter type MUST be unique across all chunks.
	15.4. IETF-Defined Additional Error Causes		15.4. IETF-Defined Additional Error Causes
	Additional cause codes can be allocated in the range 11 to 65535		Additional cause codes can be allocated through a Specification
	through a Specification Required action as defined in [RFC8126].		Required action as defined in [RFC8126]. Provided documentation MUST
	Provided documentation MUST include the following information:		include the following information:
	a) Name of the error condition.		a) Name of the error condition.
	b) Detailed description of the conditions under which an SCTP		b) Detailed description of the conditions under which an SCTP
	endpoint issues an ERROR (or ABORT) chunk with this cause code.		endpoint issues an ERROR (or ABORT) chunk with this cause code.
	c) Expected action by the SCTP endpoint that receives an ERROR (or		c) Expected action by the SCTP endpoint that receives an ERROR (or
	ABORT) chunk containing this cause code.		ABORT) chunk containing this cause code.
	d) Detailed description of the structure and content of data fields		d) Detailed description of the structure and content of data fields
	that accompany this cause code.		that accompany this cause code.
	The initial word (32 bits) of a cause code parameter MUST conform to		The initial word (32 bits) of a cause code parameter MUST conform to
	the format shown in Section 3.3.10, i.e.:		the format shown in Section 3.3.10, that is:
	* first 2 bytes contain the cause code value		* first 2 bytes contain the cause code value
	* last 2 bytes contain the length of the cause parameter.		* last 2 bytes contain the length of the error cause.
	15.5. Payload Protocol Identifiers		15.5. Payload Protocol Identifiers
	The assignment of payload protocol identifier is done using the First		The assignment of payload protocol identifiers is done using the
	Come First Served policy as defined in [RFC8126].		First Come First Served policy, as defined in [RFC8126].
	Except for value 0, which is reserved to indicate an unspecified		Except for value 0, which is reserved to indicate an unspecified
	payload protocol identifier in a DATA chunk, an SCTP implementation		payload protocol identifier in a DATA chunk, an SCTP implementation
	will not be responsible for standardizing or verifying any payload		will not be responsible for standardizing or verifying any payload
	protocol identifiers; An SCTP implementation simply receives the		protocol identifiers. An SCTP implementation simply receives the
	identifier from the upper layer and carries it with the corresponding		identifier from the upper layer and carries it with the corresponding
	payload data.		payload data.
	The upper layer, i.e., the SCTP user, SHOULD standardize any specific		The upper layer, i.e., the SCTP user, SHOULD standardize any specific
	protocol identifier with IANA if it is so desired. The use of any		protocol identifier with IANA if it is so desired. The use of any
	specific payload protocol identifier is out of the scope of this		specific payload protocol identifier is out of the scope of this
	specification.		specification.
	15.6. Port Numbers Registry		15.6. Port Numbers Registry
	SCTP services can use contact port numbers to provide service to		SCTP services can use contact port numbers to provide service to
	unknown callers, as in TCP and UDP. An IESG-appointed expert		unknown callers, as in TCP and UDP. An IESG-appointed Expert
	reviewer supports IANA in evaluating SCTP port allocation requests,		Reviewer supports IANA in evaluating SCTP port allocation requests,
	according to the procedure defined in [RFC8126]. The details of this		according to the procedure defined in [RFC8126]. The details of this
	process are defined in [RFC6335].		process are defined in [RFC6335].
	16. Suggested SCTP Protocol Parameter Values		16. Suggested SCTP Protocol Parameter Values
	The following protocol parameters are RECOMMENDED:		The following protocol parameters are RECOMMENDED:
	RTO.Initial: 1 second		RTO.Initial: 1 second
	RTO.Min: 1 second		RTO.Min: 1 second
	RTO.Max: 60 seconds		RTO.Max: 60 seconds
	Max.Burst: 4		Max.Burst: 4
	RTO.Alpha: 1/8		RTO.Alpha: 1/8
	RTO.Beta: 1/4		RTO.Beta: 1/4
	Valid.Cookie.Life: 60 seconds		Valid.Cookie.Life: 60 seconds
	Association.Max.Retrans: 10 attempts		Association.Max.Retrans: 10 attempts
	Path.Max.Retrans: 5 attempts (per destination address)		Path.Max.Retrans: 5 attempts (per destination address)
	Max.Init.Retransmits: 8 attempts		Max.Init.Retransmits: 8 attempts
	HB.interval: 30 seconds		HB.interval: 30 seconds
	HB.Max.Burst: 1		HB.Max.Burst: 1
	SACK.Delay: 200 milliseconds		SACK.Delay: 200 milliseconds
	Implementation Note: The SCTP implementation can allow ULP to		Implementation Note: The SCTP implementation can allow ULP to
	customize some of these protocol parameters (see Section 11).		customize some of these protocol parameters (see Section 11).
	'RTO.Min' SHOULD be set as described above in this section.		'RTO.Min' SHOULD be set as described above in this section.
	17. Acknowledgements		17. References
	An undertaking represented by this updated document is not a small
	feat and represents the summation of the initial co-authors of
	[RFC2960]: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
	T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson.
	Add to that, the comments from everyone who contributed to [RFC2960]:
	Mark Allman, R. J. Atkinson, Richard Band, Scott Bradner, Steve
	Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally
	Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian
	Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney,
	Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon
	Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme,
	Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg
	Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their
	invaluable comments.
	Then, add the co-authors of [RFC4460]: I. Arias-Rodriguez, K. Poon,
	and A. Caro.
	Then add to these the efforts of all the subsequent seven SCTP
	interoperability tests and those who commented on [RFC4460] as shown
	in its acknowledgements: Barry Zuckerman, La Monte Yarroll, Qiaobing
	Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John
	Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki,
	Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian
	Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner,
	Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan
	McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David
	Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller,
	Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie,
	John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim,
	Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve
	Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
	Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
	Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
	A special thanks to Mark Allman, who should actually be a co-author
	for his work on the max-burst, but managed to wiggle out due to a
	technicality.
	Also, we would like to acknowledge Lyndon Ong and Phil Conrad for
	their valuable input and many contributions.
	Furthermore, you have [RFC4960], and those who have commented upon
	that including Alfred Hönes and Ronnie Sellars.
	Then, add the co-author of [RFC8540]: Maksim Proshin.
	And people who have commented on [RFC8540]: Pontus Andersson, Eric
	W. Biederman, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst,
	Benjamin Kaduk, Mirja Kühlewind, Peter Lei, Gyula Marosi, Lionel
	Morand, Jeff Morriss, Tom Petch, Kacheong Poon, Julien Pourtet, Irene
	Rüngeler, Michael Welzl, and Qiaobing Xie.
	And finally the people who have provided comments for this document
	including Gorry Fairhurst, Martin Duke, Benjamin Kaduk, Tero Kivinen,
	Eliot Lear, Marcelo Ricardo Leitner, David Mandelberg, John Mattsson,
	Claudio Porfiri, Maksim Proshin, Ines Robles, Timo Völker, Magnus
	Westerlund, and Zhouming.
	Our thanks cannot be adequately expressed to all of you who have
	participated in the coding, testing, and updating process of this
	document. All we can say is, Thank You!
	18. Normative References		17.1. Normative References
	[ITU.V42.1994]		[ITU.V42.1994]
	International Telecommunications Union, "Error-correcting		International Telecommunications Union, "Error-correcting
	Procedures for DCEs Using Asynchronous-to-Synchronous		Procedures for DCEs Using Asynchronous-to-Synchronous
	Conversion", ITU-T Recommendation V.42, 1994.		Conversion", ITU-T Recommendation V.42, 1994.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
	skipping to change at page 149, line 43 ¶		skipping to change at line 6846 ¶
	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,		[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,		"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
	DOI 10.17487/RFC8201, July 2017,		DOI 10.17487/RFC8201, July 2017,
	<https://www.rfc-editor.org/info/rfc8201>.		<https://www.rfc-editor.org/info/rfc8201>.
	[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.		[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
	Völker, "Packetization Layer Path MTU Discovery for		Völker, "Packetization Layer Path MTU Discovery for
	Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,		Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
	September 2020, <https://www.rfc-editor.org/info/rfc8899>.		September 2020, <https://www.rfc-editor.org/info/rfc8899>.
	19. Informative References		17.2. Informative References
	[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of		[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
	Tahoe, Reno, and SACK TCP", SIGCOM 99, V. 26, N. 3,		Tahoe, Reno, and SACK TCP", SIGCOM 99, V. 26, N. 3, pp
	pp 5-21, July 1996.		5-21, July 1996.
	[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,		[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
	"TCP Congestion Control with a Misbehaving Receiver", ACM		"TCP Congestion Control with a Misbehaving Receiver", ACM
	Computer Communications Review 29(5), October 1999.		Computer Communications Review 29(5), October 1999.
	[ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End		[ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End
	Network Path Properties", SIGCOM 99, 1999.		Network Path Properties", SIGCOM 99, October 1999.
	[WILLIAMS93]		[WILLIAMS93]
	Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION		Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION
	ALGORITHMS", SIGCOM 99, August 1993,		ALGORITHMS", SIGCOM 99, August 1993,
	<http://www.geocities.com/SiliconValley/Pines/8659/		<https://archive.org/stream/PainlessCRC/crc_v3.txt>.
	crc.htm>.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980,
	<https://www.rfc-editor.org/info/rfc768>.		<https://www.rfc-editor.org/info/rfc768>.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<https://www.rfc-editor.org/info/rfc793>.		<https://www.rfc-editor.org/info/rfc793>.
	[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security		[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
	skipping to change at page 152, line 25 ¶		skipping to change at line 6966 ¶
	[RFC8540] Stewart, R., Tuexen, M., and M. Proshin, "Stream Control		[RFC8540] Stewart, R., Tuexen, M., and M. Proshin, "Stream Control
	Transmission Protocol: Errata and Issues in RFC 4960",		Transmission Protocol: Errata and Issues in RFC 4960",
	RFC 8540, DOI 10.17487/RFC8540, February 2019,		RFC 8540, DOI 10.17487/RFC8540, February 2019,
	<https://www.rfc-editor.org/info/rfc8540>.		<https://www.rfc-editor.org/info/rfc8540>.
	Appendix A. CRC32c Checksum Calculation		Appendix A. CRC32c Checksum Calculation
	We define a 'reflected value' as one that is the opposite of the		We define a 'reflected value' as one that is the opposite of the
	normal bit order of the machine. The 32-bit CRC (Cyclic Redundancy		normal bit order of the machine. The 32-bit CRC (Cyclic Redundancy
	Check) is calculated as described for CRC32c and uses the polynomial		Check) is calculated, as described for CRC32c and uses the polynomial
	code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25+x^23+x^22		code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25+x^23+x^22
	+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is		+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is
	computed using a procedure similar to ETHERNET CRC [ITU.V42.1994],		computed using a procedure similar to ETHERNET CRC [ITU.V42.1994],
	modified to reflect transport-level usage.		modified to reflect transport-level usage.
	CRC computation uses polynomial division. A message bit-string M is		CRC computation uses polynomial division. A message bit-string M is
	transformed to a polynomial, M(X), and the CRC is calculated from		transformed to a polynomial, M(X), and the CRC is calculated from
	M(X) using polynomial arithmetic.		M(X) using polynomial arithmetic.
	When CRCs are used at the link layer, the polynomial is derived from		When CRCs are used at the link layer, the polynomial is derived from
	on-the-wire bit ordering: the first bit 'on the wire' is the high-		on-the-wire bit ordering: the first bit 'on the wire' is the high-
	order coefficient. Since SCTP is a transport-level protocol, it		order coefficient. Since SCTP is a transport-level protocol, it
	cannot know the actual serial-media bit ordering. Moreover,		cannot know the actual serial-media bit ordering. Moreover,
	different links in the path between SCTP endpoints can use different		different links in the path between SCTP endpoints can use different
	link-level bit orders.		link-level bit orders.
	A convention therefore is established for mapping SCTP transport		A convention therefore is established for mapping SCTP transport
	messages to polynomials for purposes of CRC computation. The bit-		messages to polynomials for purposes of CRC computation. The bit-
	ordering for mapping SCTP messages to polynomials is that bytes are		ordering for mapping SCTP messages to polynomials is that bytes are
	taken most-significant first, but within each byte, bits are taken		taken most-significant first, but, within each byte, bits are taken
	least-significant first. The first byte of the message provides the		least-significant first. The first byte of the message provides the
	eight highest coefficients. Within each byte, the least-significant		eight highest coefficients. Within each byte, the least-significant
	SCTP bit gives the most-significant polynomial coefficient within		SCTP bit gives the most-significant polynomial coefficient within
	that byte, and the most-significant SCTP bit is the least-significant		that byte, and the most-significant SCTP bit is the least-significant
	polynomial coefficient in that byte. (This bit ordering is sometimes		polynomial coefficient in that byte. (This bit ordering is sometimes
	called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are		called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are
	to be transformed back into SCTP transport-level byte values, using a		to be transformed back into SCTP transport-level byte values, using a
	consistent mapping.		consistent mapping.
	The SCTP transport-level CRC value can be calculated as follows:		The SCTP transport-level CRC value can be calculated as follows:
	* CRC input data are assigned to a byte stream, numbered from 0 to		* CRC input data is assigned to a byte stream, numbered from 0 to
	N-1.		N-1.
	* The transport-level byte stream is mapped to a polynomial value.		* The transport-level byte stream is mapped to a polynomial value.
	An N-byte PDU with j bytes numbered 0 to N-1 is considered as		An N-byte PDU with j bytes numbered 0 to N-1 is considered as
	coefficients of a polynomial M(x) of order 8*N-1, with bit 0 of		coefficients of a polynomial M(x) of order 8*N-1, with bit 0 of
	byte j being coefficient x^(8*(N-j)-8), and bit 7 of byte j being		byte j being coefficient x^(8*(N-j)-8) and bit 7 of byte j being
	coefficient x^(8*(N-j)-1).		coefficient x^(8*(N-j)-1).
	* The CRC remainder register is initialized with all 1s and the CRC		* The CRC remainder register is initialized with all 1s and the CRC
	is computed with an algorithm that simultaneously multiplies by		is computed with an algorithm that simultaneously multiplies by
	x^32 and divides by the CRC polynomial.		x^32 and divides by the CRC polynomial.
	* The polynomial is multiplied by x^32 and divided by G(x), the		* The polynomial is multiplied by x^32 and divided by G(x), the
	generator polynomial, producing a remainder R(x) of degree less		generator polynomial, producing a remainder R(x) of degree less
	than or equal to 31.		than or equal to 31.
	skipping to change at page 154, line 32 ¶		skipping to change at line 7059 ¶
	COOKIE ECHO chunks. These special-case exchanges represent small		COOKIE ECHO chunks. These special-case exchanges represent small
	packets and will minimize the effect of the checksum calculation.		packets and will minimize the effect of the checksum calculation.
	The following non-normative sample code is taken from an open-source		The following non-normative sample code is taken from an open-source
	CRC generator [WILLIAMS93], using the "mirroring" technique and		CRC generator [WILLIAMS93], using the "mirroring" technique and
	yielding a lookup table for SCTP CRC32c with 256 entries, each 32		yielding a lookup table for SCTP CRC32c with 256 entries, each 32
	bits wide. While neither especially slow nor especially fast, as		bits wide. While neither especially slow nor especially fast, as
	software table-lookup CRCs go, it has the advantage of working on		software table-lookup CRCs go, it has the advantage of working on
	both big-endian and little-endian CPUs, using the same (host-order)		both big-endian and little-endian CPUs, using the same (host-order)
	lookup tables, and using only the predefined ntohl() and htonl()		lookup tables, and using only the predefined ntohl() and htonl()
	operations. The code is somewhat modified from [WILLIAMS93], to		operations. The code is somewhat modified from [WILLIAMS93] to
	ensure portability between big-endian and little-endian		ensure portability between big-endian and little-endian
	architectures, use fixed sized types to allow portability between		architectures, use fixed-sized types to allow portability between
	32-bit and 64-bit platforms, and general C code improvements. (Note		32-bit and 64-bit platforms, and use general C code improvements.
	that if the byte endian-ness of the target architecture is known to		(Note that, if the byte endian-ness of the target architecture is
	be little-endian, the final bit-reversal and byte-reversal steps can		known to be little endian, the final bit-reversal and byte-reversal
	be folded into a single operation.)		steps can be folded into a single operation.)
	<CODE BEGINS>		<CODE BEGINS>
	/****************************************************************/		/****************************************************************/
	/* Note: The definitions for Ross Williams's table generator */		/* Note: The definitions for Ross Williams's table generator */
	/* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE. */		/* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE. */
	/* For Mr. Williams's direct calculation code, use the settings */		/* For Mr. Williams's direct calculation code, use the settings */
	/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */		/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
	/* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000. */		/* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000. */
	/****************************************************************/		/****************************************************************/
	skipping to change at page 159, line 34 ¶		skipping to change at line 7302 ¶
	/* save and zero checksum */		/* save and zero checksum */
	message = (SCTP_message *)buffer;		message = (SCTP_message *)buffer;
	original_crc32 = ntohl(message->common_header.checksum);		original_crc32 = ntohl(message->common_header.checksum);
	message->common_header.checksum = 0L;		message->common_header.checksum = 0L;
	crc32 = generate_crc32c(buffer, length);		crc32 = generate_crc32c(buffer, length);
	return ((original_crc32 == crc32) ? 1 : -1);		return ((original_crc32 == crc32) ? 1 : -1);
	}		}
	<CODE ENDS>		<CODE ENDS>
			Acknowledgements
			An undertaking represented by this updated document is not a small
			feat and represents the summation of the initial coauthors of
			[RFC2960]: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
			T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson.
			Add to that, the comments from everyone who contributed to [RFC2960]:
			Mark Allman, R. J. Atkinson, Richard Band, Scott Bradner, Steve
			Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally
			Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian
			Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney,
			Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon
			Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme,
			Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg
			Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their
			invaluable comments.
			Then, add the coauthors of [RFC4460]: I. Arias-Rodriguez, K. Poon,
			and A. Caro.
			Then, add to these the efforts of all the subsequent seven SCTP
			interoperability tests and those who commented on [RFC4460], as shown
			in its acknowledgements: Barry Zuckerman, La Monte Yarroll, Qiaobing
			Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John
			Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki,
			Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian
			Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner,
			Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan
			McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David
			Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller,
			Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie,
			John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim,
			Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve
			Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
			Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
			Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
			A special thanks to Mark Allman, who actually should have been a
			coauthor of [RFC4460] for his work on the max-burst but managed to
			wiggle out due to a technicality.
			Also, we would like to acknowledge Lyndon Ong and Phil Conrad for
			their valuable input and many contributions.
			Furthermore, you have [RFC4960] and those who have commented upon
			that, including Alfred Hönes and Ronnie Sellars.
			Then, add the coauthor of [RFC8540]: Maksim Proshin.
			And people who have commented on [RFC8540]: Pontus Andersson, Eric
			W. Biederman, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst,
			Benjamin Kaduk, Mirja Kühlewind, Peter Lei, Gyula Marosi, Lionel
			Morand, Jeff Morriss, Tom Petch, Kacheong Poon, Julien Pourtet, Irene
			Rüngeler, Michael Welzl, and Qiaobing Xie.
			And, finally, the people who have provided comments for this
			document, including Gorry Fairhurst, Martin Duke, Benjamin Kaduk,
			Tero Kivinen, Eliot Lear, Marcelo Ricardo Leitner, David Mandelberg,
			John Preuß Mattsson, Claudio Porfiri, Maksim Proshin, Ines Robles,
			Timo Völker, Magnus Westerlund, and Zhouming.
			Our thanks cannot be adequately expressed to all of you who have
			participated in the coding, testing, and updating process of this
			document. All we can say is, Thank You!
	Authors' Addresses		Authors' Addresses
	Randall R. Stewart		Randall R. Stewart
	Netflix, Inc.		Netflix, Inc.
	2455 Heritage Green Ave		2455 Heritage Green Ave
	Davenport, FL 33837		Davenport, FL 33837
	United States		United States of America
	Email: randall@lakerest.net		Email: randall@lakerest.net
	Michael Tüxen		Michael Tüxen
	Münster University of Applied Sciences		Münster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	48565 Steinfurt		48565 Steinfurt
	Germany		Germany
	Email: tuexen@fh-muenster.de		Email: tuexen@fh-muenster.de
	Karen E. E. Nielsen		Karen E. E. Nielsen
	Kamstrup A/S		Kamstrup A/S
	Industrivej 28		Industrivej 28
	DK-8660 Skanderborg		DK-8660 Skanderborg
	Denmark		Denmark
	Email: kee@kamstrup.com		Email: kee@kamstrup.com
End of changes. 431 change blocks.
	938 lines changed or deleted		966 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/