UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
updated by
- rfc-8899 — Packetization Layer Path MTU Discovery for Datagram Transports
Extracted elements (23)
Each SCTP stack uses a single local UDP encapsulation port number as the destination for all incoming SCTP packets. Using a single port greatly simplifies implementation because multiple per-address ports would require the sender to choose the correct port during source address selection.
SCTP sends periodic HEARTBEAT chunks on all idle paths. When using UDP encapsulation for legacy NAT traversal, these HEARTBEATs serve the additional function of keeping NAT state alive for each path.
UDP encapsulation of SCTP serves two purposes: enabling SCTP traffic to pass through legacy NATs that lack native SCTP support, and allowing SCTP to be implemented in user space on hosts without direct IP-layer access, removing the need for special operating system privileges.
Although zero UDP checksum over IPv6 is allowed under RFC 6936, this document does not specify mechanisms for that mode. Deployed support may be limited, and at the time of writing, a zero UDP checksum would be counter to the goal of legacy NAT traversal.
An SCTP implementation supporting UDP encapsulation MUST maintain a remote UDP encapsulation port number per destination address for each SCTP association, because remapping by NATs may cause different remote IP addresses of the same stack to appear on different ports.
During encapsulation, the UDP source port MUST be the local UDP encapsulation port number of the SCTP stack, and the UDP destination port MUST be the remote UDP encapsulation port number maintained for the association and the destination address.
For legacy NAT traversal with single-homed associations, IP addresses MUST NOT be listed in the INIT and INIT-ACK chunks. To use multiple addresses, RFC 5061 MUST be used only with wildcard addresses in ASCONF chunks in combination with RFC 4895.
If a received ICMP or ICMPv6 packet cannot be related to a specific SCTP association or the verification tag cannot be verified, it MUST be discarded silently. The SCTP stack MUST NOT rely on receiving ICMP or ICMPv6 messages.
If an SCTP endpoint starts to encapsulate the packets of a path, it MUST decrease the Path MTU of that path by the size of the UDP header. PMTU discovery using ICMP feedback cannot be relied upon due to the ICMP limitations described in Section 5.5.
If ICMP/ICMPv6 messages are processed, ICMP 'Destination Unreachable / Port Unreachable' SHOULD be treated as 'Destination Unreachable / Protocol Unreachable' (IPv4), and ICMPv6 'Destination Unreachable / Port Unreachable' SHOULD be treated as 'Parameter Problem / unrecognized Next Header type encountered' (IPv6).
If the implementation supports sending and receiving ECN bits for the IP protocols used by an SCTP association, the ECN bits MUST NOT be changed during sending and receiving.
The UDP packet length MUST be the SCTP packet length plus the size of the UDP header. The SCTP checksum MUST be computed for both IPv4 and IPv6; the UDP checksum SHOULD be computed for both IPv4 and IPv6.
Upon decapsulation, after removing the UDP header and finding the SCTP association via the verification tag, the UDP source port MUST be stored as the encapsulation port for the destination address from which the SCTP packet was received.
When a non-encapsulated SCTP packet is received, encapsulation of outgoing packets belonging to the same association and the corresponding destination address MUST be disabled.
When addresses are changed during the lifetime of an association, the RFC 5061 dynamic address reconfiguration extension MUST be used with wildcard addresses only. If an SCTP endpoint receives an ABORT with the T-bit set, it MAY use this as an indication that the peer's visible addresses may have changed.
When using UDP encapsulation for legacy NAT traversal, IP addresses that might require translation MUST NOT be put into any SCTP packet. A multihomed association must be set up initially as single-homed, and RFC 5061 with RFC 4895 must be used with wildcard addresses only to add additional addresses.
The SCTP_REMOTE_UDP_ENCAPS_PORT socket option (struct sctp_udpencaps with fields sue_assoc_id, sue_address, sue_port) allows an application to set and retrieve the remote UDP encapsulation port number per association and destination address. Setting sue_port to 0 disables UDP encapsulation.
UDP-encapsulated SCTP normally uses IANA-assigned UDP port 9899 (sctp-tunneling) on both ends. Implementations in application space may use other ports, and NAT boxes may remap port numbers, so implementations must handle port numbers other than 9899.
IANA updated the existing UDP port 9899 (sctp-tunneling) assignment to refer to this document. The TCP port 9899 (sctp-tunneling) assignment was removed and TCP port 9899 was marked as 'Reserved' since it is no longer needed.
Encapsulating SCTP into UDP does not add any security considerations beyond those in RFC 4960 and RFC 5061. An attacker attempting to change the encapsulation port for a remote address must supply a valid verification tag, providing the same blind-attacker protection as native SCTP.
Firewalls that inspect SCTP packets must also be aware of UDP encapsulation and apply corresponding rules to the encapsulated packets; otherwise, encapsulated SCTP traffic may bypass SCTP-specific firewall policies.
For IPv4, the encapsulated packet format is: IPv4 Header | UDP Header | SCTP Common Header | SCTP Chunk #1 ... SCTP Chunk #n. The UDP header is inserted between the IP header and the SCTP common header.
For IPv6, the encapsulated packet format is: IPv6 Base Header | IPv6 Extension Headers (0 or more) | UDP Header | SCTP Common Header | SCTP Chunk #1 ... SCTP Chunk #n.