| < draft-porfiri-tsvwg-sctp-natsupp-02.txt | draft-porfiri-tsvwg-sctp-natsupp-03.txt > | |||
|---|---|---|---|---|
| Network Working Group C. Porfiri | Network Working Group C. Porfiri | |||
| Internet-Draft Ericsson AB | Internet-Draft Ericsson AB | |||
| Intended status: Standards Track 25 March 2022 | Intended status: Standards Track 29 April 2022 | |||
| Expires: 26 September 2022 | Expires: 31 October 2022 | |||
| Stream Control Transmission Protocol (SCTP) Network Address Translation | Stream Control Transmission Protocol (SCTP) Network Address Translation | |||
| Support | Support | |||
| draft-porfiri-tsvwg-sctp-natsupp-02 | draft-porfiri-tsvwg-sctp-natsupp-03 | |||
| 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 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
| 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 26 September 2022. | This Internet-Draft will expire on 31 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (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 | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4. Motivation and Overview . . . . . . . . . . . . . . . . . . . 6 | 4. Motivation and Overview . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 | 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 | |||
| 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 6 | 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 6 | |||
| 4.1.2. Multipoint Traversal . . . . . . . . . . . . . . . . 8 | 4.1.2. Multipoint Traversal . . . . . . . . . . . . . . . . 8 | |||
| 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8 | 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 9 | |||
| 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 9 | 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 9 | |||
| 4.4. Differences with Current NAT Support Draft . . . . . . . 13 | 4.4. Compatibility and increamental deployment . . . . . . . . 14 | |||
| 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 | 4.5. Differences with Current NAT Support Draft . . . . . . . 15 | |||
| 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 14 | 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 14 | 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 14 | 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 16 | |||
| 5.1.3. Extended INIT-ACK Chunk . . . . . . . . . . . . . . . 15 | 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 16 | |||
| 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 15 | 5.1.3. Extended INIT-ACK Chunk . . . . . . . . . . . . . . . 16 | |||
| 5.2.1. Port Number Collision Error Cause . . . . . . . . . . 15 | 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 16 | 5.2.1. Port Number Collision Error Cause . . . . . . . . . . 17 | |||
| 5.3.1. Repetita Juvant Parameter . . . . . . . . . . . . . . 16 | 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 16 | 5.3.1. Repetita Juvant Parameter . . . . . . . . . . . . . . 18 | |||
| 6.1. Association Setup Considerations for Endpoints . . . . . 17 | 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 18 | |||
| 6.2. Association Setup Considerations for NAT . . . . . . . . 17 | 6.1. Association Setup Considerations for Endpoints . . . . . 19 | |||
| 6.3. Handling of Internal Port Number Collisions . . . . . . . 18 | 6.2. Association Setup Considerations for NAT . . . . . . . . 19 | |||
| 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 19 | 6.3. Handling of Internal Port Number Collisions . . . . . . . 19 | |||
| 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 19 | 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20 | |||
| 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 19 | 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 | |||
| 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 19 | 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 | |||
| 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 | 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 21 | |||
| 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 20 | 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22 | |||
| 6.6. Multipoint Traversal Considerations for Endpoints . . . . 21 | 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 22 | |||
| 6.6.1. NAT Function Considerations . . . . . . . . . . . . . 21 | 6.6. Multipoint Traversal Considerations for Endpoints . . . . 22 | |||
| 6.6.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 | 6.6.1. NAT Function Considerations . . . . . . . . . . . . . 23 | |||
| 6.7. Path Probing considerations . . . . . . . . . . . . . . . 22 | 6.6.2. Endpoint Considerations . . . . . . . . . . . . . . . 23 | |||
| 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 22 | 6.7. Path Probing considerations . . . . . . . . . . . . . . . 24 | |||
| 7.1. Single Homed Association Setup . . . . . . . . . . . . . 23 | 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 24 | |||
| 7.2. Single Homed Association Setup with Collision . . . . . . 23 | 7.1. Single Homed Association Setup . . . . . . . . . . . . . 25 | |||
| 7.3. Multi Homed Association Setup . . . . . . . . . . . . . . 24 | 7.2. Single Homed Association Setup with Collision . . . . . . 25 | |||
| 7.4. Multi Homed Association Setup . . . . . . . . . . . . . . 25 | 7.3. Multi Homed Association Setup . . . . . . . . . . . . . . 25 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 7.4. Multi Homed Association Setup . . . . . . . . . . . . . . 26 | |||
| 8.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 26 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 8.2. Four New Error Causes . . . . . . . . . . . . . . . . . . 27 | 8.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 28 | |||
| 8.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 28 | 8.2. Four New Error Causes . . . . . . . . . . . . . . . . . . 29 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 8.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 30 | |||
| 10. Normative References . . . . . . . . . . . . . . . . . . . . 29 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | |||
| 11. Informative References . . . . . . . . . . . . . . . . . . . 29 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 31 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 11. Informative References . . . . . . . . . . . . . . . . . . . 31 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
| 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 | |||
| function using private-use addresses (see [RFC6890] ) and yet share a | function using private-use addresses (see [RFC6890] ) and yet share a | |||
| single IPv4 address, even when two hosts (behind a NAT function) | single IPv4 address, even when two hosts (behind a NAT function) | |||
| skipping to change at page 4, line 27 ¶ | skipping to change at page 4, line 27 ¶ | |||
| messages by NAT functions easier. | messages by NAT functions easier. | |||
| An SCTP-aware NAT function will need to follow these procedures for | An SCTP-aware NAT function will need to follow these procedures for | |||
| generating appropriate SCTP packet formats, this is needed under | generating appropriate SCTP packet formats, this is needed under | |||
| circumstances detailed in this document and only triggered by the | circumstances detailed in this document and only triggered by the | |||
| detection of an SCTP packet containing an INIT chunk. | detection of an SCTP packet containing an INIT chunk. | |||
| When considering SCTP-aware NAT it is possible to have multiple | When considering SCTP-aware NAT it is possible to have multiple | |||
| levels of support. At each level, the Internal Host, Remote Host, | levels of support. At each level, the Internal Host, Remote Host, | |||
| and NAT function does or does not support the procedures described in | and NAT function does or does not support the procedures described in | |||
| this document. The following table illustrates the results of the | this document. | |||
| various combinations of support and if communications can occur | ||||
| between two endpoints. | The reference configuration for NAT support is depicted in the | |||
| following figure: | ||||
| Internal Network | External Network | ||||
| | | ||||
| Internal | External Remote | ||||
| Address | Address /--\/--\ Address | ||||
| +--------+ +-----+ / \ +--------+ | ||||
| | Host A |=========| NAT |=======| Network |==========| Host B | | ||||
| +--------+ +-----+ \ / +--------+ | ||||
| Internal | \--/\--/ Remote | ||||
| Internal Port | Port Remote | ||||
| VTag | VTag | ||||
| Figure 1: Basic Network Setup | ||||
| In the above Figure 1 the NAT hides Host A whereas Host B is directly | ||||
| connected to the public internet. Host A has a private IP address, | ||||
| NAT and Host B have public IP addresses. | ||||
| The following table illustrates the results of the various | ||||
| combinations of support and if communications can occur between two | ||||
| endpoints with reference to Figure 1, the NAT adaptation is the one | ||||
| described in the current document. | ||||
| +===============+==============+=============+===============+ | +===============+==============+=============+===============+ | |||
| | Internal Host | NAT Function | Remote Host | Communication | | | Internal Host | NAT Function | Remote Host | Communication | | |||
| +===============+==============+=============+===============+ | +===============+==============+=============+===============+ | |||
| | Support | Support | Support | Yes | | | Support | Support | Support | Yes | | |||
| +---------------+--------------+-------------+---------------+ | +---------------+--------------+-------------+---------------+ | |||
| | Support | Support | No Support | Limited | | | Support | Support | No Support | Yes | | |||
| +---------------+--------------+-------------+---------------+ | +---------------+--------------+-------------+---------------+ | |||
| | Support | No Support | Support | None | | | Support | No Support | Support | None | | |||
| +---------------+--------------+-------------+---------------+ | +---------------+--------------+-------------+---------------+ | |||
| | Support | No Support | No Support | None | | | Support | No Support | No Support | None | | |||
| +---------------+--------------+-------------+---------------+ | +---------------+--------------+-------------+---------------+ | |||
| | No Support | Support | Support | Limited | | | No Support | Support | Support | Limited | | |||
| +---------------+--------------+-------------+---------------+ | +---------------+--------------+-------------+---------------+ | |||
| | 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 no communication can occur when a | From the table it can be seen that no communication can occur when a | |||
| NAT function does not support SCTP-aware NAT. This assumes that the | NAT function does not support SCTP-aware NAT. This assumes that the | |||
| NAT function does not handle SCTP packets at all and all SCTP packets | NAT function does not handle SCTP packets at all and all SCTP packets | |||
| sent from behind a NAT function are discarded by the NAT function. | sent from behind a NAT function are discarded by the NAT function. | |||
| In some cases, where the NAT function supports SCTP-aware NAT, but | ||||
| one of the two hosts does not support the feature, communication can | In some cases, where the NAT function supports SCTP-aware NAT but the | |||
| possibly occur in a limited way. For example, only one host can have | local host does not support the feature, communication can possibly | |||
| a connection when a collision case occurs. | occur in a limited way. For example, only one host can have a | |||
| connection when a collision case occurs. | ||||
| When a SCTP host is deployed behind a NAT and both support SCTP-aware | ||||
| NAT, the communication will suceed independently from the remote | ||||
| peer. | ||||
| 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 6, line 9 ¶ | skipping to change at page 6, line 40 ¶ | |||
| Remote-VTag (Rem-VTag) | Remote-VTag (Rem-VTag) | |||
| The Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) that | The Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) that | |||
| the host holding the Remote-Address has chosen for an association. | the host holding the Remote-Address has chosen for an association. | |||
| The VTag is a unique 32-bit tag that accompanies any outgoing SCTP | The VTag is a unique 32-bit tag that accompanies any outgoing SCTP | |||
| packet for this association to the Remote-Address. | packet for this association to the Remote-Address. | |||
| External-Address (Ext-Addr) | External-Address (Ext-Addr) | |||
| An external address assigned to the NAT function, that it uses as | An external address assigned to the NAT function, that it uses as | |||
| a source address when sending packets towards a Remote-Address. | a source address when sending packets towards a Remote-Address. | |||
| Internal Network | External Network | ||||
| | | ||||
| Internal | External Remote | ||||
| Address | Address /--\/--\ Address | ||||
| +--------+ +-----+ / \ +--------+ | ||||
| | Host A |=========| NAT |=======| Network |==========| Host B | | ||||
| +--------+ +-----+ \ / +--------+ | ||||
| Internal | \--/\--/ Remote | ||||
| Internal Port | Port Remote | ||||
| VTag | VTag | ||||
| Figure 1: Basic Network Setup | ||||
| 4. Motivation and Overview | 4. Motivation and Overview | |||
| 4.1. SCTP NAT Traversal Scenarios | 4.1. SCTP NAT Traversal Scenarios | |||
| This section defines the notion of single and multipoint NAT | This section defines the notion of single and multipoint NAT | |||
| traversal. | traversal. | |||
| 4.1.1. Single Point Traversal | 4.1.1. Single Point Traversal | |||
| In this case, all packets in the SCTP association go through a single | In this case, all packets in the SCTP association go through a single | |||
| skipping to change at page 13, line 32 ¶ | skipping to change at page 14, line 32 ¶ | |||
| forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) | forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) | |||
| Translates To: | Translates To: | |||
| Int-Addr:Int-Port <------ Rem-Addr:Rem-Port | Int-Addr:Int-Port <------ Rem-Addr:Rem-Port | |||
| Int-VTag | Int-VTag | |||
| In the case where the Lookup function fails because it does not find | In the case where the Lookup function fails because it does not find | |||
| an entry, the SCTP packet is dropped. | an entry, the SCTP packet is dropped. | |||
| 4.4. Differences with Current NAT Support Draft | 4.4. Compatibility and increamental deployment | |||
| The current proposal for adding SCTP-capable NAT function is meant to | ||||
| provide backwards compatibility in both involved functionality and | ||||
| being compatible with legacy SCTP remote terminations that doesn't | ||||
| implement it. | ||||
| The compatibility at NAT tracking mechanism allows the NAT functionto | ||||
| be able hiding also SCTP stack that doesn't implement the current | ||||
| specfication, at the same time an SCTP stack implementing the current | ||||
| specification canbe deployed in a NAT scenario where the NAT doesn't | ||||
| implement it. In either cases the SCTP termination will be | ||||
| accomplished with limitations as described earlier. | ||||
| The compatibility at network level is proposed in a way that makes it | ||||
| possible deploying a cluster of SCTP termination behind a NAT | ||||
| function still with full compatibility towards legacy networking. As | ||||
| an example, the scenario described in Figure 2 shows Host A being | ||||
| hidden by NAT and Host B being directly connected to the internet. | ||||
| In such case only Host A and NAT need to implement the current | ||||
| specification whilst Host B can neglect it. The same applies to more | ||||
| complex scenarios such as the ones shown in Figure 4 or in Figure 5. | ||||
| 4.5. Differences with Current NAT Support Draft | ||||
| This section describes the differences with the existing draft-ietf- | This section describes the differences with the existing draft-ietf- | |||
| tsvwg-natsupp. | tsvwg-natsupp. | |||
| The main difference is that the NAT function is simpler and doesn't | From a functional perspective, the major difference between is in the | |||
| require explicit handling of NAT missing states. Actually in this | compatibility towards legacy SCTP hosts. The NAT-adaptation | |||
| proposal NAT doesn't need to parse all the SCTP payloads. NAT only | specified in this document allows interoperability between SCTP hosts | |||
| parses INIT chunks, filtering of SCTP packets containing INIT chunks | even when the remote peer hasn't implemented it. Not even is | |||
| is based on checking the SCTP Common Header and discriminate the | mandatory that all the NAT devices in the path do implement it as | |||
| behavior based on Verification Tag = 0, that indicates the SCTP | long as they allow SCTP packets to pass through transparently. On | |||
| the existing draft-ietf-tsvwg-natsupp, the specification needs to be | ||||
| implemented on all SCTP Hosts and all NAT devices in the network in | ||||
| order to work. | ||||
| The main technical difference is that the NAT function is simpler and | ||||
| doesn't require explicit handling of NAT missing states. Actually in | ||||
| this proposal NAT doesn't need to parse all the SCTP payloads. NAT | ||||
| only parses INIT chunks, filtering of SCTP packets containing INIT | ||||
| chunks is based on checking the SCTP Common Header and discriminate | ||||
| the behavior based on Verification Tag = 0, that indicates the SCTP | ||||
| packet contains an INIT chunk. The NAT supervises the association by | packet contains an INIT chunk. The NAT supervises the association by | |||
| means of a timer, if no SCTP packets are seen within a certain time, | means of a timer, if no SCTP packets are seen within a certain time, | |||
| NAT assumes that the association is closed and will remove the | NAT assumes that the association is closed and will remove the | |||
| related NAT-entry. | related NAT-entry. | |||
| The other difference is in the role of the SCTP User. In the current | The other difference is in the role of the SCTP User. In the current | |||
| proposal it's up to the SCTP User to change the originating Endpoint | proposal it's up to the SCTP User to change the originating Endpoint | |||
| (i.e. choose a different port number) if collision is detected. The | (i.e. choose a different port number) if collision is detected. The | |||
| current proposal guarantees that at each node being in a path | current proposal guarantees that at each node being in a path | |||
| belonging to an association, there will be only one 4-uple describing | belonging to an association, there will be only one 4-uple describing | |||
| skipping to change at page 31, line 21 ¶ | skipping to change at page 33, line 21 ¶ | |||
| [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., | [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., | |||
| and F. Gont, "IP Fragmentation Considered Fragile", | and F. Gont, "IP Fragmentation Considered Fragile", | |||
| BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, | BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, | |||
| <https://www.rfc-editor.org/info/rfc8900>. | <https://www.rfc-editor.org/info/rfc8900>. | |||
| Acknowledgments | Acknowledgments | |||
| The author wishes to thank Michael Tuxen , and Magnus Westerlund for | The author wishes to thank Michael Tuxen , and Magnus Westerlund for | |||
| their invaluable comments. | their invaluable comments. | |||
| In addition, the author wishes to thank , for their suggestions. | In addition, the author wishes to thank Sriram Yagnaraman , for their | |||
| suggestions. | ||||
| The author also wishes to thank the authors of draft-ietf-tsvwg- | The author also wishes to thank the authors of draft-ietf-tsvwg- | |||
| natsupp-22 which this document is based. | natsupp-22 which this document is based. | |||
| Author's Address | Author's Address | |||
| Claudio Porfiri | Claudio Porfiri | |||
| Ericsson AB | Ericsson AB | |||
| Torshamnsgatan 21 | Torshamnsgatan 21 | |||
| 16440 Stockholm | 16440 Stockholm | |||
| End of changes. 13 change blocks. | ||||
| 73 lines changed or deleted | 124 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/ | ||||