EXHIBIT 8
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 1 of 135
`
`

`

`Network Working Group R. Stewart
`Request for Comments: 2960 Q. Xie
`Category: Standards Track Motorola
` K. Morneault
` C. Sharp
` Cisco
` H. Schwarzbauer
` Siemens
` T. Taylor
` Nortel Networks
` I. Rytina
` Ericsson
` M. Kalla
` Telcordia
` L. Zhang
` UCLA
` V. Paxson
` ACIRI
` October 2000
`
` Stream Control Transmission Protocol
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2000). All Rights Reserved.
`
`Abstract
`
` This document describes the Stream Control Transmission Protocol
` (SCTP). SCTP is designed to transport PSTN signaling messages over
` IP networks, but is capable of broader applications.
`
` SCTP is a reliable transport protocol operating on top of a
` connectionless packet network such as IP. It offers the following
` services to its users:
`
` -- acknowledged error-free non-duplicated transfer of user data,
` -- data fragmentation to conform to discovered path MTU size,
`
`Stewart, et al. Standards Track [Page 1]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 2 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` -- sequenced delivery of user messages within multiple streams,
` with an option for order-of-arrival delivery of individual user
` messages,
` -- optional bundling of multiple user messages into a single SCTP
` packet, and
` -- network-level fault tolerance through supporting of multi-
` homing at either or both ends of an association.
`
` The design of SCTP includes appropriate congestion avoidance behavior
` and resistance to flooding and masquerade attacks.
`
`Stewart, et al. Standards Track [Page 2]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 3 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
`Table of Contents
`
` 1. Introduction.................................................. 5
` 1.1 Motivation.................................................. 6
` 1.2 Architectural View of SCTP.................................. 6
` 1.3 Functional View of SCTP..................................... 7
` 1.3.1 Association Startup and Takedown........................ 8
` 1.3.2 Sequenced Delivery within Streams....................... 9
` 1.3.3 User Data Fragmentation................................. 9
` 1.3.4 Acknowledgement and Congestion Avoidance................ 9
` 1.3.5 Chunk Bundling ......................................... 10
` 1.3.6 Packet Validation....................................... 10
` 1.3.7 Path Management......................................... 11
` 1.4 Key Terms................................................... 11
` 1.5 Abbreviations............................................... 15
` 1.6 Serial Number Arithmetic.................................... 15
` 2. Conventions.................................................... 16
` 3. SCTP packet Format............................................ 16
` 3.1 SCTP Common Header Field Descriptions....................... 17
` 3.2 Chunk Field Descriptions.................................... 18
` 3.2.1 Optional/Variable-length Parameter Format............... 20
` 3.3 SCTP Chunk Definitions...................................... 21
` 3.3.1 Payload Data (DATA)..................................... 22
` 3.3.2 Initiation (INIT)....................................... 24
` 3.3.2.1 Optional or Variable Length Parameters.............. 26
` 3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
` 3.3.3.1 Optional or Variable Length Parameters.............. 33
` 3.3.4 Selective Acknowledgement (SACK)........................ 33
` 3.3.5 Heartbeat Request (HEARTBEAT)........................... 37
` 3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38
` 3.3.7 Abort Association (ABORT)............................... 39
` 3.3.8 Shutdown Association (SHUTDOWN)......................... 40
` 3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40
` 3.3.10 Operation Error (ERROR)................................ 41
` 3.3.10.1 Invalid Stream Identifier.......................... 42
` 3.3.10.2 Missing Mandatory Parameter........................ 43
` 3.3.10.3 Stale Cookie Error................................. 43
` 3.3.10.4 Out of Resource.................................... 44
` 3.3.10.5 Unresolvable Address............................... 44
` 3.3.10.6 Unrecognized Chunk Type............................ 44
` 3.3.10.7 Invalid Mandatory Parameter........................ 45
` 3.3.10.8 Unrecognized Parameters............................ 45
` 3.3.10.9 No User Data....................................... 46
` 3.3.10.10 Cookie Received While Shutting Down............... 46
` 3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
` 3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
` 3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
` 4. SCTP Association State Diagram................................. 48
`
`Stewart, et al. Standards Track [Page 3]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 4 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` 5. Association Initialization..................................... 52
` 5.1 Normal Establishment of an Association...................... 52
` 5.1.1 Handle Stream Parameters................................ 54
` 5.1.2 Handle Address Parameters............................... 54
` 5.1.3 Generating State Cookie................................. 56
` 5.1.4 State Cookie Processing................................. 57
` 5.1.5 State Cookie Authentication............................. 57
` 5.1.6 An Example of Normal Association Establishment.......... 58
` 5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,
` and COOKIE ACK.............................................. 60
` 5.2.1 Handle Duplicate INIT in COOKIE-WAIT
` or COOKIE-ECHOED States................................. 60
` 5.2.2 Unexpected INIT in States Other than CLOSED,
` COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61
` 5.2.3 Unexpected INIT ACK..................................... 61
` 5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62
` 5.2.4.1 An Example of a Association Restart................. 64
` 5.2.5 Handle Duplicate COOKIE ACK............................. 66
` 5.2.6 Handle Stale COOKIE Error............................... 66
` 5.3 Other Initialization Issues................................. 67
` 5.3.1 Selection of Tag Value.................................. 67
` 6. User Data Transfer............................................. 67
` 6.1 Transmission of DATA Chunks................................. 69
` 6.2 Acknowledgement on Reception of DATA Chunks................. 70
` 6.2.1 Tracking Peer’s Receive Buffer Space.................... 73
` 6.3 Management Retransmission Timer............................. 75
` 6.3.1 RTO Calculation......................................... 75
` 6.3.2 Retransmission Timer Rules.............................. 76
` 6.3.3 Handle T3-rtx Expiration................................ 77
` 6.4 Multi-homed SCTP Endpoints.................................. 78
` 6.4.1 Failover from Inactive Destination Address.............. 79
` 6.5 Stream Identifier and Stream Sequence Number................ 80
` 6.6 Ordered and Unordered Delivery.............................. 80
` 6.7 Report Gaps in Received DATA TSNs........................... 81
` 6.8 Adler-32 Checksum Calculation............................... 82
` 6.9 Fragmentation............................................... 83
` 6.10 Bundling .................................................. 84
` 7. Congestion Control .......................................... 85
` 7.1 SCTP Differences from TCP Congestion Control................ 85
` 7.2 SCTP Slow-Start and Congestion Avoidance.................... 87
` 7.2.1 Slow-Start.............................................. 87
` 7.2.2 Congestion Avoidance.................................... 89
` 7.2.3 Congestion Control...................................... 89
` 7.2.4 Fast Retransmit on Gap Reports.......................... 90
` 7.3 Path MTU Discovery.......................................... 91
` 8. Fault Management.............................................. 92
` 8.1 Endpoint Failure Detection.................................. 92
` 8.2 Path Failure Detection...................................... 92
`
`Stewart, et al. Standards Track [Page 4]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 5 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` 8.3 Path Heartbeat.............................................. 93
` 8.4 Handle "Out of the blue" Packets............................ 95
` 8.5 Verification Tag............................................ 96
` 8.5.1 Exceptions in Verification Tag Rules.................... 97
` 9. Termination of Association..................................... 98
` 9.1 Abort of an Association..................................... 98
` 9.2 Shutdown of an Association.................................. 98
` 10. Interface with Upper Layer....................................101
` 10.1 ULP-to-SCTP................................................101
` 10.2 SCTP-to-ULP................................................111
` 11. Security Considerations.......................................114
` 11.1 Security Objectives........................................114
` 11.2 SCTP Responses To Potential Threats........................115
` 11.2.1 Countering Insider Attacks.............................115
` 11.2.2 Protecting against Data Corruption in the Network......115
` 11.2.3 Protecting Confidentiality.............................115
` 11.2.4 Protecting against Blind Denial of Service Attacks.....116
` 11.2.4.1 Flooding...........................................116
` 11.2.4.2 Blind Masquerade...................................118
` 11.2.4.3 Improper Monopolization of Services................118
` 11.3 Protection against Fraud and Repudiation...................119
` 12. Recommended Transmission Control Block (TCB) Parameters.......120
` 12.1 Parameters necessary for the SCTP instance.................120
` 12.2 Parameters necessary per association (i.e. the TCB)........120
` 12.3 Per Transport Address Data.................................122
` 12.4 General Parameters Needed..................................123
` 13. IANA Considerations...........................................123
` 13.1 IETF-defined Chunk Extension...............................123
` 13.2 IETF-defined Chunk Parameter Extension.....................124
` 13.3 IETF-defined Additional Error Causes.......................124
` 13.4 Payload Protocol Identifiers...............................125
` 14. Suggested SCTP Protocol Parameter Values......................125
` 15. Acknowledgements..............................................126
` 16. Authors’ Addresses............................................126
` 17. References....................................................128
` 18. Bibliography..................................................129
` Appendix A .......................................................131
` Appendix B .......................................................132
` Full Copyright Statement .........................................134
`
`1. Introduction
`
` This section explains the reasoning behind the development of the
` Stream Control Transmission Protocol (SCTP), the services it offers,
` and the basic concepts needed to understand the detailed description
` of the protocol.
`
`Stewart, et al. Standards Track [Page 5]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 6 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
`1.1 Motivation
`
` TCP [RFC793] has performed immense service as the primary means of
` reliable data transfer in IP networks. However, an increasing number
` of recent applications have found TCP too limiting, and have
` incorporated their own reliable data transfer protocol on top of UDP
` [RFC768]. The limitations which users have wished to bypass include
` the following:
`
` -- TCP provides both reliable data transfer and strict order-of-
` transmission delivery of data. Some applications need reliable
` transfer without sequence maintenance, while others would be
` satisfied with partial ordering of the data. In both of these
` cases the head-of-line blocking offered by TCP causes unnecessary
` delay.
`
` -- The stream-oriented nature of TCP is often an inconvenience.
` Applications must add their own record marking to delineate their
` messages, and must make explicit use of the push facility to
` ensure that a complete message is transferred in a reasonable
` time.
`
` -- The limited scope of TCP sockets complicates the task of
` providing highly-available data transfer capability using multi-
` homed hosts.
`
` -- TCP is relatively vulnerable to denial of service attacks, such
` as SYN attacks.
`
` Transport of PSTN signaling across the IP network is an application
` for which all of these limitations of TCP are relevant. While this
` application directly motivated the development of SCTP, other
` applications may find SCTP a good match to their requirements.
`
`1.2 Architectural View of SCTP
`
` SCTP is viewed as a layer between the SCTP user application ("SCTP
` user" for short) and a connectionless packet network service such as
` 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
` messages between peer SCTP users. It performs this service within
` the context of an association between two SCTP endpoints. Section 10
` of this document sketches the API which should exist at the boundary
` between the SCTP and the SCTP user layers.
`
` SCTP is connection-oriented in nature, but the SCTP association is a
` broader concept than the TCP connection. SCTP provides the means for
` each SCTP endpoint (Section 1.4) to provide the other endpoint
`
`Stewart, et al. Standards Track [Page 6]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 7 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` (during association startup) with a list of transport addresses
` (i.e., multiple IP addresses in combination with an SCTP port)
` through which that endpoint can be reached and from which it will
` originate SCTP packets. The association spans transfers over all of
` the possible source/destination combinations which may be generated
` from each endpoint’s lists.
`
` _____________ _____________
` | SCTP User | | SCTP User |
` | Application | | Application |
` |-------------| |-------------|
` | SCTP | | SCTP |
` | Transport | | Transport |
` | Service | | Service |
` |-------------| |-------------|
` | |One or more ---- One or more| |
` | IP Network |IP address \/ IP address| IP Network |
` | Service |appearances /\ appearances| Service |
` |_____________| ---- |_____________|
`
` SCTP Node A |<-------- Network transport ------->| SCTP Node B
`
` Figure 1: An SCTP Association
`
`1.3 Functional View of SCTP
`
` The SCTP transport service can be decomposed into a number of
` functions. These are depicted in Figure 2 and explained in the
` remainder of this section.
`
`Stewart, et al. Standards Track [Page 7]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 8 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` SCTP User Application
`
` -----------------------------------------------------
` _____________ ____________________
` | | | Sequenced delivery |
` | Association | | within streams |
` | | |____________________|
` | startup |
` | | ____________________________
` | and | | User Data Fragmentation |
` | | |____________________________|
` | takedown |
` | | ____________________________
` | | | Acknowledgement |
` | | | and |
` | | | Congestion Avoidance |
` | | |____________________________|
` | |
` | | ____________________________
` | | | Chunk Bundling |
` | | |____________________________|
` | |
` | | ________________________________
` | | | Packet Validation |
` | | |________________________________|
` | |
` | | ________________________________
` | | | Path Management |
` |_____________| |________________________________|
`
` Figure 2: Functional View of the SCTP Transport Service
`
`1.3.1 Association Startup and Takedown
`
` An association is initiated by a request from the SCTP user (see the
` description of the ASSOCIATE (or SEND) primitive in Section 10).
`
` A cookie mechanism, similar to one described by Karn and Simpson in
` [RFC2522], is employed during the initialization to provide
` protection against security attacks. The cookie mechanism 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
` Section 5 of this document.
`
` SCTP provides for graceful close (i.e., shutdown) of an active
` association on request from the SCTP user. See the description of
` the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful
` close (i.e., abort), either on request from the user (ABORT
`
`Stewart, et al. Standards Track [Page 8]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 9 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` primitive) or as a result of an error condition detected within the
` SCTP layer. Section 9 describes both the graceful and the ungraceful
` close procedures.
`
` SCTP does not support a half-open state (like TCP) wherein one side
` may continue sending data while the other end is closed. When either
` endpoint performs a shutdown, the association on each peer will stop
` accepting new data from its user and only deliver data in queue at
` the time of the graceful close (see Section 9).
`
`1.3.2 Sequenced Delivery within Streams
`
` 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
` 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
` bytes (in this document a byte is assumed to be eight bits).
`
` The SCTP user can specify at association startup time the number of
` streams to be supported by the association. This number is
` negotiated with the remote end (see Section 5.1.1). User messages
` are associated with stream numbers (SEND, RECEIVE primitives, Section
` 10). Internally, SCTP assigns a stream sequence number to 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
` within a given stream. However, while one stream may be blocked
` waiting for the next in-sequence user message, delivery from other
` streams may proceed.
`
` SCTP provides a mechanism for bypassing the sequenced delivery
` service. User messages sent using this mechanism are delivered to
` the SCTP user as soon as they are received.
`
`1.3.3 User Data Fragmentation
`
` When needed, SCTP fragments user messages to ensure that the SCTP
` packet passed to the lower layer conforms to the path MTU. On
` receipt, fragments are reassembled into complete messages before
` being passed to the SCTP user.
`
`1.3.4 Acknowledgement and Congestion Avoidance
`
` SCTP assigns a Transmission Sequence Number (TSN) to each user data
` fragment or unfragmented message. The TSN is independent of any
` stream sequence number assigned at the stream level. The receiving
`
`Stewart, et al. Standards Track [Page 9]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 10 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` end acknowledges all TSNs received, even if there are gaps in the
` sequence. In this way, reliable delivery is kept functionally
` separate from sequenced stream delivery.
`
` The acknowledgement and congestion avoidance function is responsible
` for packet retransmission when timely acknowledgement has not been
` received. Packet retransmission is conditioned by congestion
` avoidance procedures similar to those used for TCP. See Sections 6
` and 7 for a detailed description of the protocol procedures
` associated with this function.
`
`1.3.5 Chunk Bundling
`
` 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.
` Each chunk may contain either user data or SCTP control information.
` The SCTP user has the option to request bundling of more than one
` user messages into a single SCTP packet. The chunk bundling function
` of SCTP is responsible for assembly of the complete SCTP packet and
` its disassembly at the receiving end.
`
` During times of congestion an SCTP implementation MAY still perform
` bundling even if the user has requested that SCTP not bundle. The
` user’s disabling of bundling only affects SCTP implementations that
` may delay a small period of time before transmission (to attempt to
` encourage bundling). When the user layer disables bundling, this
` small delay is prohibited but not bundling that is performed during
` congestion or retransmission.
`
`1.3.6 Packet Validation
`
` A mandatory Verification Tag field and a 32 bit checksum field (see
` Appendix B for a description of the Adler-32 checksum) are included
` in the SCTP common header. The Verification Tag value is chosen by
` each end of the association during association startup. Packets
` received without the expected Verification Tag value are discarded,
` as a protection against blind masquerade attacks and against stale
` SCTP packets from a previous association. The Adler-32 checksum
` should be set by the sender of each SCTP packet to provide additional
` protection against data corruption in the network. The receiver of
` an SCTP packet with an invalid Adler-32 checksum silently discards
` the packet.
`
`Stewart, et al. Standards Track [Page 10]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 11 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
`1.3.7 Path Management
`
` The sending SCTP user is able to manipulate the set of transport
` addresses used as destinations for SCTP packets through the
` primitives described in Section 10. The SCTP path management
` function chooses the destination transport address for each outgoing
` SCTP packet based on the SCTP user’s instructions and the currently
` perceived reachability status of the eligible destination set. The
` path management function monitors reachability through heartbeats
` when other packet traffic is inadequate to provide this information
` and advises the SCTP user when reachability of any far-end transport
` address changes. The path management function is also responsible
` for reporting the eligible set of local transport addresses to the
` far end during association startup, and for reporting the transport
` addresses returned from the far end to the SCTP user.
`
` At association start-up, a primary path is defined for each SCTP
` endpoint, and is used for normal sending of SCTP packets.
`
` On the receiving end, the path management is responsible for
` verifying the existence of a valid SCTP association to which the
` inbound SCTP packet belongs before passing it for further processing.
`
` Note: Path Management and Packet Validation are done at the same
` time, so although described separately above, in reality they cannot
` be performed as separate items.
`
`1.4 Key Terms
`
` Some of the language used to describe SCTP has been introduced in the
` previous sections. This section provides a consolidated list of the
` key terms and their definitions.
`
` o Active destination transport address: A transport address on a
` peer endpoint which a transmitting endpoint considers available
` for receiving user messages.
`
` o Bundling: An optional multiplexing operation, whereby more than
` one user message may be carried in the same SCTP packet. Each
` user message occupies its own DATA chunk.
`
` o Chunk: A unit of information within an SCTP packet, consisting of
` a chunk header and chunk-specific content.
`
` o Congestion Window (cwnd): An SCTP variable that limits the data,
` in number of bytes, a sender can send to a particular destination
` transport address before receiving an acknowledgement.
`
`Stewart, et al. Standards Track [Page 11]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 12 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` o Cumulative TSN Ack Point: The TSN of the last DATA chunk
` acknowledged via the Cumulative TSN Ack field of a SACK.
`
` o Idle destination address: An address that has not had user
` messages sent to it within some length of time, normally the
` HEARTBEAT interval or greater.
`
` o Inactive destination transport address: An address which is
` considered inactive due to errors and unavailable to transport
` user messages.
`
` o Message = user message: Data submitted to SCTP by the Upper Layer
` Protocol (ULP).
`
` o Message Authentication Code (MAC): An integrity check mechanism
` based on cryptographic hash functions using a secret key.
` Typically, message authentication codes are used between two
` parties that share a secret key in order to validate information
` transmitted between these parties. In SCTP it is used by an
` endpoint to validate the State Cookie information that is returned
` from the peer in the COOKIE ECHO chunk. The term "MAC" has
` different meanings in different contexts. SCTP uses this term
` with the same meaning as in [RFC2104].
`
` o Network Byte Order: Most significant byte first, a.k.a., Big
` Endian.
`
` o Ordered Message: A user message that is delivered in order with
` respect to all previous user messages sent within the stream the
` message was sent on.
`
` o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
` DATA chunk) that has been sent by the endpoint but for which it
` has not yet received an acknowledgement.
`
` o Path: The route taken by the SCTP packets sent by one SCTP
` endpoint to a specific destination transport address of its peer
` SCTP endpoint. Sending to different destination transport
` addresses does not necessarily guarantee getting separate paths.
`
` o Primary Path: The primary path is the destination and source
` address that will be put into a packet outbound to the peer
` endpoint by default. The definition includes the source address
` since an implementation MAY wish to specify both destination and
` source address to better control the return path taken by reply
` chunks and on which interface the packet is transmitted when the
` data sender is multi-homed.
`
`Stewart, et al. Standards Track [Page 12]
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1019
`Page 13 of 135
`
`

