RFC 5061
Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration 🦋
Okay bestie, this is RFC 5061 💖 It's a Standards Track doc from the Network Working Group, dated September 2007 ✨ The authors are R. Stewart (Cisco Systems, Inc.), Q. Xie (Motorola, Inc.), M. Tuexen (Univ. of Applied Sciences Muenster), and S. Maruyama and M. Kozuka (Kyoto University) 🫶 The title block doesn't list anything it obsoletes or updates, so there's no drama there 🌸
Status of This Memo ✨
Okay so this doc specifies an Internet standards track protocol for the Internet community, and it literally requests discussion and suggestions for improvements 💅 If you want the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract 🎀
Okay, so a local host can have multiple points of attachment to the Internet, which gives it some fault tolerance against hardware failures 🛡️ Stream Control Transmission Protocol (SCTP) (RFC 4960) was built to take full advantage of that multi-homed host, giving fast failover and association survivability when hardware fails 🔥 This document describes an extension to SCTP that lets an SCTP stack dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and request to set the primary address the peer will use when sending to an endpoint. It's giving flexibility, no cap 💜
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Serial Number Arithmetic . . . . . . . . . . . . . . . . . . . 4
4. Additional Chunks and Parameters . . . . . . . . . . . . . . . 4
4.1. New Chunk Types . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Address Configuration Change Chunk (ASCONF) . . . . . 5
4.1.2. Address Configuration Acknowledgment Chunk
(ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 6
4.2. New Parameter Types . . . . . . . . . . . . . . . . . . . 7
4.2.1. Add IP Address . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Delete IP Address . . . . . . . . . . . . . . . . . . 9
4.2.3. Error Cause Indication . . . . . . . . . . . . . . . . 10
4.2.4. Set Primary IP Address . . . . . . . . . . . . . . . . 11
4.2.5. Success Indication . . . . . . . . . . . . . . . . . . 12
4.2.6. Adaptation Layer Indication . . . . . . . . . . . . . 13
4.2.7. Supported Extensions Parameter . . . . . . . . . . . . 13
4.3. New Error Causes . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Error Cause: Request to Delete Last Remaining IP
Address . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. Error Cause: Operation Refused Due to Resource
Shortage . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.3. Error Cause: Request to Delete Source IP Address . . . 16
4.3.4. Error Cause: Association Aborted Due to Illegal
ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 17
4.3.5. Error Cause: Request Refused - No Authorization. . . . 17
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18
5.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 20
5.2. Upon Reception of an ASCONF Chunk . . . . . . . . . . . . 21
5.3. General Rules for Address Manipulation . . . . . . . . . . 24
5.3.1. A Special Case for OOTB ABORT Chunks . . . . . . . . . 29
5.3.2. A Special Case for Changing an Address . . . . . . . . 29
5.4. Setting of the Primary Address . . . . . . . . . . . . . . 29
5.5. Bundling of Multiple ASCONFs . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 36
A.1. General Remarks . . . . . . . . . . . . . . . . . . . . . 36
A.2. Generalized Endpoints . . . . . . . . . . . . . . . . . . 36
A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 37
A.4. Relationship with RFC 4960 . . . . . . . . . . . . . . . . 38
A.5. Rules for Address Manipulation . . . . . . . . . . . . . . 381. Introduction 🌸
Okay so a local host can have multiple points of attachment to the Internet, giving it some fault tolerance from hardware failures 🫶 SCTP was made to take full advantage of that multi-homed host, giving fast failover and association survivability when hardware fails. But here's the thing: lots of modern computers let you add and remove network cards on the fly (sometimes called a hot-pluggable interface) 😭 Add in the fact that, in IPv6, a provider can dynamically renumber a network, and there's still a gap between full fault tolerance and the SCTP protocol as it's currently defined 💀 Whether a card gets added or an interface gets renumbered, the transport association has to be restarted to use the new configuration. For lots of fault-tolerant apps, that restart counts as an outage, and nobody wants that 🙈
This document describes an extension to SCTP that tries to fix this for the more demanding fault-tolerant apps 👑 With this extension, an SCTP stack can:
- Dynamically add an IP address to an association.
- Dynamically delete an IP address from an association.
- Request to set the primary address the peer will use when sending to an endpoint.
Adding and removing IP addresses dynamically means an SCTP association can keep working through host and network reconfigurations ✨ These changes can come from the provider or from the user, and the peer might be better off using the newly added address. The catch is that only the endpoint where the reconfiguration happened may know that. So this extension lets the local endpoint tell the peer what it thinks is the better primary address to use 🧚
One more thing this extension adds is a small, 32-bit integer called an adaptation indication, which gets exchanged at startup 🎀 It's useful when there are one or more specific layers below the application but still above SCTP. Exchanging this indication lets the proper layer get enabled below the application, which is so smart, literally 💅
2. Conventions 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
3. Serial Number Arithmetic 🔢
It is essential to remember that the actual Address Configuration Change Chunk (ASCONF) Sequence Number space is finite, though very large 🥹 This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with ASCONF Sequence Numbers MUST be performed modulo 2**32. This unsigned arithmetic keeps the relationship of sequence numbers intact as they cycle from 2**32 - 1 back to 0. Computer modulo arithmetic has some subtleties, so take great care when you program comparisons of these values 🙈 When referring to ASCONF Sequence Numbers, the symbol =< means "less than or equal" (modulo 2**32).
Comparisons and arithmetic on ASCONF sequence numbers in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
ASCONF Sequence Numbers wrap around when they reach 2**32 - 1. In other words, the next ASCONF Sequence Number an ASCONF chunk MUST use after transmitting an ASCONF Sequence Number = 2**32 - 1 is 0 🔄
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic (as defined in [RFC1982]) where SERIAL_BITS = 16. All other arithmetic and comparisons in this document use normal arithmetic 💖
4. Additional Chunks and Parameters ✨
This section adds two new chunks and seven new parameters to allow:
- Dynamic addition of IP addresses to an association.
- Dynamic deletion of IP addresses from an association.
- A request to set the primary address the peer will use when sending to an endpoint.
It also describes three new Error Causes that support these new chunks and parameters 🦋
4.1. New Chunk Types 🧚
Okay so this section defines two new chunk types that get used to transfer the control information reliably. Table 1 shows both of them 💅
Chunk Type Chunk Name
--------------------------------------------------------------
0xC1 Address Configuration Change Chunk (ASCONF)
0x80 Address Configuration Acknowledgment (ASCONF-ACK)
Table 1: Address Configuration Chunks4.1.1. Address Configuration Change Chunk (ASCONF) 💖
okay so this is the ASCONF chunk, and it's how we tell the other endpoint about a config change that MUST get acknowledged 🫶. The info rides in a Type-Length-Value (TLV) format, the same one from "3.2.1 Optional/Variable-length Parameter Format" in [RFC4960], for every variable parameter ✨. Bestie, this chunk MUST be sent authenticated using the mechanism from [RFC4895]. If it shows up unauthenticated, it MUST be silently discarded, as [RFC4895] describes 🙈. no cap, security is the whole vibe here 🔐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ .... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sequence Number: 32 bits (unsigned integer) 🔢
This is the Sequence Number for the ASCONF Chunk. The valid range is 0 to 4294967295 (2**32 - 1), and it wraps back to 0 after hitting 4294967295 🌸
Address Parameter: 8 or 20 bytes (depending on the address type) 📍
This field holds an address parameter, either IPv6 or IPv4, from [RFC4960]. It's the address of the ASCONF Chunk's sender, and the peer (the receiver) MUST treat it as part of the association 🦋. The receiver can use it to help find the association. If the address 0.0.0.0 or ::0 shows up, the receiver MAY look up the association using other info in the packet. This parameter MUST be in every ASCONF message, since it's a mandatory TLV parameter 💅
Note: the host name address MUST NOT be sent, and it MUST be ignored if received in any ASCONF message. Don't be that person 🙅♀️
It's worth knowing that the ASCONF Chunk format requires the receiver to report back to the sender if it doesn't understand the chunk. That happens by setting the upper bits in the chunk type, as [RFC4960], Section 3.2 describes. The upper two bits in the ASCONF Chunk are set to one. Per [RFC4960], Section 3.2, a receiver that doesn't understand this chunk MUST skip it and keep processing, then report it in an Operation Error Chunk with the 'Unrecognized Chunk Type' cause of error. This will not abort the association, but it does tell the sender that it MUST not send any further ASCONF chunks 🫠
ASCONF Parameter: TLV format 🎀
Each address configuration change is its own TLV parameter, as defined in Section 4.2. One or more requests can be in a single ASCONF Chunk ✨
4.1.2. Address Configuration Acknowledgment Chunk (ASCONF-ACK) 🩷
This chunk is what the receiver of an ASCONF Chunk sends back to say "got it" 💌. It carries zero or more results for any ASCONF parameters the receiver processed. It MUST also be sent authenticated, using the mechanism from [RFC4895], and if it's received unauthenticated it MUST be silently discarded as [RFC4895] describes 🔐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x80 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ .... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sequence Number: 32 bits (unsigned integer) 🔢
This is the Sequence Number of the received ASCONF Chunk being acknowledged. It gets copied straight from that ASCONF Chunk 🪞
ASCONF Parameter Response: TLV format 💬
The ASCONF Parameter Response is how the ASCONF-ACK reports the status of ASCONF processing. By default, if the responding endpoint doesn't include any Error Cause, that means success 🎉. So a sender of an ASCONF-ACK MAY signal complete success for all TLVs by just returning the Chunk Type, Chunk Flags, Chunk Length (set to 8), and the Sequence Number. Super efficient, iconic 👑
4.2. New Parameter Types 🌈
The seven new parameters follow the format from Section 3.2.1 of [RFC4960]. Tables 2, 3, and 4 describe them 📋
Address Configuration Parameters Parameter Type
-------------------------------------------------
Set Primary Address 0xC004
Adaptation Layer Indication 0xC006
Supported Extensions 0x8008
Table 2: Parameters That Can Be Used in an INIT/INIT-ACK Chunk
Address Configuration Parameters Parameter Type
-------------------------------------------------
Add IP Address 0xC001
Delete IP Address 0xC002
Set Primary Address 0xC004
Table 3: Parameters Used in an ASCONF Parameter
Address Configuration Parameters Parameter Type
-------------------------------------------------
Error Cause Indication 0xC003
Success Indication 0xC005
Table 4: Parameters Used in an ASCONF Parameter ResponseAny parameter that shows up where it isn't allowed (like a 0xC002 parameter inside an INIT or INIT-ACK) MAY get an ABORT from the receiver of the invalid parameter 🚨. If the receiver chooses not to abort, the parameter MUST be ignored. A robust implementation SHOULD ignore the parameter and leave the association intact 💪
4.2.1. Add IP Address ➕
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC001 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ASCONF-Request Correlation ID: 32 bits 🆔
This is an opaque integer the sender assigns to identify each request parameter. The receiver of the ASCONF Chunk copies this 2-bit value into the ASCONF Response Correlation ID field of the ASCONF-ACK response parameter. The sender can use this same value in the ASCONF-ACK to find which request the response belongs to. The receiver MUST NOT change this 32-bit value 🔒
Fun fact (and a bit of a plot twist): the text says "2-bit value" in one spot, but the field is 32 bits and the same sentence elsewhere says 32-bit. Bestie, the RFC is being a little messy here 🙈
Address Parameter: TLV 🏠
This field holds an IPv4 or IPv6 address parameter, as described in Section 3.3.2.1 of [RFC4960]. The whole TLV gets wrapped inside this parameter. It tells the receiver that the address is to be added to the existing association. This parameter MUST NOT contain a broadcast or multicast address. If the address 0.0.0.0 or ::0 is provided, the source address of the packet MUST be added 🌟
Here's an example TLV asking that the IPv4 address 192.0.2.1 be added to the association 🧚
+--------------------------------+
| Type=0xC001 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023474 |
+--------------------------------+
| Type=5 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+Valid Chunk Appearance 📦
The Add IP Address parameter may only appear in the ASCONF Chunk type 💖
4.2.2. Delete IP Address 🗑️
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC002 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ASCONF-Request Correlation ID: 32 bits 🆔
This is an opaque integer the sender assigns to identify each request parameter. The receiver of the ASCONF Chunk copies this 32-bit value into the ASCONF Response Correlation ID field of the ASCONF-ACK response parameter. The sender can use this same value in the ASCONF-ACK to find which request the response is for. The receiver MUST NOT change this 32-bit value 🔒
Address Parameter: TLV 🏠
This field holds an IPv4 or IPv6 address parameter, as described in Section 3.3.2.1 of [RFC4960]. The whole TLV gets wrapped inside this parameter. It tells the receiver that the address is to be removed from the existing association. This parameter MUST NOT contain a broadcast or multicast address. If the address 0.0.0.0 or ::0 is provided, all addresses of the peer except the source address of the packet MUST be deleted 💀
Here's an example TLV deleting the IPv4 address 192.0.2.1 from an existing association 🦋
+--------------------------------+
| Type=0xC002 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Type=5 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+Valid Chunk Appearance 📦
The Delete IP Address parameter may only appear in the ASCONF Chunk type 🫶
4.2.3. Error Cause Indication ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC003 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Cause(s) or Success Indication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ASCONF-Response Correlation ID: 32 bits
okay so this is an opaque integer that the sender picks to tag each request parameter 🎀 when the ASCONF Chunk arrives, the receiver copies that 32-bit value from the ASCONF-Request Correlation ID into the ASCONF Response Correlation ID field, so the peer can match the request to its response like a total pro 🧚 bestie, the receiver MUST NOT change this 32-bit value 🚫 no editing allowed!!
Error Cause(s): TLV(s)
when something goes wrong, this response parameter wraps up one or more standard Error Causes 💌 those are the same ones you'd normally find inside an SCTP Operational Error or SCTP Abort (defined in [RFC4960]). the Error Cause(s) follow the format defined in Section 3.3.10 of [RFC4960] 📖
Valid Chunk Appearance
the Error Cause Indication parameter may only appear in the ASCONF-ACK Chunk Type 🦋
4.2.4. Set Primary IP Address 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC004 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ASCONF-Request Correlation ID: 32 bits
same vibe as before 💅 this is an opaque integer the sender assigns to tag each request parameter. the receiver of the ASCONF Chunk copies this 32-bit value into the ASCONF Response Correlation ID field of the ASCONF-ACK response parameter, and the sender can use that same value in the ASCONF-ACK to figure out which request the response belongs to 🔍 again, the receiver MUST NOT change this 32-bit value, no exceptions bestie 🙅♀️
Address Parameter: TLV
this field holds an IPv4 or IPv6 address parameter, exactly as described in Section 3.3.2.1 of [RFC4960] 🌈 the complete TLV gets wrapped up inside this parameter. it's basically asking the receiver to mark the given address as the primary address to send data to (see Section 5.1.2 of [RFC4960]) 👑 the receiver MAY mark this as its primary address once it gets the request. and if the address 0.0.0.0 or ::0 shows up, the receiver MAY mark the source address of the packet as its primary 🧚
here's an example TLV asking for the IPv4 address 192.0.2.1 to become the primary destination address, and it's giving very clear vibes 🫶
+--------------------------------+
| Type=0xC004 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023479 |
+--------------------------------+
| Type=5 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+Valid Chunk Appearance
the Set Primary IP Address parameter may appear in the ASCONF, the INIT, or the INIT-ACK Chunk Type 🎀 putting it in the INIT or INIT-ACK can be used to show an initial preference for the primary address, which is so thoughtful 🥹
4.2.5. Success Indication 💖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC005 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ngl the default here is so chill 😌 if a responding endpoint doesn't report an error for a requested TLV, success is just implied. so a sender of an ASCONF-ACK MAY signal complete success for every TLV in an ASCONF by only sending back the Chunk Type, Chunk Flags, Chunk Length (set to 8), and the Sequence Number ✨ no extra baggage needed!
the responding endpoint MAY also choose to explicitly report success for a requested TLV, by sending back a success report ASCONF Parameter Response 🙌
ASCONF-Response Correlation ID: 32 bits
this is an opaque integer the sender assigned to identify each request parameter 🌸 the receiver of the ASCONF Chunk copies this 32-bit value from the ASCONF-Request Correlation ID into the ASCONF Response Correlation ID field, so the peer can easily match the request to this response 💜
Valid Chunk Appearance
the Success Indication parameter may only appear in the ASCONF-ACK Chunk Type 🦋
4.2.6. Adaptation Layer Indication 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+this parameter is for talking to peer upper-layer protocols 🗣️ it's envisioned for flow control and other adaptation layers that need an indication carried in the INIT and INIT-ACK. every adaptation layer that wants to use it MUST specify an adaptation code point in an appropriate RFC that defines its use and meaning 📜 the SCTP implementation SHOULD NOT examine this parameter, and it should just get passed along opaquely to the upper-layer protocol 🫠 not its job, not its drama!
Note: This parameter isn't used for adding or deleting addresses at all. It's just here for the convenience of the upper layer. This document includes it so we don't have to make extra SCTP documents 📚
Valid Chunk Appearance
the Adaptation Layer Indication parameter may appear in an INIT or INIT-ACK chunk, and it SHOULD be passed up to the receiver's upper-layer protocol based on the upper-layer protocol configuration of the SCTP stack 🎀 it MUST NOT be sent in any other chunks, and if it shows up in another chunk anyway, it MUST be ignored 🙈
4.2.7. Supported Extensions Parameter 🧚
this parameter is used at startup to tell the peer about any extra extensions the sender supports 💫 the sender MUST support both sending and receiving any chunk types listed in the Supported Extensions Parameter. an implementation that supports this extension MUST list the ASCONF,the ASCONF-ACK, and the AUTH chunks in its INIT and INIT-ACK parameters 🔥
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8008 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE N | PAD | PAD | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Parameter Type: this field holds the IANA-defined parameter type for the Supported Extensions Parameter. its value is 0x8008 💖
Parameter Type Length: this field holds the length of the parameter, counting the Parameter Type, Parameter Length, and any supported extensions. ⚠️ the length MUST NOT include any padding, so don't sneak it in there!
CHUNK TYPE X: these field(s) hold the chunk type of any SCTP extension(s) the sending SCTP currently supports. you can list multiple chunk types, one for each extra feature the sender supports 🌈 the sender MUST NOT include multiple Supported Extensions Parameters within any chunk.
Parameter Appearance: this parameter may appear in the INIT or INIT-ACK chunk. it MUST NOT appear in any other chunk 🙅♀️
4.3. New Error Causes 💥
five new Error Causes get added to the SCTP Operational Errors, mainly for use in the ASCONF-ACK Chunk 🎉
Cause Code
Value Cause Code
--------- ----------------
0x00A0 Request to Delete Last Remaining IP Address
0x00A1 Operation Refused Due to Resource Shortage
0x00A2 Request to Delete Source IP Address
0x00A3 Association Aborted Due to Illegal ASCONF-ACK
0x00A4 Request Refused - No Authorization
Table 5: New Error Causes4.3.1. Error Cause: Request to Delete Last Remaining IP Address 🚨
Cause of error
Request to Delete Last Remaining IP Address: the receiver of this error sent a request to delete the last IP address from its association with its peer 😱 this error tells you the request got rejected, so no deleting your last address, bestie!
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A0 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what a failed delete looks like inside an Error Cause TLV in the response ASCONF-ACK message 🎀
+--------------------------------+
| Type = 0xC003 | Length = 28 |
+----------------+---------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Cause=0x00A0 | Length = 20 |
+----------------+---------------+
| Type= 0xC002 | Length = 16 |
+----------------+---------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Type=0x0005 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+4.3.2. Error Cause: Operation Refused Due to Resource Shortage 🫶
Okay bestie, this one's for when the receiver tries to do the thing but is totally out of room 😭 It's a Cause of error, and it basically says "sorry, not enough resources rn" 💀 The whole TLV that got refused gets copied from the ASCONF into the Error Cause 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A1 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what a failed addition looks like inside the response ASCONF-ACK message 🦋
+--------------------------------+
| Type = 0xC003 | Length = 28 |
+--------------------------------+
| C-ID = 0x01023474 |
+--------------------------------+
| Cause=0x00A1 | Length = 20 |
+----------------+---------------+
| Type=0xC001 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023474 |
+--------------------------------+
| Type=0x0005 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+4.3.3. Error Cause: Request to Delete Source IP Address 🙅♀️
Okay so this one is giving "you can't delete the address I just sent this from" 👀 Cause of error: the receiver of this error sent a request to delete the source IP address of the ASCONF message, and this error says that request got rejected. Period 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A2 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's an example of a failed delete in an Error Cause TLV, as it'd show up in the response ASCONF-ACK message 🌸
+--------------------------------+
| Type = 0xC003 | Length = 28 |
+--------------------------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Cause=0x00A2 | Length = 20 |
+----------------+---------------+
| Type=0xC002 | Length = 16 |
+----------------+---------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Type=0x0005 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+IMPLEMENTATION NOTE: It is unlikely that an endpoint would source a packet from the address being deleted, unless the endpoint does not do proper source address selection. 🧐
4.3.4. Error Cause: Association Aborted Due to Illegal ASCONF-ACK 💥
This one's dramatic, ngl 😭 It goes inside an ABORT that gets generated when an ASCONF-ACK shows up that nobody was expecting but that is larger than the current Sequence Number (see Section 5.3, Rule F0). Note that a Sequence Number counts as larger than the last acked Sequence Number if it's either the next sequence or no more than 2**31-1 greater than the current Sequence Number. Sequence Numbers smaller than the last acked Sequence Number are silently ignored 🤫
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A3 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3.5. Error Cause: Request Refused - No Authorization. 🔒
Cause of error: this Error Cause may be included to reject a request based on local security policies. So basically the box said no because of its own rules 🚫
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A4 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5. Procedures ✨
This section is where we get into the nitty-gritty 🤓 It lays out the specific procedures for the address-configuration change chunk type and how that chunk gets processed.
5.1. ASCONF Chunk Procedures 💖
When an endpoint has an ASCONF signaled change to send to the remote endpoint, it MUST do the following:
A1) Create an ASCONF Chunk as defined in Section 4.1.1. The chunk MUST contain all of the TLV(s) of information needed to be sent to the remote endpoint, along with unique correlation identities for each request 🎀
A2) A Sequence Number MUST be assigned to the Chunk. The Sequence Number MUST be larger by one. The Sequence Number MUST be initialized at the start of the association to the same value as the Initial Transmission Sequence Number (TSN), and every time a new ASCONF Chunk is created, it MUST be incremented by one after the Sequence Number gets assigned to the newly created chunk 🔢
A3) If no SCTP packet with one or more ASCONF Chunk(s) is outstanding (unacknowledged) with the remote peer, send the chunk and move on to step A4. If an ASCONF chunk is outstanding, then the ASCONF chunk should be queued for later transmission, and no further action should be taken until the previous ASCONF is acknowledged or a timeout occurs ⏳
A4) The sender MUST Start a T-4 Retransmission Timeout (RTO) timer, using the RTO value of the selected destination address (normally the primary path; see [RFC4960], Section 6.4 for details) ⏰
A5) When the ASCONF-ACK that acknowledges the Sequence Number last sent arrives, the sender MUST stop the T-4 RTO timer, and clear the appropriate association and destination error counters as defined in [RFC4960], Sections 8.1 and 8.2 🧹
A6) The endpoint MUST process all of the TLVs within the ASCONF-ACK(s) to find out the particular status information returned for the various requests that were sent. Use the Correlation IDs to match up the requests and the responses 🔍
A7) If an error response is received for a TLV parameter, all TLVs with no response before the failed TLV are considered successful if not reported. All TLVs after the failed response are considered unsuccessful unless a specific success indication is present for the parameter 😬
A8) If there is no response to specific TLV parameter(s), and no failures are indicated, then all request(s) are considered successful ✅
A9) If the peer responds to an ASCONF with an ERROR Chunk reporting that it did not recognize the ASCONF Chunk Type, the sender of the ASCONF MUST NOT send any further ASCONF Chunks and MUST stop its T-4 timer. Hard stop, no notes 🛑
If the T-4 RTO timer expires, the endpoint MUST do the following:
B1) Increment the error counters and perform path failure detection on the appropriate destination address as defined in [RFC4960], Sections 8.1 and 8.2 📉
B2) Increment the association error counters and perform endpoint failure detection on the association as defined in [RFC4960], Sections 8.1 and 8.2 📉
B3) Back off the destination address RTO value that the ASCONF chunk was sent to by doubling the RTO timer value 📈
Note: The RTO value is used in the setting of all timer types for SCTP. Each destination address has a single RTO estimate. 💜
B4) Re-transmit the ASCONF Chunk last sent, and if possible choose an alternate destination address (please refer to [RFC4960], Section 6.4.1). An endpoint MUST NOT add new parameters to this chunk. It MUST be the same (including its Sequence Number) as the last ASCONF sent. An endpoint MAY, however, bundle an additional ASCONF with new ASCONF parameters with the next Sequence Number. For details, see Section 5.5 🔁
B5) Restart the T-4 RTO timer. Note that if a different destination is selected, then the RTO used will be that of the new destination address 🔄
Note: The total number of retransmissions is limited by B2 above. If the maximum is reached, the association will fail and enter into the CLOSED state (see [RFC4960], Section 6.4.1 for details). 💀
5.1.1. Congestion Control of ASCONF Chunks 🦋
okay so bestie, when we're defining how ASCONF Chunk transfers work, it is literally essential that these transfers MUST NOT cause congestion within the network 😭 no cap, we do not want the internet clogging up. so here are the restrictions we put on sending ASCONF Chunks 💅
C1) One and only one SCTP packet-holding ASCONF Chunk(s) MAY be in transit and unacknowledged at any one time. If a sender, after sending an ASCONF chunk, decides it needs to transfer another ASCONF Chunk, it MUST wait until the ASCONF-ACK Chunk returns from the previous ASCONF Chunk before sending a subsequent ASCONF. Note: This restriction binds each side, so at any time, two ASCONF may be in-transit on any given association (one sent from each endpoint). However, when an ASCONF Chunk is retransmitted due to a time-out, the additionally held ASCONF Chunks can be bundled into the retransmission packet as described in Section 5.5. 🎀
C2) An ASCONF Chunk may be bundled with any other chunk type including other ASCONF Chunks. If bundled with other ASCONF Chunks, the chunks MUST appear in sequential order with respect to their Sequence Number. 🧚
C3) An ASCONF-ACK Chunk may be bundled with any other chunk type including other ASCONF-ACK Chunks. If bundled with other ASCONF-ACK Chunks, the chunks MUST appear in sequential order with respect to their Sequence Number. 🌸
C4) Both ASCONF and ASCONF-ACK Chunks MUST NOT be sent in any SCTP state except ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED, and SHUTDOWN-SENT. 🚫
C5) An ASCONF Chunk and an ASCONF-ACK Chunk SHOULD not be larger than the PMTU. If the PMTU is unknown, then the PMTU should be set to the minimum PMTU. The minimum PMTU depends on the IP version used for transmission, and is the lesser of 576 octets and the first-hop MTU for IPv4 [RFC1122] and 1280 octets for IPv6 [RFC2460]. 📏
An ASCONF sender without these restrictions could possibly flood the network with a large number of separate address-change operations, thus causing network congestion. That's the whole reason we're being this strict 🙈
If the sender of an ASCONF Chunk receives an Operational Error indicating that the ASCONF Chunk Type is not understood, then the sender MUST NOT send subsequent ASCONF Chunks to the peer. The endpoint should also inform the upper-layer application that the peer endpoint does not support any of the extensions detailed in this document. 💀
5.2. Upon Reception of an ASCONF Chunk 🧐
okay, so when an endpoint gets an ASCONF Chunk from the remote peer, sometimes it needs special procedures to figure out which association the ASCONF Chunk belongs to. to properly find the association, the following procedures SHOULD be followed 🔍
D1) Use the source address and port number of the sender to attempt to identify the association (i.e., use the same method defined in [RFC4960] used for all other SCTP Chunks). If found, proceed to rule D4. 💖
D2) If the association is not found, use the address found in the Address Parameter TLV combined with the port number found in the SCTP common header. If found, proceed to rule D4. ✨
D2-ext) If more than one ASCONF Chunks are packed together, use the address found in the ASCONF Address Parameter TLV of each of the subsequent ASCONF Chunks. If found, proceed to rule D4. 🫶
D3) If neither D1, D2, nor D2-ext locates the association, treat the chunk as an Out Of The Blue packet as defined in [RFC4960]. 👻
D4) Follow the normal rules to validate the SCTP verification tag found in [RFC4960]. 🔐
D5) After the verification tag has been validated, normal chunk processing should occur. Prior to finding the ASCONF chunk, the receiver MUST encounter an AUTH chunk as described in [RFC4895]. If either authentication fails, or the AUTH chunk is missing, the receiver MUST silently discard this chunk and the rest of the packet. 🛑
After identification and verification of the association, the following should be performed to properly process the ASCONF Chunk:
E1) If the value found in the Sequence Number of the ASCONF Chunk is equal to the ('Peer-Sequence-Number' + 1) and the Sequence Number of the ASCONF Chunk is the first in the SCTP Packet, the endpoint MAY clean any old cached ASCONF-ACK up to the 'Peer-Sequence-Number' and then proceed to rule E4. 🧹
E1-ext) If the value found in the Sequence Number of the ASCONF Chunk is equal to the ('Peer-Sequence-Number' + 1) and the ASCONF chunk is NOT the first Sequence Number in the SCTP packet, proceed to rule E4 but do NOT clear any cached ASCONF- ACK or state information. 🙅♀️
E2) If the value found in the Sequence Number is less than the ('Peer- Sequence-Number' + 1), simply skip to the next ASCONF, and include in the outbound response packet any previously cached ASCONF-ACK response that was sent and saved that matches the Sequence Number of the ASCONF. Note: It is possible that no cached ASCONF-ACK Chunk exists. This will occur when an older ASCONF arrives out of order. In such a case, the receiver should skip the ASCONF Chunk and not include ASCONF-ACK Chunk for that chunk. 🕰️
E3) Then, process each ASCONF one by one as above while the Sequence Number of the ASCONF is less than the ('Peer-Sequence-Number' + 1). 🔁
E4) When the Sequence Number matches the next one expected, process the ASCONF as described below and after processing the ASCONF Chunk, append an ASCONF-ACK Chunk to the response packet and cache a copy of it (in the event it later needs to be retransmitted). 📦
V1) Process the TLVs contained within the Chunk performing the appropriate actions as indicated by each TLV type. The TLVs MUST be processed in order within the Chunk. For example, if the sender puts 3 TLVs in one chunk, the first TLV (the one closest to the Chunk Header) in the Chunk MUST be processed first. The next TLV in the chunk (the middle one) MUST be processed second and finally, the last TLV in the Chunk MUST be processed last. 1️⃣
V2) In processing the chunk, the receiver should build a response message with the appropriate error TLVs, as specified in the Parameter type bits, for any ASCONF Parameter it does not understand. To indicate an unrecognized parameter, Cause Type 8 should be used as defined in the ERROR in Section 3.3.10.8, [RFC4960]. The endpoint may also use the response to carry rejections for other reasons, such as resource shortages, etc., using the Error Cause TLV and an appropriate error condition. 📝
Note: A positive response is implied if no error is indicated by the sender. 👍
V3) All responses MUST copy the ASCONF-Request Correlation ID field received in the ASCONF parameter from the TLV being responded to, into the ASCONF-Request Correlation ID field in the response parameter. 🪞
V4) After processing the entire Chunk, the receiver of the ASCONF MUST queue the response ASCONF-ACK Chunk for transmission after the rest of the SCTP packet has been processed. This allows the ASCONF-ACK Chunk to be bundled with other ASCONF-ACK Chunks as well as any additional responses, e.g., a Selective Acknowledgment (SACK) Chunk. 🎁
V5) Update the 'Peer-Sequence-Number' to the value found in the Sequence Number field. ⏭️
E5) Otherwise, the ASCONF Chunk is discarded since it must be either a stale packet or from an attacker. A receiver of such a packet MAY log the event for security purposes. 🚨
E6) When all ASCONF Chunks are processed for this SCTP packet, send back the accumulated single response packet with all of the ASCONF-ACK Chunks. The destination address of the SCTP packet containing the ASCONF-ACK Chunks MUST be the source address of the SCTP packet that held the ASCONF Chunks. 📬
E7) While processing the ASCONF Chunks in the SCTP packet, if the response packet will exceed the PMTU of the return path, the receiver MUST stop adding additional ASCONF-ACKs into the response packet but MUST continue to process all of the ASCONF Chunks, saving ASCONF-ACK Chunk responses in its cached copy. The sender of the ASCONF Chunk will later retransmit the ASCONF Chunks that were not responded to, at which time the cached copies of the responses that would NOT fit in the PMTU can be sent to the peer. 🧃
Note: These rules have been presented with the assumption that the implementation is caching old ASCONF-ACKs in case of loss of SCTP packets in the ACK path. It is allowable for an implementation to maintain this state in another form it deems appropriate, as long as that form results in the same ASCONF-ACK sequences being returned to the peer as outlined above. 🧠✨
5.3. General Rules for Address Manipulation ✨
okay bestie, this is the rulebook for adding and deleting IP addresses 📖💅 whenever you build the TLV parameters for an ASCONF Chunk, these rules MUST be applied, no exceptions 🫶
F0) if an endpoint gets an ASCONF-ACK that's greater than or equal to the next Sequence Number to be used but there's no ASCONF Chunk outstanding, the endpoint MUST ABORT the association 💀 quick note: a Sequence Number counts as "greater than" if it's no more than 2^^31-1 larger than the current Sequence Number, using serial arithmetic 🧮
F1) when you add an IP address to an association, that address is not fully added until the ASCONF-ACK shows up 🌸 so until the ASCONF with the add gets acknowledged, the sender MUST NOT use the new IP address as a source for ANY SCTP packet except one carrying an ASCONF Chunk 🙈 the receiver of the Add IP Address request may use the address as a destination right away ✨ but the receiver MUST use the path-verification procedure for the added address before using that address 🦋 the receiver MUST NOT send packets to the new address except for the matching ASCONF-ACK Chunk or HEARTBEAT Chunks for path verification before the new path is verified 💜 and if the ASCONF-ACK is sent to the new address, it MAY be bundled with the HEARTBEAT chunk for path verification 🧚
F2) after the ASCONF-ACK of an IP address Add arrives, the endpoint MAY start using the added IP address as a source address for any type of SCTP chunk 🎀
F3a) if an endpoint gets an Error Cause TLV saying the IP address Add or IP address Deletion parameters weren't understood, the endpoint MUST consider the operation failed and MUST NOT try to send any more Add or Delete requests to the peer 🚫
F3b) if an endpoint gets an Error Cause TLV saying the IP address Set Primary IP Address parameter wasn't understood, the endpoint MUST consider the operation failed and MUST NOT try to send any more Set Primary IP Address requests to the peer 🙅♀️
F4) when you delete an IP address from an association, that address MUST still count as a valid destination for receiving SCTP packets until the ASCONF-ACK arrives 🫠 but it MUST NOT be used as a source address for any later packets ✨ so any datagrams that show up before the ASCONF-ACK and are destined to the address being deleted MUST be treated as part of the current association 🦋 one special thing: ABORT Chunks arriving at the IP address being deleted MUST be ignored (see Section 5.3.1 for the deets) 🙈
F5) an endpoint MUST NOT delete its last remaining IP address from an association 🚨 in other words, if an endpoint is not multi-homed, it MUST NOT use the delete IP address without an Add IP Address before the delete parameter in the ASCONF Chunk 💅 and if an endpoint sends multiple requests to delete IP addresses, it MUST NOT delete all of the IP addresses that the peer has listed for the requester 🫶
F6) an endpoint MUST NOT set the IP header source address for an SCTP packet holding the ASCONF Chunk to be the same as an address being deleted by that ASCONF Chunk 🌈
F7) if a request comes in to delete the last remaining IP address of a peer endpoint, the receiver MUST send an Error Cause TLV with the Error Cause set to the new error code 'Request to Delete Last Remaining IP Address' 😭 the requested delete MUST NOT be performed or acted upon, other than to send the ASCONF-ACK 💖
F8) if a request comes in to delete an IP address that is also the source address of the IP packet containing the ASCONF chunk, the receiver MUST reject it 🙅♀️ to reject it, the receiver MUST send an Error Cause TLV set to the new error code 'Request to Delete Source IP Address' (unless Rule F5 was also broken, in which case the error code 'Request to Delete Last Remaining IP Address' gets sent instead) 🍓
F9) if an endpoint gets an ADD IP Address request and doesn't have the local resources to add this new address to the association, it MUST return an Error Cause TLV set to the new error code 'Operation Refused Due to Resource Shortage' 🥺
F10) if an endpoint gets an 'Out of Resource' error in response to its request to ADD an IP address to an association, it must either ABORT the association or not consider the address part of the association 🌸 put simply, if it doesn't ABORT, it must treat the add attempt as failed and not use this address, since its peer will treat SCTP packets destined to the address as Out Of The Blue packets 👑
F11) when an endpoint receives an ASCONF to add an IP address and sends back an 'Out of Resource' in its response, it MUST also fail any later add or delete requests bundled in the ASCONF 🫠 the receiver MUST NOT reject an ADD and then accept a later DELETE of an IP address in the same ASCONF Chunk 🙈 so basically, once a receiver starts failing any ADD or DELETE request, it must fail all the later ADD or DELETE requests in that single ASCONF 🎀
F12) when an endpoint gets a request to delete an IP address that is the current primary address, it's an implementation decision how that endpoint picks the new primary address 🧠
F13) when an endpoint gets a valid request to DELETE an IP address, the endpoint MUST consider the address no longer part of the association 🚪 it MUST NOT send SCTP packets for the association to that address, and it MUST treat any later packets received from that address as Out Of The Blue 👻
During the time between sending the ASCONF and receiving the ASCONF-ACK, it MAY be possible to receive DATA Chunks out of order 🌀 the following examples show these problems:
F14) all addresses added by receiving an ASCONF Chunk MUST be put into the UNCONFIRMED state, and MUST have path verification performed on them before the address can be used as described in [RFC4960], Section 5.4 🔍
Endpoint-A Endpoint-Z ---------- ---------- ASCONF[Add-IP:X]------------------------------> /--ASCONF-ACK / /--------/---New DATA: / / Destination <-------------------/ / IP:X / <--------------------------/
In the example above, a new IP address (X) is being added to Endpoint-A 🌟 but because of packet re-ordering in the network, a new DATA chunk is sent and arrives at Endpoint-A before the ASCONF-ACK confirms the add to the association 😱
A similar problem happens with deleting an IP address, like this:
Endpoint-A Endpoint-Z ---------- ---------- /------------New DATA: / Destination / IP:X ASCONF [DEL-IP:X]---------/----------------> <-----------------/------------------ASCONF-ACK / / <-------------/
In this one, a DATA chunk destined to IP:X (the one about to be deleted) shows up after the deletion is already complete 🫣 for the ADD case, an endpoint SHOULD consider the newly added IP address for sending data to the association before the ASCONF-ACK has been received 🦋 the endpoint MUST NOT source data from this new address until the ASCONF-ACK arrives, but it may receive out-of-order data like the example shows, and it MUST NOT treat this data as an OOTB datagram (please see [RFC4960] section 8.4) 💜 it MAY drop the data silently, or it MAY treat it as part of the association, but it MUST NOT respond with an ABORT 🤫
For the DELETE case, an endpoint MAY respond to the late DATA packet as an OOTB datagram, or it MAY keep the deleting IP address valid for a small period of time 🕰️ if it treats the DATA packet as OOTB, the peer will silently discard the ABORT (since by the time the ABORT is sent, the peer will have removed the IP address from this association) 🫶 if the endpoint chooses to keep the IP address valid for a while, it MUST NOT keep it valid for longer than 2 RTO intervals for the destination being removed ⏱️
5.3.1. A Special Case for OOTB ABORT Chunks 🎭
Another case worth knowing about is shown below:
Endpoint-A Endpoint-Z ---------- ----------
New DATA:------------\ Source IP:X \ \ ASCONF-REQ[DEL-IP:X]----------------------> \ /---------ASCONF-ACK \ / ----/-----------> OOTB (Ignored <---------------------/-------------ABORT by rule F4) / <---------------------/
For this case, while an IP address is being deleted, an Abort MUST be ignored if the destination address of the Abort message is that of a destination being deleted 🙈
5.3.2. A Special Case for Changing an Address 🦋
Sometimes the sender may only have one IP address in an association that's getting renumbered 🥹 when that happens, the sender may not be able to send the right ADD/DELETE pair to the peer, and it may use the old address as a source in the IP header 😵💫 for this reason, the sender MUST fill in the Address Parameter field with an address that is part of the association (in this case, the one being deleted) ✨ that lets the receiver find the association without using the source address from the IP header 💖
The receiver of such a chunk MUST always first use the source address found in the IP header to look up the association 🔍 the receiver should try the address in the Address Parameter field only if the lookup using the IP header's source address fails 🫶 the receiver MUST reply to the source address of the packet in this case, which is the new address that the ASCONF added (since the old address is no longer part of the association after processing) 🌈
5.4. Setting of the Primary Address ✨
Okay bestie, so a sender of the set primary parameter MAY send it combined with an add or delete of an address 💅. But here's the tea 🫖: a sender MUST only send a set primary request to an address that is already considered part of the association 🫶. If you bundle a set primary with an add new IP address request, the set primary gets discarded unless the add request is going to be processed BEFORE the set primary (aka it comes first) 😭.
A request to set primary MAY also show up in an INIT or INIT-ACK chunk 🦋. In that case it's like advice for the other endpoint about which of the sender's addresses the sender would prefer as the primary address 🌸.
Setting the primary path is an option the receiver SHOULD perform 💖. It's advice about the best-destination address to use when sending SCTP packets, from the requester's point of view ✨. If a request asks the receiver to make a nonexistent address primary, the receiver SHOULD NOT honor it, and the existing primary address just stays put 🙈.
5.5. Bundling of Multiple ASCONFs 🎀
Normally you send one ASCONF in a packet and get one ASCONF-ACK back 💜. But if an SCTP packet with an ASCONF or ASCONF-ACK gets lost, the sender is allowed to bundle extra ASCONFs into the retransmission 🧚. When you bundle, these rules MUST be followed:
- Previously transmitted ASCONF Chunks MUST be left unchanged.
- Each SCTP packet containing ASCONF Chunks MUST be bundled starting with the smallest ASCONF Sequence Number first in the packet (closest to the Chunk header) and preceding in sequential order from the lowest to highest ASCONF Sequence Number.
- All ASCONFs within the packet MUST be adjacent to each other, i.e., no other chunk type must separate the ASCONFs.
- Each new ASCONF lookup address MUST be populated as if the previous ASCONFs had been processed and accepted.
6. Security Considerations 🚨
Okay this one is SERIOUS, so pay attention 🙈. Adding or deleting an IP address on an existing association is an extra way existing associations can get hijacked 💀. So this document requires the use of the authentication mechanism defined in [RFC4895] to limit how much an attacker can hijack an association 🔐.
Hijacking an association with address adds and deletes is only possible for an attacker who can intercept the initial two packets of the association setup, and that's when the SCTP-AUTH extension is used without pre-shared keys 👀. If that threat is a possibility for you, then the [RFC4895] extension MUST be used with a preconfigured shared endpoint pair key to mitigate it 🛡️. For a more detailed analysis, see [RFC4895] 📚.
When the address parameter in ASCONF chunks with Add, IP Delete IP, or Set Primary IP parameters is a wildcard, the source address of the packet is used 🌐. That address is not protected by SCTP-AUTH [RFC4895], so an attacker can intercept such a packet and modify the source address 😱. Even if the source address isn't currently an alternate for the association, the identification of the association may rely on other info in the packet (perhaps the verification tag, for example) 🧩. So an on-path attacker can modify the source address to its liking 💀.
If the ASCONF includes an Add IP with a wildcard address, the attacker can add an address of its liking. That causes little immediate damage, but it can set up later attacks 🕸️.
If the ASCONF includes a Delete IP with a wildcard address, the attacker can cause all addresses but one of its choosing to be deleted from an association 😤. The address supplied by the attacker must already belong to the association, which makes this harder for the attacker. However, the sole remaining address might be one the attacker controls, or can monitor, etc. At the least, the sender and the deceived receiver would have different ideas of what that sole remaining address is. This will eventually cause the association to fail, but in the meantime, the deceived receiver could be transmitting packets to an address the sender did not intend 📦.
If the ASCONF includes a Set Primary IP with a wildcard address, then the attacker can cause an address to be used as a primary address 🎭. This is limited to an address that already belongs to the association, so the damage is limited. At the least, the recipient ends up using a primary address the sender did not intend. However, if both a wildcard Add IP and a wildcard Set Primary IP are used, the attacker can modify the source address to both add an address to its liking to the association and make it the primary address. That combo gives the attacker a chance to do way more damage 😭🔥.
Note that all these attacks are from an on-path attacker. Endpoints that believe they face a threat from on-path attackers SHOULD NOT use wildcard addresses in ASCONF Add IP, Delete IP, or Set Primary IP parameters 🚫.
If an SCTP endpoint that supports this extension receives an INIT that indicates the peer supports the ASCONF extension but does NOT support the [RFC4895] extension, the receiver of that INIT MUST send an ABORT in response 🛑. An implementation is allowed to silently discard that INIT as an option too, but under NO circumstance is an implementation allowed to proceed with the association setup by sending an INIT-ACK in response 🙅♀️.
An implementation that receives an INIT-ACK indicating the peer does not support the [RFC4895] extension MUST NOT send the COOKIE-ECHO to establish the association 🚷. Instead, the implementation MUST discard the INIT-ACK and report to the upper-layer user that an association cannot be established, destroying the Transmission Control Block (TCB) 🗑️.
Other types of attacks, e.g., bombing, are discussed in detail in [RFC5062] 💣. The bombing attack in particular is countered by the use of a random nonce, and that nonce is required by [RFC4960] 🎲.
An on-path attacker can modify the INIT and INIT-ACK Supported Extensions parameter (and authentication-related parameters) to cause a denial of service 😵. If the on-path attacker removes the [RFC4895]-related parameters from an INIT that indicates it supports the ASCONF extension, the association will not be established. If the on-path attacker adds a Supported Extensions parameter mentioning the ASCONF type to an INIT or INIT-ACK that doesn't carry any AUTH-related parameters, the association will not be established. If the on-path attacker removes the Supported Extensions parameter (or removes the ASCONF type from that parameter) from the INIT or the INIT-ACK, the association won't be able to use the ADD-IP feature. If the on-path attacker adds the Supported Extensions parameter listing the ASCONF type to an INIT-ACK that didn't carry one (but did carry AUTH-related parameters), then the INIT sender may use ASCONF where the INIT-ACK sender doesn't support it. That would be discovered later if the INIT sender transmitted an ASCONF, but by then the INIT sender could already have made configuration choices 🫠. Since the INIT and INIT-ACK aren't protected by the AUTH feature, there is no way to counter such attacks 😤. Note, however, that an on-path attacker capable of modifying the INIT and INIT-ACK would almost certainly also be able to prevent those chunks from being delivered, or modify the verification tags or checksum to cause the packet to be discarded. So the Supported Extensions parameter adds little additional vulnerability (with respect to preventing association formation) to the SCTP protocol. The ability to prevent use of this new feature is an additional vulnerability to SCTP, but only for this new feature 🧐.
The Adaptation Layer Indication is subject to corruption, insertion, or deletion from the INIT and INIT-ACK chunks by an on-path attacker 🧌. This parameter SHOULD be opaque to the SCTP protocol (see Section 4.2.6), so changes to it will likely not affect SCTP itself 🫧. However, any adaptation layer that is defined SHOULD consider its own vulnerabilities in the Security Considerations section of the RFC that defines its adaptation code point 📝.
The Set Primary IP Address parameter is subject to corruption, insertion, or deletion by an on-path attacker when it's included in the INIT and INIT-ACK chunks 😬. The attacker could use this to influence the receiver to choose an address that serves the attacker's purposes (one it controls, one that would be less desirable for the sender, etc.). An on-path attacker can also include or remove addresses for the association from the INIT or INIT-ACK, so it isn't limited in the address it can specify in the Set Primary IP Address 🕵️. Endpoints that wish to avoid this possible threat MAY defer sending the initial Set Primary request, and wait until the association is fully established before sending a fully protected ASCONF with the Set Primary as its single parameter 🔒✨.
7. IANA Considerations 📋
This document defines the following new SCTP parameters, chunks, and errors (http://www.iana.org/assignments/sctp-parameters) 🎀:
- two new chunk types,
- six parameter types, and
- five new SCTP error causes.
The chunk types with their assigned values are shown below 🦋:
Chunk Type Chunk Name
--------------------------------------------------------------
0xC1 Address Configuration Change Chunk (ASCONF)
0x80 Address Configuration Acknowledgment (ASCONF-ACK)The parameter types are listed below 💜:
Parameter Type Parameter Name
-------------------------------------------------
0x8008 Supported Extensions
0xC001 Add IP Address
0xC002 Delete IP Address
0xC003 Error Cause Indication
0xC004 Set Primary Address
0xC005 Success Indication
0xC006 Adaptation Layer IndicationThe Error Causes are listed below 🌸:
Cause Code
Value Cause Code
--------- ----------------
0x00A0 Request to Delete Last Remaining IP Address
0x00A1 Operation Refused Due to Resource Shortage
0x00A2 Request to Delete Source IP Address
0x00A3 Association Aborted Due to Illegal ASCONF-ACK
0x00A4 Request Refused - No AuthorizationThis document also defines an adaptation code point 🧚. The adaptation code point is a 32-bit integer that is assigned by IANA through an IETF Consensus action as defined in [RFC2434]. For this new registry, no initial values are being added by this document. However, [RDDP] will add the first entry 🌈.
8. Acknowledgments ✨
okay bestie, big thank you energy 🫶 The authors want to give a special shoutout to Michael Ramahlo and Phillip Conrad for their extreme efforts in the early formation of this draft 💖
The authors also thank Jon Berger, Mark Butler, Lars Eggert, Janardhan Iyengar, Greg Kendall, Seok Koh, Salvatore Loreto, Peter Lei, John Loughney, Sandy Murphy, Ivan Arias Rodriguez, Renee Revis, Marshall Rose, Ronnie Sellars, Chip Sharp, and Irene Ruengeler for their invaluable comments 🌸
Maria-Carmen Belinchon and Ian Rytina also get a special mention for their early contributions to this document and their thoughtful comments 🧚
And a super special thanks to James Polk, abstract writer to the few but lucky 💅👑
9. References 📚
9.1. Normative References
These are the ones you really need to read, no cap 🔥
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, August 2007.9.2. Informative References
These are the extra-credit reads 🧠
[RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security
Attacks Found Against SCTP and Current Countermeasures",
RFC 5062, September 2007.
[RDDP] Bestler, C. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Direct Data Placement (DDP) Adaptation",
Work in Progress, September 2006.Appendix A. Abstract Address Handling 🦋
A.1. General Remarks
Quick heads-up: this appendix is non-normative 🙈 It's here to give you a concise mathematical definition of an SCTP endpoint. The text below is a working definition of the endpoint notion, so we can talk about address reconfiguration without going around in circles. It is not meant to restrict implementations in any way, its goal is just to provide a set of definitions. Using these definitions should make discussing address issues way easier 💖
A.2. Generalized Endpoints
A generalized endpoint is a pair of a set of IP addresses and a port number at any given point of time. The precise definition goes like this:
A generalized endpoint gE at time t is given by
gE(t) = ({IP1, ..., IPn}, Port)where {IP1, ..., IPn} is a non-empty set of IP addresses.
Please note that the dynamic addition and deletion of IP addresses described in this document lets the set of IP addresses of a generalized endpoint change at some point of time. The port number can never be changed 🔒
The set of IP addresses of a generalized endpoint gE at a time t is defined as
Addr(gE)(t) = {IP1, ..., IPn}if gE(t) = ({IP1, ..., IPn}, Port) holds at time t.
The port number of a generalized endpoint gE is defined as
Port(gE) = Portif gE(t) = ({IP1, ..., IPn}, Port) holds at time t.
There is one fundamental rule that restricts all generalized endpoints, and it's giving strict ✨
For two different generalized endpoints gE' and gE'' with the same port number Port(gE') = Port(gE''), the address sets Addr(gE')(t) and Addr(gE'')(t) must be disjoint at every point in time.
A.3. Associations
Associations are made of two generalized endpoints and the two address sets known by the peer at any time 🤝 The precise definition is:
An association A between two different generalized endpoints gE' and gE'' is given by
A = (gE', S', gE'', S'')where S'(t) and S''(t) are sets of addresses at any time t, such that S'(t) is a non-empty subset of Addr(gE')(t) and S''(t) is a non-empty subset of Addr(gE'')(t).
If A = (gE', S', gE'', S'') is an association between the generalized endpoints gE' and gE'', the following notation is used:
Addr(A, gE') = S' and Addr(A, gE'') = S''.If the dependency on time matters, the notation Addr(A, gE')(t) = S'(t) will be used.
If A is an association between gE' and gE'', then Addr(A, gE') is the subset of IP addresses of gE' that gE'' knows about and gE' uses. Main character energy 💅
Association establishment between gE' and gE'' can be seen like this:
- gE' and gE'' do exist before the association.
- If an INIT has to be sent from gE' to gE'', address-scoping rules and other limitations are applied to calculate the subset S' from
Addr(gE'). The addresses of S' are included in the INIT chunk. - If an INIT-ACK has to be sent from gE'' to gE', address-scoping rules and other limitations are applied to calculate the subset S'' from
Addr(gE''). The addresses of S'' are included in the INIT-ACK chunk. - After the handshake, the association
A = (gE', S', gE'', S'')has been established 🎉 - Right after the association establishment,
Addr(A, gE')andAddr(A, gE'')are the addresses that have been seen on the wire during the handshake.
A.4. Relationship with RFC 4960
[RFC4960] defines the notion of an endpoint. This subsection shows that these endpoints are also (special) generalized endpoints, which is so iconic 🦋
[RFC4960] has no notion of address-scoping or other address-handling limitations, and it provides no mechanism to change the addresses of an endpoint.
This means an endpoint is simply a generalized endpoint that does not depend on time. Neither the port nor the address list changes 🧊
During association setup, no address-scoping rules or other limitations are applied. So for an association A between two endpoints gE' and gE'', the following is true:
Addr(A, gE') = Addr(gE') and Addr(A, gE'') = Addr(gE'')A.5. Rules for Address Manipulation
The rules for address manipulation can be stated in a simple way, periodt ✨
- An address can be added to a generalized endpoint gE only if this address is not an address of a different generalized endpoint with the same port number.
- An address can be added to an association A with generalized endpoint gE if it has been added to the generalized endpoint gE first. This means the address must be an element of
Addr(gE)first, and then it can become an element ofAddr(A, gE). But this is not necessary. If the association does not allow the reconfiguration of the addresses, onlyAddr(gE)can be modified. - An address can be deleted from an association A with generalized endpoint gE as long as
Addr(A, gE)stays non-empty. - An address can be deleted from a generalized endpoint gE only if it has been removed from all associations having gE as a generalized endpoint.
These rules make sure the rules for endpoints and associations given above are always fulfilled. Lowkey the best part of the whole appendix 🫶
Authors' Addresses 🌈
Here's how to find the authors (they'd love to hear from you 💌):
Randall R. Stewart
Cisco Systems, Inc.
4875 Forest Drive
Suite 200
Columbia, SC 29206
US
Phone:
EMail: rrs@cisco.com
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, 2-3C
Arlington Heights, IL 60004
USA
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@motorola.com
Michael Tuexen
Univ. of Applied Sciences Muenster
Stegerwaldstr. 39
48565 Steinfurt
Germany
EMail: tuexen@fh-muenster.de
Shin Maruyama
Kyoto University
Yoshida-Honmachi
Sakyo-ku
Kyoto, Kyoto 606-8501
JAPAN
Phone: +81-75-753-7417
EMail: mail@marushin.gr.jp
Masahiro Kozuka
Kyoto University
Yoshida-Honmachi
Sakyo-ku
Kyoto, Kyoto 606-8501
JAPAN
Phone: +81-75-753-7417
EMail: ma-kun@kozuka.jpFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🎀
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Bye, that's the whole doc 💖🦋
📦 where this page comes from
- ietf: rfc5061 2007-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms