draft-ietf-tsvwg-natsupp-21.txt   draft-ietf-tsvwg-natsupp-22.txt 
Network Working Group R. R. Stewart Network Working Group R. R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Standards Track M. Tüxen Intended status: Standards Track M. Tüxen
Expires: 5 May 2021 I. Rüngeler Expires: 20 May 2021 I. Rüngeler
Münster Univ. of Appl. Sciences Münster Univ. of Appl. Sciences
1 November 2020 16 November 2020
Stream Control Transmission Protocol (SCTP) Network Address Translation Stream Control Transmission Protocol (SCTP) Network Address Translation
Support Support
draft-ietf-tsvwg-natsupp-21 draft-ietf-tsvwg-natsupp-22
Abstract Abstract
The Stream Control Transmission Protocol (SCTP) provides a reliable The Stream Control Transmission Protocol (SCTP) provides a reliable
communications channel between two end-hosts in many ways similar to communications channel between two end-hosts in many ways similar to
the Transmission Control Protocol (TCP). With the widespread the Transmission Control Protocol (TCP). With the widespread
deployment of Network Address Translators (NAT), specialized code has deployment of Network Address Translators (NAT), specialized code has
been added to NAT functions for TCP that allows multiple hosts to been added to NAT functions for TCP that allows multiple hosts to
reside behind a NAT function and yet share a single IPv4 address, reside behind a NAT function and yet share a single IPv4 address,
even when two hosts (behind a NAT function) choose the same port even when two hosts (behind a NAT function) choose the same port
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 May 2021. This Internet-Draft will expire on 20 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 7 skipping to change at page 3, line 7
6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 20
6.3. Handling of Internal Port Number Collisions . . . . . . . 20 6.3. Handling of Internal Port Number Collisions . . . . . . . 20
6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20
6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21
6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21
6.4.1. NAT Function Considerations . . . . . . . . . . . . . 22 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 22
6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22
6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 24 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 24
6.6. Multi Point Traversal Considerations for Endpoints . . . 24 6.6. Multi Point Traversal Considerations for Endpoints . . . 24
7. Various Examples of NAT Traversals . . . . . . . . . . . . . 24 7. SCTP NAT YANG Module . . . . . . . . . . . . . . . . . . . . 24
7.1. Single-homed Client to Single-homed Server . . . . . . . 24 7.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 24
7.2. Single-homed Client to Multi-homed Server . . . . . . . . 27 7.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Multihomed Client and Server . . . . . . . . . . . . . . 29 8. Various Examples of NAT Traversals . . . . . . . . . . . . . 27
7.4. NAT Function Loses Its State . . . . . . . . . . . . . . 32 8.1. Single-homed Client to Single-homed Server . . . . . . . 28
7.5. Peer-to-Peer Communications . . . . . . . . . . . . . . . 34 8.2. Single-homed Client to Multi-homed Server . . . . . . . . 30
8. SCTP NAT YANG Module . . . . . . . . . . . . . . . . . . . . 39 8.3. Multihomed Client and Server . . . . . . . . . . . . . . 32
8.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 39 8.4. NAT Function Loses Its State . . . . . . . . . . . . . . 35
8.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 40 8.5. Peer-to-Peer Communications . . . . . . . . . . . . . . . 37
9. Socket API Considerations . . . . . . . . . . . . . . . . . . 42 9. Socket API Considerations . . . . . . . . . . . . . . . . . . 42
9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 43 9.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 43 10.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 43
10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 45 10.2. Three New Error Causes . . . . . . . . . . . . . . . . . 45
10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 46 10.3. Two New Chunk Parameter Types . . . . . . . . . . . . . 46
10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 46 10.4. One New URI . . . . . . . . . . . . . . . . . . . . . . 46
10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 46 10.5. One New YANG Module . . . . . . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46
12. Normative References . . . . . . . . . . . . . . . . . . . . 47 12. Normative References . . . . . . . . . . . . . . . . . . . . 47
13. Informative References . . . . . . . . . . . . . . . . . . . 49 13. Informative References . . . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
Stream Control Transmission Protocol (SCTP) [RFC4960] provides a Stream Control Transmission Protocol (SCTP) [RFC4960] provides a
reliable communications channel between two end-hosts in many ways reliable communications channel between two end-hosts in many ways
similar to TCP [RFC0793]. With the widespread deployment of Network similar to TCP [RFC0793]. With the widespread deployment of Network
Address Translators (NAT), specialized code has been added to NAT Address Translators (NAT), specialized code has been added to NAT
functions for TCP that allows multiple hosts to reside behind a NAT functions for TCP that allows multiple hosts to reside behind a NAT
skipping to change at page 5, line 27 skipping to change at page 5, line 27
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| No Support | Support | No Support | Limited | | No Support | Support | No Support | Limited |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| No Support | No Support | Support | None | | No Support | No Support | Support | None |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| No Support | No Support | No Support | None | | No Support | No Support | No Support | None |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
Table 1: Communication possibilities Table 1: Communication possibilities
From the table it can be seen that when a NAT function does not From the table it can be seen that no communication can occur when a
support SCTP-aware NAT no communication can occur. This assumes that NAT function does not support SCTP-aware NAT. This assumes that the
the NAT function does not handle SCTP packets at all and all SCTP NAT function does not handle SCTP packets at all and all SCTP packets
packets sent from behind a NAT function are discarded by the NAT sent from behind a NAT function are discarded by the NAT function.
function. In some cases, where the NAT function supports SCTP-aware In some cases, where the NAT function supports SCTP-aware NAT, but
NAT but one of the two hosts does not support the feature, one of the two hosts does not support the feature, communication can
communication possibly occurs but in a limited way. For example only possibly occur in a limited way. For example, only one host can have
one host can have a connection when a collision case occurs. a connection when a collision case occurs.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
skipping to change at page 8, line 28 skipping to change at page 8, line 28
This case does not apply to a single-homed SCTP association (i.e., This case does not apply to a single-homed SCTP association (i.e.,
both endpoints in the association use only one IP address). The both endpoints in the association use only one IP address). The
advantage here is that the existence of multiple NAT traversal points advantage here is that the existence of multiple NAT traversal points
can preserve the path diversity of a multi-homed association for the can preserve the path diversity of a multi-homed association for the
entire path. This in turn can improve the robustness of the entire path. This in turn can improve the robustness of the
communication. communication.
4.2. Limitations of Classical NAPT for SCTP 4.2. Limitations of Classical NAPT for SCTP
Using classical NAPT possibly results in changing one of the SCTP Using classical NAPT possibly results in changing one of the SCTP
port numbers during the processing which requires the recomputation port numbers during the processing, which requires the recomputation
of the transport layer checksum by the NAPT function. Whereas for of the transport layer checksum by the NAPT function. Whereas for
UDP and TCP this can be done very efficiently, for SCTP the checksum UDP and TCP this can be done very efficiently, for SCTP the checksum
(CRC32c) over the entire packet needs to be recomputed (see (CRC32c) over the entire packet needs to be recomputed (see
Appendix B of [RFC4960] for details of the CRC32c computation). This Appendix B of [RFC4960] for details of the CRC32c computation). This
would considerably add to the NAT computational burden, however would considerably add to the NAT computational burden, however
hardware support can mitigate this in some implementations. hardware support can mitigate this in some implementations.
An SCTP endpoint can have multiple addresses but only has a single An SCTP endpoint can have multiple addresses but only has a single
port number to use. To make multipoint traversal work, all the NAT port number to use. To make multipoint traversal work, all the NAT
functions involved need to recognize the packets they see as functions involved need to recognize the packets they see as
skipping to change at page 9, line 36 skipping to change at page 9, line 36
conditions. There can not be more than one entry NAT binding table conditions. There can not be more than one entry NAT binding table
with the same pair of Internal-Port and Remote-Port. This rule can with the same pair of Internal-Port and Remote-Port. This rule can
be relaxed, if all NAT binding table entries with the same Internal- be relaxed, if all NAT binding table entries with the same Internal-
Port and Remote-Port have the support for the restart procedure Port and Remote-Port have the support for the restart procedure
disabled (see Section 5.3.1). In this case there can not be no more disabled (see Section 5.3.1). In this case there can not be no more
than one entry with the same Internal-Port, Remote-Port and Remote- than one entry with the same Internal-Port, Remote-Port and Remote-
VTag and no more than one NAT binding table entry with the same VTag and no more than one NAT binding table entry with the same
Internal-Port, Remote-Port, and Int-VTag. Internal-Port, Remote-Port, and Int-VTag.
The processing of outgoing SCTP packets containing an INIT chunk is The processing of outgoing SCTP packets containing an INIT chunk is
described in the following figure. The scenario shown is valid for illustrated in the following figure. This scenario is valid for all
all message flows in this section. message flows in this section.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B | | Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\---/ \--/\---/
INIT[Initiate-Tag] INIT[Initiate-Tag]
Int-Addr:Int-Port ------> Rem-Addr:Rem-Port Int-Addr:Int-Port ------> Rem-Addr:Rem-Port
Rem-VTag=0 Rem-VTag=0
skipping to change at page 11, line 23 skipping to change at page 11, line 23
Int-Addr:Int-Port ------> Rem-Addr:Rem-Port Int-Addr:Int-Port ------> Rem-Addr:Rem-Port
Rem-VTag Rem-VTag
Translate To: Translate To:
Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port
Rem-VTag Rem-VTag
The processing of incoming SCTP packets containing an INIT ACK chunk The processing of incoming SCTP packets containing an INIT ACK chunk
is described in the following figure. The Lookup() function getting is illustrated in the following figure. The Lookup() function has as
as input the Internal-VTag, Internal-Port, Remote-VTag, and Remote- input the Internal-VTag, Internal-Port, Remote-VTag, and Remote-Port.
Port, returns the corresponding entry of the NAT binding table and It returns the corresponding entry of the NAT binding table and
updates the Remote-VTag by substituting it with the value of the updates the Remote-VTag by substituting it with the value of the
Initiate-Tag of the INIT ACK chunk. The wildcard character signifies Initiate-Tag of the INIT ACK chunk. The wildcard character signifies
that the parameter's value is not considered in the Lookup() function that the parameter's value is not considered in the Lookup() function
or changed in the Update() function, respectively. or changed in the Update() function, respectively.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B | | Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\---/ \--/\---/
skipping to change at page 17, line 15 skipping to change at page 17, line 15
Restart Parameter. IANA is requested to assign the value 0xC007 Restart Parameter. IANA is requested to assign the value 0xC007
for this parameter type. for this parameter type.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter. The value This field holds the length in bytes of the parameter. The value
MUST be 4. MUST be 4.
[NOTE to RFC-Editor: Assignment of parameter type to be confirmed by [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by
IANA.] IANA.]
This parameter MAY appear in INIT, INIT ACK and ASCONF chunks and The Disable Restart Parameter MAY appear in INIT, INIT ACK and ASCONF
MUST NOT appear in any other chunk. chunks and MUST NOT appear in any other chunk.
5.3.2. VTags Parameter 5.3.2. VTags Parameter
This parameter is used to help a NAT function to recover from state This parameter is used to help a NAT function to recover from state
loss. loss.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0xC008 | Parameter Length = 16 | | Parameter Type = 0xC008 | Parameter Length = 16 |
skipping to change at page 17, line 50 skipping to change at page 17, line 50
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter. The value This field holds the length in bytes of the parameter. The value
MUST be 16. MUST be 16.
ASCONF-Request Correlation ID: 4 bytes (unsigned integer) ASCONF-Request Correlation ID: 4 bytes (unsigned integer)
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. The receiver of the ASCONF Chunk will copy request parameter. The receiver of the ASCONF Chunk will copy
this 32-bit value into the ASCONF Response Correlation ID field of this 32-bit value into the ASCONF Response Correlation ID field of
the ASCONF ACK response parameter. The sender of the packet the ASCONF ACK response parameter. The sender of the packet
containing the ASCONF chunk can use this same value in the ASCONF containing the ASCONF chunk can use this same value in the ASCONF
ACK chunk to find which request the response is for. Note that ACK chunk to find which request the response is for. The receiver
the receiver MUST NOT change this 32-bit value. MUST NOT change the value of the ASCONF-Request Correlation ID.
Internal Verification Tag: 4 bytes (unsigned integer) Internal Verification Tag: 4 bytes (unsigned integer)
The Verification Tag that the internal host has chosen for the The Verification Tag that the internal host has chosen for the
association. The Verification Tag is a unique 32-bit tag that association. The Verification Tag is a unique 32-bit tag that
accompanies any incoming SCTP packet for this association to the accompanies any incoming SCTP packet for this association to the
Internal-Address. Internal-Address.
Remote Verification Tag: 4 bytes (unsigned integer) Remote Verification Tag: 4 bytes (unsigned integer)
The Verification Tag that the host holding the Remote-Address has The Verification Tag that the host holding the Remote-Address has
chosen for the association. The VTag is a unique 32-bit tag that chosen for the association. The VTag is a unique 32-bit tag that
accompanies any outgoing SCTP packet for this association to the accompanies any outgoing SCTP packet for this association to the
Remote-Address. Remote-Address.
[NOTE to RFC-Editor: Assignment of parameter type to be confirmed by [NOTE to RFC-Editor: Assignment of parameter type to be confirmed by
IANA.] IANA.]
This parameter MAY appear in ASCONF chunks and MUST NOT appear in any The VTags Parameter MAY appear in ASCONF chunks and MUST NOT appear
other chunk. in any other chunk.
6. Procedures for SCTP Endpoints and NAT Functions 6. Procedures for SCTP Endpoints and NAT Functions
If an SCTP endpoint is behind an SCTP-aware NAT, a number of problems If an SCTP endpoint is behind an SCTP-aware NAT, a number of problems
can arise as it tries to communicate with its peers: can arise as it tries to communicate with its peers:
* IP addresses can not be included in the SCTP packet. This is * IP addresses can not be included in the SCTP packet. This is
discussed in Section 6.1. discussed in Section 6.1.
* More than one host behind a NAT function could select the same * More than one host behind a NAT function could select the same
skipping to change at page 24, line 12 skipping to change at page 24, line 12
different than what happens to all TCP connections when a NAT different than what happens to all TCP connections when a NAT
function looses its state). function looses its state).
6.5. Handling of Fragmented SCTP Packets by NAT Functions 6.5. Handling of Fragmented SCTP Packets by NAT Functions
SCTP minimizes the use of IP-level fragmentation. However, it can SCTP minimizes the use of IP-level fragmentation. However, it can
happen that using IP-level fragmentation is needed to continue an happen that using IP-level fragmentation is needed to continue an
SCTP association. For example, if the path MTU is reduced and there SCTP association. For example, if the path MTU is reduced and there
are still some DATA chunk in flight, which require packets larger are still some DATA chunk in flight, which require packets larger
than the new path MTU. If IP-level fragmentation can not be used, than the new path MTU. If IP-level fragmentation can not be used,
the SCTP association will be terminated in a non-graceful way. the SCTP association will be terminated in a non-graceful way. See
[RFC8900] for more information about IP fragmentation.
Therefore, a NAT function MUST be able to handle IP-level fragmented Therefore, a NAT function MUST be able to handle IP-level fragmented
SCTP packets. The fragments MAY arrive in any order. SCTP packets. The fragments MAY arrive in any order.
When an SCTP packet can not be forwarded by the NAT function due to When an SCTP packet can not be forwarded by the NAT function due to
MTU issues and the IP header forbids fragmentation, the NAT MUST send MTU issues and the IP header forbids fragmentation, the NAT MUST send
back a "Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message back a "Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message
to the internal host. This allows for a faster recovery from this to the internal host. This allows for a faster recovery from this
packet drop. packet drop.
skipping to change at page 24, line 34 skipping to change at page 24, line 35
If a multi-homed SCTP endpoint behind a NAT function connects to a If a multi-homed SCTP endpoint behind a NAT function connects to a
peer, it MUST first set up the association single-homed with only one peer, it MUST first set up the association single-homed with only one
address causing the first NAT function to populate its state. Then address causing the first NAT function to populate its state. Then
it SHOULD add each IP address using packets containing ASCONF chunks it SHOULD add each IP address using packets containing ASCONF chunks
sent via their respective NAT functions. The address used in the Add sent via their respective NAT functions. The address used in the Add
IP address parameter is the wildcard address (0.0.0.0 or ::0) and the IP address parameter is the wildcard address (0.0.0.0 or ::0) and the
address parameter in the ASCONF chunk SHOULD also contain the VTags address parameter in the ASCONF chunk SHOULD also contain the VTags
parameter and optionally the Disable Restart parameter. parameter and optionally the Disable Restart parameter.
7. Various Examples of NAT Traversals 7. SCTP NAT YANG Module
This section defines a YANG module for SCTP NAT.
The terminology for describing YANG data models is defined in
[RFC7950]. The meaning of the symbols in tree diagrams is defined in
[RFC8340].
7.1. Tree Structure
This module augments NAT YANG module [RFC8512] with SCTP specifics.
The module supports both classical SCTP NAT (that is, rewrite port
numbers) and SCTP-specific variant where the ports numbers are not
altered. The YANG "feature" is used to indicate whether SCTP-
specific variant is supported.
The tree structure of the SCTP NAT YANG module is provided below:
module: ietf-nat-sctp
augment /nat:nat/nat:instances/nat:instance
/nat:policy/nat:timers:
+--rw sctp-timeout? uint32
augment /nat:nat/nat:instances/nat:instance
/nat:mapping-table/nat:mapping-entry:
+--rw int-VTag? uint32 {sctp-nat}?
+--rw rem-VTag? uint32 {sctp-nat}?
Concretely, the SCTP NAT YANG module augments the NAT YANG module
(policy, in particular) with the following:
* The sctp-timeout is used to control the SCTP inactivity timeout.
That is, the time an SCTP mapping will stay active without SCTP
packets traversing the NAT. This timeout can be set only for
SCTP. Hence, "/nat:nat/nat:instances/nat:instance/nat:policy/
nat:transport-protocols/nat:protocol-id" MUST be set to '132'
(SCTP).
In addition, the SCTP NAT YANG module augments the mapping entry with
the following parameters defined in Section 3. These parameters
apply only for SCTP NAT mapping entries (i.e.,
"/nat/instances/instance/mapping-table/mapping-entry/transport-
protocol" MUST be set to '132');
* The Internal Verification Tag (Int-VTag)
* The Remote Verification Tag (Rem-VTag)
7.2. YANG Module
<CODE BEGINS> file "ietf-nat-sctp@2020-11-02.yang"
module ietf-nat-sctp {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-nat-sctp";
prefix nat-sctp;
import ietf-nat {
prefix nat;
reference
"RFC 8512: A YANG Module for Network Address Translation
(NAT) and Network Prefix Translation (NPT)";
}
organization
"IETF TSVWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/tsvwg/>
WG List: <mailto:tsvwg@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>";
description
"This module augments NAT YANG module with Stream Control
Transmission Protocol (SCTP) specifics. The extension supports
both a classical SCTP NAT (that is, rewrite port numbers)
and a, SCTP-specific variant where the ports numbers are
not altered.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2019-11-18 {
description
"Initial revision.";
reference
"RFC XXXX: Stream Control Transmission Protocol (SCTP)
Network Address Translation Support";
}
feature sctp-nat {
description
"This feature means that SCTP-specific variant of NAT
is supported. That is, avoid rewriting port numbers.";
reference
"Section 4.3 of RFC XXXX.";
}
augment "/nat:nat/nat:instances/nat:instance"
+ "/nat:policy/nat:timers" {
when "/nat:nat/nat:instances/nat:instance"
+ "/nat:policy/nat:transport-protocols"
+ "/nat:protocol-id = 132";
description
"Extends NAT policy with a timeout for SCTP mapping
entries.";
leaf sctp-timeout {
type uint32;
units "seconds";
description
"SCTP inactivity timeout. That is, the time an SCTP
mapping entry will stay active without packets
traversing the NAT.";
}
}
augment "/nat:nat/nat:instances/nat:instance"
+ "/nat:mapping-table/nat:mapping-entry" {
when "nat:transport-protocol = 132";
if-feature "sctp-nat";
description
"Extends the mapping entry with SCTP specifics.";
leaf int-VTag {
type uint32;
description
"The Internal Verification Tag that the internal
host has chosen for this communication.";
}
leaf rem-VTag {
type uint32;
description
"The Remote Verification Tag that the remote
peer has chosen for this communication.";
}
}
}
<CODE ENDS>
8. Various Examples of NAT Traversals
Please note that this section is informational only. Please note that this section is informational only.
The addresses being used in the following examples are IPv4 addresses The addresses being used in the following examples are IPv4 addresses
for private-use networks and for documentation as specified in for private-use networks and for documentation as specified in
[RFC6890]. However, the method described here is not limited to this [RFC6890]. However, the method described here is not limited to this
NAT44 case. NAT44 case.
The NAT binding table entries shown in the following examples do not The NAT binding table entries shown in the following examples do not
include the flag indicating whether the restart procedure is include the flag indicating whether the restart procedure is
supported or not. This flag is not relevant for these examples. supported or not. This flag is not relevant for these examples.
7.1. Single-homed Client to Single-homed Server 8.1. Single-homed Client to Single-homed Server
The internal client starts the association with the remote server via The internal client starts the association with the remote server via
a four-way-handshake. Host A starts by sending a packet containing a four-way-handshake. Host A starts by sending a packet containing
an INIT chunk. an INIT chunk.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B | | Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\---/ \--/\---/
skipping to change at page 27, line 5 skipping to change at page 30, line 5
Rem-VTag = 5678 Rem-VTag = 5678
COOKIE ACK COOKIE ACK
192.0.2.1:1 <----------------------- 203.0.113.1:2 192.0.2.1:1 <----------------------- 203.0.113.1:2
Int-VTag = 1234 Int-VTag = 1234
COOKIE ACK COOKIE ACK
10.0.0.1:1 <------ 203.0.113.1:2 10.0.0.1:1 <------ 203.0.113.1:2
Int-VTag = 1234 Int-VTag = 1234
7.2. Single-homed Client to Multi-homed Server 8.2. Single-homed Client to Multi-homed Server
The internal client is single-homed whereas the remote server is The internal client is single-homed whereas the remote server is
multi-homed. The client (Host A) sends a packet containing an INIT multi-homed. The client (Host A) sends a packet containing an INIT
chunk like in the single-homed case. chunk like in the single-homed case.
+--------+ +--------+
/--\/--\ /-|Router 1| \ /--\/--\ /-|Router 1| \
+------+ +-----+ / \ / +--------+ \ +------+ +------+ +-----+ / \ / +--------+ \ +------+
| Host | <-----> | NAT | <-> | Network | == =| Host | | Host | <-----> | NAT | <-> | Network | == =| Host |
| A | +-----+ \ / \ +--------+ / | B | | A | +-----+ \ / \ +--------+ / | B |
skipping to change at page 29, line 29 skipping to change at page 32, line 29
Rem-VTag = 5678 Rem-VTag = 5678
COOKIE ACK COOKIE ACK
192.0.2.1:1 <-------------------------- 203.0.113.1:2 192.0.2.1:1 <-------------------------- 203.0.113.1:2
Int-VTag = 1234 Int-VTag = 1234
COOKIE ACK COOKIE ACK
10.0.0.1:1 <--- 203.0.113.1:2 10.0.0.1:1 <--- 203.0.113.1:2
Int-VTag = 1234 Int-VTag = 1234
7.3. Multihomed Client and Server 8.3. Multihomed Client and Server
The client (Host A) sends a packet containing an INIT chunk to the The client (Host A) sends a packet containing an INIT chunk to the
server (Host B), but does not include the second address. server (Host B), but does not include the second address.
+-------+ +-------+
/--| NAT 1 |--\ /--\/--\ /--| NAT 1 |--\ /--\/--\
+------+ / +-------+ \ / \ +--------+ +------+ / +-------+ \ / \ +--------+
| Host |=== ====| Network |====| Host B | | Host |=== ====| Network |====| Host B |
| A | \ +-------+ / \ / +--------+ | A | \ +-------+ / \ / +--------+
+------+ \--| NAT 2 |--/ \--/\--/ +------+ \--| NAT 2 |--/ \--/\--/
skipping to change at page 32, line 24 skipping to change at page 35, line 24
Rem-VTag = 5678 Rem-VTag = 5678
ASCONF ACK ASCONF ACK
192.0.2.129:1 <------------------- 203.0.113.129:2 192.0.2.129:1 <------------------- 203.0.113.129:2
Int-VTag = 1234 Int-VTag = 1234
ASCONF ACK ASCONF ACK
10.1.0.1:1 <----- 203.0.113.129:2 10.1.0.1:1 <----- 203.0.113.129:2
Int-VTag = 1234 Int-VTag = 1234
7.4. NAT Function Loses Its State 8.4. NAT Function Loses Its State
Association is already established between Host A and Host B, when Association is already established between Host A and Host B, when
the NAT function loses its state and obtains a new external address. the NAT function loses its state and obtains a new external address.
Host A sends a DATA chunk to Host B. Host A sends a DATA chunk to Host B.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <----------> | NAT | <----> | Network | <----> | Host B | | Host A | <----------> | NAT | <----> | Network | <----> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\--/ \--/\--/
skipping to change at page 34, line 26 skipping to change at page 37, line 26
10.1.0.1:1 <---------- 203.0.113.129:2 10.1.0.1:1 <---------- 203.0.113.129:2
Int-VTag = 1234 Int-VTag = 1234
DATA DATA
10.0.0.1:1 ----------> 203.0.113.1:2 10.0.0.1:1 ----------> 203.0.113.1:2
Rem-VTag = 5678 Rem-VTag = 5678
DATA DATA
192.0.2.2:1 -----------------> 203.0.113.129:2 192.0.2.2:1 -----------------> 203.0.113.129:2
Rem-VTag = 5678 Rem-VTag = 5678
7.5. Peer-to-Peer Communications 8.5. Peer-to-Peer Communications
If two hosts, each of them behind a NAT function, want to communicate If two hosts, each of them behind a NAT function, want to communicate
with each other, they have to get knowledge of the peer's external with each other, they have to get knowledge of the peer's external
address. This can be achieved with a so-called rendezvous server. address. This can be achieved with a so-called rendezvous server.
Afterwards the destination addresses are external, and the Afterwards the destination addresses are external, and the
association is set up with the help of the INIT collision. The NAT association is set up with the help of the INIT collision. The NAT
functions create their entries according to their internal peer's functions create their entries according to their internal peer's
point of view. Therefore, NAT function A's Internal-VTag and point of view. Therefore, NAT function A's Internal-VTag and
Internal-Port are NAT function B's Remote-VTag and Remote-Port, Internal-Port are NAT function B's Remote-VTag and Remote-Port,
respectively. The naming (internal/remote) of the verification tag respectively. The naming (internal/remote) of the verification tag
skipping to change at page 39, line 37 skipping to change at page 42, line 37
Rem-VTag = 5678 Rem-VTag = 5678
COOKIE ACK COOKIE ACK
192.0.2.1:1 ----------------> 203.0.113.1:2 192.0.2.1:1 ----------------> 203.0.113.1:2
Rem-VTag = 5678 Rem-VTag = 5678
COOKIE ACK COOKIE ACK
192.0.2.1:1 --> 10.1.0.1:2 192.0.2.1:1 --> 10.1.0.1:2
Rem-VTag = 5678 Rem-VTag = 5678
8. SCTP NAT YANG Module
This section defines a YANG module for SCTP NAT.
The terminology for describing YANG data models is defined in
[RFC7950]. The meaning of the symbols in tree diagrams is defined in
[RFC8340].
8.1. Tree Structure
This module augments NAT YANG module [RFC8512] with SCTP specifics.
The module supports both classical SCTP NAT (that is, rewrite port
numbers) and SCTP-specific variant where the ports numbers are not
altered. The YANG "feature" is used to indicate whether SCTP-
specific variant is supported.
The tree structure of the SCTP NAT YANG module is provided below:
module: ietf-nat-sctp
augment /nat:nat/nat:instances/nat:instance
/nat:policy/nat:timers:
+--rw sctp-timeout? uint32
augment /nat:nat/nat:instances/nat:instance
/nat:mapping-table/nat:mapping-entry:
+--rw int-VTag? uint32 {sctp-nat}?
+--rw rem-VTag? uint32 {sctp-nat}?
Concretely, the SCTP NAT YANG module augments the NAT YANG module
(policy, in particular) with the following:
* The sctp-timeout is used to control the SCTP inactivity timeout.
That is, the time an SCTP mapping will stay active without SCTP
packets traversing the NAT. This timeout can be set only for
SCTP. Hence, "/nat:nat/nat:instances/nat:instance/nat:policy/
nat:transport-protocols/nat:protocol-id" MUST be set to '132'
(SCTP).
In addition, the SCTP NAT YANG module augments the mapping entry with
the following parameters defined in Section 3. These parameters
apply only for SCTP NAT mapping entries (i.e.,
"/nat/instances/instance/mapping-table/mapping-entry/transport-
protocol" MUST be set to '132');
* The Internal Verification Tag (Int-VTag)
* The Remote Verification Tag (Rem-VTag)
8.2. YANG Module
<CODE BEGINS> file "ietf-nat-sctp@2020-11-02.yang"
module ietf-nat-sctp {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-nat-sctp";
prefix nat-sctp;
import ietf-nat {
prefix nat;
reference
"RFC 8512: A YANG Module for Network Address Translation
(NAT) and Network Prefix Translation (NPT)";
}
organization
"IETF TSVWG Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/tsvwg/>
WG List: <mailto:tsvwg@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>";
description
"This module augments NAT YANG module with Stream Control
Transmission Protocol (SCTP) specifics. The extension supports
both a classical SCTP NAT (that is, rewrite port numbers)
and a, SCTP-specific variant where the ports numbers are
not altered.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2019-11-18 {
description
"Initial revision.";
reference
"RFC XXXX: Stream Control Transmission Protocol (SCTP)
Network Address Translation Support";
}
feature sctp-nat {
description
"This feature means that SCTP-specific variant of NAT
is supported. That is, avoid rewriting port numbers.";
reference
"Section 4.3 of RFC XXXX.";
}
augment "/nat:nat/nat:instances/nat:instance"
+ "/nat:policy/nat:timers" {
when "/nat:nat/nat:instances/nat:instance"
+ "/nat:policy/nat:transport-protocols"
+ "/nat:protocol-id = 132";
description
"Extends NAT policy with a timeout for SCTP mapping
entries.";
leaf sctp-timeout {
type uint32;
units "seconds";
description
"SCTP inactivity timeout. That is, the time an SCTP
mapping entry will stay active without packets
traversing the NAT.";
}
}
augment "/nat:nat/nat:instances/nat:instance"
+ "/nat:mapping-table/nat:mapping-entry" {
when "nat:transport-protocol = 132";
if-feature "sctp-nat";
description
"Extends the mapping entry with SCTP specifics.";
leaf int-VTag {
type uint32;
description
"The Internal Verification Tag that the internal
host has chosen for this communication.";
}
leaf rem-VTag {
type uint32;
description
"The Remote Verification Tag that the remote
peer has chosen for this communication.";
}
}
}
<CODE ENDS>
9. Socket API Considerations 9. Socket API Considerations
This section describes how the socket API defined in [RFC6458] is This section describes how the socket API defined in [RFC6458] is
extended to provide a way for the application to control NAT extended to provide a way for the application to control NAT
friendliness. friendliness.
Please note that this section is informational only. Please note that this section is informational only.
A socket API implementation based on [RFC6458] is extended by A socket API implementation based on [RFC6458] is extended by
supporting one new read/write socket option. supporting one new read/write socket option.
skipping to change at page 48, line 39 skipping to change at page 48, line 39
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Chunk Flags Registration", RFC 6096, Protocol (SCTP) Chunk Flags Registration", RFC 6096,
DOI 10.17487/RFC6096, January 2011, DOI 10.17487/RFC6096, January 2011,
<https://www.rfc-editor.org/info/rfc6096>. <https://www.rfc-editor.org/info/rfc6096>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
<https://www.rfc-editor.org/info/rfc8512>. <https://www.rfc-editor.org/info/rfc8512>.
13. Informative References 13. Informative References
[DOI_10.1145_1496091.1496095] [DOI_10.1145_1496091.1496095]
Hayes, D., But, J., and G. Armitage, "Issues with network Hayes, D., But, J., and G. Armitage, "Issues with network
skipping to change at page 50, line 25 skipping to change at page 50, line 5
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>. <https://www.rfc-editor.org/info/rfc6056>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<https://www.rfc-editor.org/info/rfc6333>. <https://www.rfc-editor.org/info/rfc6333>.
skipping to change at page 51, line 15 skipping to change at page 51, line 5
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
S., and K. Naito, "Updates to Network Address Translation S., and K. Naito, "Updates to Network Address Translation
(NAT) Behavioral Requirements", BCP 127, RFC 7857, (NAT) Behavioral Requirements", BCP 127, RFC 7857,
DOI 10.17487/RFC7857, April 2016, DOI 10.17487/RFC7857, April 2016,
<https://www.rfc-editor.org/info/rfc7857>. <https://www.rfc-editor.org/info/rfc7857>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
Acknowledgments Acknowledgments
The authors wish to thank Mohamed Boucadair, Gorry Fairhurst, Bryan The authors wish to thank Mohamed Boucadair, Gorry Fairhurst, Bryan
Ford, David Hayes, Alfred Hines, Karen E. E. Nielsen, Henning Peters, Ford, David Hayes, Alfred Hines, Karen E. E. Nielsen, Henning Peters,
Maksim Proshin, Timo Völker, Dan Wing, and Qiaobing Xie for their Maksim Proshin, Timo Völker, Dan Wing, and Qiaobing Xie for their
invaluable comments. invaluable comments.
In addition, the authors wish to thank David Hayes, Jason But, and In addition, the authors wish to thank David Hayes, Jason But, and
Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for Grenville Armitage, the authors of [DOI_10.1145_1496091.1496095], for
their suggestions. their suggestions.
 End of changes. 26 change blocks. 
212 lines changed or deleted 217 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/