`

`RFC 2960 Stream Control Transmission Protocol October 2000
`
` o Receiver Window (rwnd): An SCTP variable a data sender uses to
` store the most recently calculated receiver window of its peer, in
` number of bytes. This gives the sender an indication of the space
` available in the receiver’s inbound buffer.
`
` o SCTP association: A protocol relationship between SCTP endpoints,
` composed of the two SCTP endpoints and protocol state information
` including Verification Tags and the currently active set of
` Transmission Sequence Numbers (TSNs), etc. An association can be
` uniquely identified by the transport addresses used by the
` endpoints in the association. Two SCTP endpoints MUST NOT have
` more than one SCTP association between them at any given time.
`
` o SCTP endpoint: The logical sender/receiver of SCTP packets. On a
` multi-homed host, an SCTP endpoint is represented to its peers as
` a combination of a set of eligible destination transport addresses
` 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 used by an SCTP endpoint must use the same
` port number, but can use multiple IP addresses. A transport
` address used by an SCTP endpoint must not be used by another SCTP
` endpoint. In other words, a transport address is unique to an
` SCTP endpoint.
`
` o SCTP packet (or packet): The unit of data delivery across the
` interface between SCTP and the connectionless packet network
` (e.g., IP). An SCTP packet includes the common SCTP header,
`