draft-ietf-tsvwg-natsupp-13.txt   draft-ietf-tsvwg-natsupp-14.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Standards Track M. Tuexen Intended status: Standards Track M. Tuexen
Expires: January 9, 2020 I. Ruengeler Expires: May 7, 2020 I. Ruengeler
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
July 8, 2019 November 4, 2019
Stream Control Transmission Protocol (SCTP) Network Address Translation Stream Control Transmission Protocol (SCTP) Network Address Translation
Support Support
draft-ietf-tsvwg-natsupp-13.txt draft-ietf-tsvwg-natsupp-14
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 for TCP that allows multiple hosts to reside behind been added to NAT for TCP that allows multiple hosts to reside behind
a NAT and yet use only a single globally unique IPv4 address, even a NAT and yet use only a single globally unique IPv4 address, even
when two hosts (behind a NAT) choose the same port numbers for their when two hosts (behind a NAT) choose the same port numbers for their
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 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. Multi Point Traversal . . . . . . . . . . . . . . . . 7 4.1.2. Multi Point Traversal . . . . . . . . . . . . . . . . 7
4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8
4.3. The SCTP Specific Variant of NAT . . . . . . . . . . . . 8 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 8
5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 12 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 12 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 12
5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 13 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 13
5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 13 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 13
5.2.1. VTag and Port Number Collision Error Cause . . . . . 13 5.2.1. VTag and Port Number Collision Error Cause . . . . . 13
5.2.2. Missing State Error Cause . . . . . . . . . . . . . . 14 5.2.2. Missing State Error Cause . . . . . . . . . . . . . . 14
5.2.3. Port Number Collision Error Cause . . . . . . . . . . 15 5.2.3. Port Number Collision Error Cause . . . . . . . . . . 15
5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 15 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 16 5.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 16
skipping to change at page 3, line 5 skipping to change at page 3, line 5
6.2. Handling of Internal Port Number and Verification Tag 6.2. Handling of Internal Port Number and Verification Tag
Collisions . . . . . . . . . . . . . . . . . . . . . . . 18 Collisions . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. NAT Device Considerations . . . . . . . . . . . . . . 19 6.2.1. NAT Device Considerations . . . . . . . . . . . . . . 19
6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 19 6.2.2. Endpoint Considerations . . . . . . . . . . . . . . . 19
6.3. Handling of Internal Port Number Collisions . . . . . . . 19 6.3. Handling of Internal Port Number Collisions . . . . . . . 19
6.3.1. NAT Device Considerations . . . . . . . . . . . . . . 20 6.3.1. NAT Device Considerations . . . . . . . . . . . . . . 20
6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 20
6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21
6.4.1. NAT Device Considerations . . . . . . . . . . . . . . 21 6.4.1. NAT Device Considerations . . . . . . . . . . . . . . 21
6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 21
6.5. Handling of Fragmented SCTP Packets by NAT Devices . . . 22 6.5. Handling of Fragmented SCTP Packets by NAT Devices . . . 23
6.6. Multi-Point Traversal Considerations for Endpoints . . . 23 6.6. Multi-Point Traversal Considerations for Endpoints . . . 23
7. Various Examples of NAT Traversals . . . . . . . . . . . . . 23 7. Various Examples of NAT Traversals . . . . . . . . . . . . . 23
7.1. Single-homed Client to Single-homed Server . . . . . . . 23 7.1. Single-homed Client to Single-homed Server . . . . . . . 23
7.2. Single-homed Client to Multi-homed Server . . . . . . . . 25 7.2. Single-homed Client to Multi-homed Server . . . . . . . . 25
7.3. Multihomed Client and Server . . . . . . . . . . . . . . 28 7.3. Multihomed Client and Server . . . . . . . . . . . . . . 28
7.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 32 7.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 32
7.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . 34 7.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . 34
8. Socket API Considerations . . . . . . . . . . . . . . . . . . 39 8. Socket API Considerations . . . . . . . . . . . . . . . . . . 39
8.1. Get or Set the NAT Friendliness 8.1. Get or Set the NAT Friendliness
(SCTP_NAT_FRIENDLY) . . . . . . . . . . . . . . . . . . . 40 (SCTP_NAT_FRIENDLY) . . . . . . . . . . . . . . . . . . . 40
skipping to change at page 3, line 41 skipping to change at page 3, line 41
TCP [RFC0793]. With the widespread deployment of Network Address TCP [RFC0793]. With the widespread deployment of Network Address
Translators (NAT), specialized code has been added to NAT for TCP Translators (NAT), specialized code has been added to NAT for TCP
that allows multiple hosts to reside behind a NAT using private that allows multiple hosts to reside behind a NAT using private
addresses (see [RFC6890]) and yet use only a single globally unique addresses (see [RFC6890]) and yet use only a single globally unique
IPv4 address, even when two hosts (behind a NAT) choose the same port IPv4 address, even when two hosts (behind a NAT) choose the same port
numbers for their connection. This additional code is sometimes numbers for their connection. This additional code is sometimes
classified as Network Address and Port Translation (NAPT). Please classified as Network Address and Port Translation (NAPT). Please
note that this document focuses on the case where the NAT maps note that this document focuses on the case where the NAT maps
multiple private addresses to a single public address. To date, multiple private addresses to a single public address. To date,
specialized code for SCTP has not yet been added to most NAT devices specialized code for SCTP has not yet been added to most NAT devices
so that only true NAT is available. The end result of this is that so that only a translation of IP addresses is supported. The end
only one SCTP capable host can be behind a NAT and this host can only result of this is that only one SCTP-capable host can successfully
be single-homed. The only alternative for supporting legacy NAT operate behind such a NAT and this host can only be single-homed.
devices is to use UDP encapsulation as specified in [RFC6951]. The only alternative for supporting legacy NAT devices is to use UDP
encapsulation as specified in [RFC6951].
This document specifies procedures allowing a NAT to support SCTP by This document specifies procedures allowing a NAT to support SCTP by
providing similar features to those provided by a NAPT for TCP and providing similar features to those provided by a NAPT for TCP and
other supported protocols. The document also specifies a set of data other supported protocols. The document also specifies a set of data
formats for SCTP packets and a set of SCTP endpoint procedures to formats for SCTP packets and a set of SCTP endpoint procedures to
support NAT traversal. An SCTP implementation supporting these support NAT traversal. An SCTP implementation supporting these
procedures can assure that in both single-homed and multi-homed cases procedures can assure that in both single-homed and multi-homed cases
a NAT will maintain the proper state without needing to change port a NAT will maintain the appropriate state without the NAT needing to
numbers. change port numbers.
It is possible and desirable to make these changes for a number of It is possible and desirable to make these changes for a number of
reasons: reasons:
o It is desirable for SCTP internal end-hosts on multiple platforms o It is desirable for SCTP internal end-hosts on multiple platforms
to be able to share a NAT's public IP address in the same way that to be able to share a NAT's public IP address in the same way that
a TCP session can use a NAT. a TCP session can use a NAT.
o If a NAT does not need to change any data within an SCTP packet it o If a NAT does not need to change any data within an SCTP packet it
will reduce the processing burden of NAT'ing SCTP by NOT needing will reduce the processing burden of NAT'ing SCTP by NOT needing
skipping to change at page 5, line 10 skipping to change at page 5, line 10
device does not handle SCTP packets at all and all SCTP packets sent device does not handle SCTP packets at all and all SCTP packets sent
externally from behind a NAT device are discarded by the NAT. In externally from behind a NAT device are discarded by the NAT. In
some cases, where the NAT device supports the feature but one of the some cases, where the NAT device supports the feature but one of the
two hosts does not support the feature, communication may occur but two hosts does not support the feature, communication may occur but
in a limited way. For example only one host may be able to have a in a limited way. For example only one host may be able to have a
connection when a collision case occurs. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology 3. Terminology
This document uses the following terms, which are depicted in This document uses the following terms, which are depicted in
Figure 1. Familiarity with the terminology used in [RFC4960] and Figure 1. Familiarity with the terminology used in [RFC4960] and
[RFC5061] is assumed. [RFC5061] is assumed.
Private-Address (Priv-Addr): The private address that is known to Private-Address (Priv-Addr): The private address that is known to
the internal host. the internal host.
Internal-Port (Int-Port): The port number that is in use by the host Internal-Port (Int-Port): The port number that is in use by the host
holding the Private-Address. holding the Private-Address.
Internal-VTag (Int-VTag): The SCTP Verification Tag (VTag) that the Internal-VTag (Int-VTag): The SCTP Verification Tag (VTag) (see
internal host has chosen for its communication. The VTag is a Section 3.1 of [RFC4960]) that the internal host has chosen for
unique 32-bit tag that must accompany any incoming SCTP packet for its communication. The VTag is a unique 32-bit tag that must
this association to the Private-Address. accompany any incoming SCTP packet for this association to the
Private-Address.
External-Address (Ext-Addr): The address that an internal host is External-Address (Ext-Addr): The address that an internal host is
attempting to contact. attempting to contact.
External-Port (Ext-Port): The port number of the peer process at the External-Port (Ext-Port): The port number of the peer process at the
External-Address. External-Address.
External-VTag (Ext-VTag): The Verification Tag that the host holding External-VTag (Ext-VTag): The Verification Tag that the host holding
the External-Address has chosen for its communication. The VTag the External-Address has chosen for its communication. The VTag
is a unique 32-bit tag that must accompany any incoming SCTP is a unique 32-bit tag that must accompany any incoming SCTP
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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 may result in changing one of the SCTP port Using classical NAPT may result in changing one of the SCTP port
numbers during the processing which requires the recomputation of the numbers during the processing which requires the recomputation of the
transport layer checksum. Whereas for UDP and TCP this can be done transport layer checksum by the NAPT device. Whereas for UDP and TCP
very efficiently, for SCTP the checksum (CRC32c) over the entire this can be done very efficiently, for SCTP the checksum (CRC32c)
packet needs to be recomputed. This would considerably add to the over the entire packet needs to be recomputed. See Appendix B of
NAT computational burden, however hardware support may mitigate this [RFC4960] for details of the CRC32c computation. This would
in some implementations. considerably add to the NAT computational burden, however hardware
support may mitigate this in some implementations.
An SCTP endpoint may have multiple addresses but only has a single An SCTP endpoint may have multiple addresses but only has a single
port number. To make multipoint traversal work, all the NAT devices port number. To make multipoint traversal work, all the NAT devices
involved must recognize the packets they see as belonging to the same involved must recognize the packets they see as belonging to the same
SCTP association and perform port number translation in a consistent SCTP association and perform port number translation in a consistent
way. One possible way of doing this is to use pre-defined table of way. One possible way of doing this is to use a pre-defined table of
ports and addresses configured within each NAT. Other mechanisms ports and addresses configured within each NAT. Other mechanisms
could make use of NAT to NAT communication. Such mechanisms are not could make use of NAT to NAT communication. Such mechanisms have not
to be deployable on a wide scale base and thus not a recommended been deployabled on a wide scale base and thus are not a recommended
solution. Therefore the SCTP variant of NAT has been developed. solution. Therefore the SCTP variant of NAT has been developed.
4.3. The SCTP Specific Variant of NAT 4.3. The SCTP-Specific Variant of NAT
In this section it is assumed that there are multiple SCTP capable In this section it is allowed that there are multiple SCTP capable
hosts behind a NAT that has one Public-Address. Furthermore this hosts behind a NAT that has one Public-Address. Furthermore this
section focuses on the single point traversal scenario. section focuses on the single point traversal scenario.
The modification of SCTP packets sent to the public Internet is The modification of SCTP packets sent to the public Internet is
simple: the source address of the packet has to be replaced with the simple: the source address of the packet has to be replaced with the
Public-Address. It may also be necessary to establish some state in Public-Address. It may also be necessary to establish some state in
the NAT device to later handle incoming packets. the NAT device to later handle incoming packets.
For the SCTP NAT processing the NAT device has to maintain a table of For the SCTP NAT processing the NAT device has to maintain a NAT
Internal-VTag, Internal-Port, External-VTag, External-Port, Private- binding table of Internal-VTag, Internal-Port, External-VTag,
Address, and whether the restart procedure is disabled or not. An External-Port, Private-Address, and whether the restart procedure is
entry in that table is called a NAT state control block. The disabled or not. An entry in that NAT binding table is called a NAT
function Create() obtains the just mentioned parameters and returns a state control block. The function Create() obtains the just
NAT-State control block. mentioned parameters and returns a NAT-State control block.
For SCTP packets coming from the public Internet the destination For SCTP packets coming from the public Internet the destination
address of the packets has to be replaced with the Private-Address of address of the packets has to be replaced with the Private-Address of
the host the packet has to be delivered to. The lookup of the the host the packet has to be delivered to. The lookup of the
Private-Address is based on the External-VTag, External-Port, Private-Address is based on the External-VTag, External-Port,
Internal-VTag and the Internal-Port. Internal-VTag and the Internal-Port.
The entries in the table fulfill some uniqueness conditions. There The entries in the NAT binding table need to fulfill some uniqueness
must not be more than one entry with the same pair of Internal-Port conditions. There must not be more than one entry NAT binding table
and External-Port. This rule can be relaxed, if all entries with the with the same pair of Internal-Port and External-Port. This rule can
same Internal-Port and External-Port have the support for the restart be relaxed, if all NAT binding table entries with the same Internal-
procedure enabled. In this case there must be no more than one entry Port and External-Port have the support for the restart procedure
with the same Internal-Port, External-Port and Ext-VTag and no more enabled. In this case there must be no more than one entry with the
than one entry with the same Internal-Port, External-Port and Int- same Internal-Port, External-Port and Ext-VTag and no more than one
VTag. NAT binding table entry with the same Internal-Port, External-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 described in the following figure. The scenario shown is valid for
all message flows in this section. all message flows in this section.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Internet | <------> | Host B | | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\---/ \--/\---/
skipping to change at page 9, line 33 skipping to change at page 9, line 35
Create(Initiate-Tag, Int-Port, 0, Ext-Port, Priv-Addr, Create(Initiate-Tag, Int-Port, 0, Ext-Port, Priv-Addr,
RestartSupported) RestartSupported)
Returns(NAT-State control block) Returns(NAT-State control block)
Translate To: Translate To:
INIT[Initiate-Tag] INIT[Initiate-Tag]
Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port
Ext-VTag=0 Ext-VTag=0
Normally a NAT control block will be created. However, it is Normally a NAT binding table entry will be created.
possible that there is already a NAT control block with the same
External-Address, External-Port, Internal-Port, and Internal-VTag but However, it is possible that there is already a NAT binding table
different Private-Address. In this case the INIT MUST be dropped by entry with the same External-Address, External-Port, Internal-Port,
the NAT and an ABORT MUST be sent back to the SCTP host with the and Internal-VTag but different Private-Address. In this case the
M-Bit set and an appropriate error cause (see Section 5.1.1 for the INIT MUST be dropped by the NAT and an ABORT MUST be sent back to the
format). The source address of the packet containing the ABORT chunk SCTP host with the M-Bit set and an appropriate error cause (see
MUST be the destination address of the packet containing the INIT Section 5.1.1 for the format). The source address of the packet
chunk. containing the ABORT chunk MUST be the destination address of the
packet containing the INIT chunk.
It is also possible that a connection to External-Address and It is also possible that a connection to External-Address and
External-Port exists without an Internal-VTag conflict but the External-Port exists without an Internal-VTag conflict but the
External-Address does not support the DISABLE_RESTART feature (noted External-Address does not support the DISABLE_RESTART feature (noted
in the NAT control block when the prior connection was established). in the NAT binding table entry when the prior connection was
In such a case the INIT SHOULD be dropped by the NAT and an ABORT established). In such a case the INIT SHOULD be dropped by the NAT
SHOULD be sent back to the SCTP host with the M-Bit set and an and an ABORT SHOULD be sent back to the SCTP host with the M-Bit set
appropriate error cause (see Section 5.1.1 for the format). and an appropriate error cause (see Section 5.1.1 for the format).
The processing of outgoing SCTP packets containing no INIT-chunk is The processing of outgoing SCTP packets containing no INIT-chunk is
described in the following figure. described in the following figure.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Internet | <------> | Host B | | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\---/ \--/\---/
skipping to change at page 10, line 27 skipping to change at page 10, line 29
Ext-VTag Ext-VTag
Translate To: Translate To:
Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port
Ext-VTag Ext-VTag
The processing of incoming SCTP packets containing INIT-ACK chunks is The processing of incoming SCTP packets containing INIT-ACK chunks is
described in the following figure. The Lookup() function getting as described in the following figure. The Lookup() function getting as
input the Internal-VTag, Internal-Port, External-VTag, and External- input the Internal-VTag, Internal-Port, External-VTag, and External-
Port, returns the corresponding entry of the NAT table and updates Port, returns the corresponding entry of the NAT binding table and
the External-VTag by substituting it with the value of the Initiate- updates the External-VTag by substituting it with the value of the
Tag of the INIT-ACK chunk. The wildcard character signifies that the Initiate-Tag of the INIT-ACK chunk. The wildcard character signifies
parameter's value is not considered in the Lookup() function or that the parameter's value is not considered in the Lookup() function
changed in the Update() function, respectively. or changed in the Update() function, respectively.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Internet | <------> | Host B | | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\---/ \--/\---/
INIT-ACK[Initiate-Tag] INIT-ACK[Initiate-Tag]
Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port
Int-VTag Int-VTag
skipping to change at page 12, line 24 skipping to change at page 12, line 24
Lookup(Int-VTag, Int-Port, *, Ext-Port) Lookup(Int-VTag, Int-Port, *, Ext-Port)
Returns(NAT-State control block containing Local-Address) Returns(NAT-State control block containing Local-Address)
Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port
Int-VTag Int-VTag
For an incoming packet containing an INIT-chunk a table lookup is For an incoming packet containing an INIT-chunk a table lookup is
made only based on the addresses and port numbers. If an entry with made only based on the addresses and port numbers. If an entry with
an External-VTag of zero is found, it is considered a match and the an External-VTag of zero is found, it is considered a match and the
External-VTag is updated. External-VTag is updated. This allows the handling of INIT-collision
through NAT.
This allows the handling of INIT-collision through NAT.
5. Data Formats 5. Data Formats
This section defines the formats used to support NAT traversal. This section defines the formats used to support NAT traversal.
Section 5.1 and Section 5.2 describe chunks and error causes sent by Section 5.1 and Section 5.2 describe chunks and error causes sent by
NAT devices and received by SCTP endpoints. Section 5.3 describes NAT devices and received by SCTP endpoints. Section 5.3 describes
parameters sent by SCTP endpoints and used by NAT devices and SCTP parameters sent by SCTP endpoints and used by NAT devices and SCTP
endpoints. endpoints.
5.1. Modified Chunks 5.1. Modified Chunks
skipping to change at page 19, line 8 skipping to change at page 19, line 8
6.2. Handling of Internal Port Number and Verification Tag Collisions 6.2. Handling of Internal Port Number and Verification Tag Collisions
Consider the case where two hosts in the Private-Address space want Consider the case where two hosts in the Private-Address space want
to set up an SCTP association with the same service provided by some to set up an SCTP association with the same service provided by some
hosts in the Internet. This means that the External-Port is the hosts in the Internet. This means that the External-Port is the
same. If they both choose the same Internal-Port and Internal-VTag, same. If they both choose the same Internal-Port and Internal-VTag,
the NAT device cannot distinguish between incoming packets anymore. the NAT device cannot distinguish between incoming packets anymore.
But this is very unlikely. The Internal-VTags are chosen at random But this is very unlikely. The Internal-VTags are chosen at random
and if the Internal-Ports are also chosen from the ephemeral port and if the Internal-Ports are also chosen from the ephemeral port
range at random this gives a 46-bit random number which has to match. range at random this gives a 46-bit random number that has to match.
In the TCP-like NAPT case the NAT device can control the 16-bit A NAPT device can control the 16-bit Natted Port and therefore avoid
Natted Port and therefore avoid collisions deterministically. collisions deterministically.
The same can happen with the External-VTag when an INIT-ACK chunk or The same can happen with the External-VTag when an INIT-ACK chunk or
an ASCONF chunk is processed by the NAT. an ASCONF chunk is processed by the NAT.
6.2.1. NAT Device Considerations 6.2.1. NAT Device Considerations
However, in this unlikely event the NAT device MUST send an ABORT If the NAT device detects a collision of internal port numbers and
chunk with the M-bit set if the collision is triggered by an INIT or verification tags, it MUST send an ABORT chunk with the M-bit set if
INIT-ACK chunk or send an ERROR chunk with the M-bit set if the the collision is triggered by an INIT or INIT-ACK chunk. If such a
collision is triggered by an ASCONF chunk. The M-bit is a new bit collision is triggered by an ASCONF chunk, it MUST send an ERROR
defined by this document to express to SCTP that the source of this chunk with the M-bit. The M-bit is a new bit defined by this
packet is a "middle" box, not the peer SCTP endpoint (see document to express to SCTP that the source of this packet is a
Section 5.1.1). If a packet containing an INIT-ACK chunk triggers "middle" box, not the peer SCTP endpoint (see Section 5.1.1). If a
the collision, the corresponding packet containing the ABORT chunk packet containing an INIT-ACK chunk triggers the collision, the
MUST contain the same source and destination address and port numbers corresponding packet containing the ABORT chunk MUST contain the same
as the packet containing the INIT-ACK chunk. In the other two cases, source and destination address and port numbers as the packet
the source and destination address and port numbers MUST be swapped. containing the INIT-ACK chunk. In the other two cases, the source
and destination address and port numbers MUST be swapped.
The sender of the ERROR or ABORT chunk MUST include the error cause The sender of the ERROR or ABORT chunk MUST include the error cause
with cause code 'VTag and Port Number Collision' (see Section 5.2.1). with cause code 'VTag and Port Number Collision' (see Section 5.2.1).
6.2.2. Endpoint Considerations 6.2.2. Endpoint Considerations
The sender of the packet containing the INIT chunk or the receiver of The sender of the packet containing the INIT chunk or the receiver of
the INIT-ACK chunk, upon reception of an ABORT chunk with M-bit set the INIT-ACK chunk, upon reception of an ABORT chunk with M-bit set
and the appropriate error cause code for colliding NAT table state is and the appropriate error cause code for colliding NAT binding table
included, MUST reinitiate the association setup procedure after state is included, MUST reinitiate the association setup procedure
choosing a new initiate tag, if the association is in COOKIE-WAIT after choosing a new initiate tag, if the association is in COOKIE-
state. In any other state, the SCTP endpoint MUST NOT respond. WAIT state. In any other state, the SCTP endpoint MUST NOT respond.
The sender of the ASCONF chunk, upon reception of an ERROR chunk with The sender of the ASCONF chunk, upon reception of an ERROR chunk with
M-bit set, MUST stop adding the path to the association. M-bit set, MUST stop adding the path to the association.
6.3. Handling of Internal Port Number Collisions 6.3. Handling of Internal Port Number Collisions
When two SCTP hosts are behind an SCTP-aware NAT it is possible that When two SCTP hosts are behind an SCTP-aware NAT it is possible that
two SCTP hosts in the Private-Address space will want to set up an two SCTP hosts in the Private-Address space will want to set up an
SCTP association with the same server running on the same host in the SCTP association with the same server running on the same host in the
Internet. For the NAT, appropriate tracking may be performed by Internet. For the NAT, appropriate tracking may be performed by
assuring that the VTags are unique between the two hosts. assuring that the VTags are unique between the two hosts.
6.3.1. NAT Device Considerations 6.3.1. NAT Device Considerations
The NAT, when processing the INIT-ACK, should note in its internal The NAT, when processing the INIT-ACK, should note in its NAT binding
table that the association supports the Disable Restart extension. table that the association supports the Disable Restart extension.
This note is used when establishing future associations (i.e. when This note is used when establishing future associations (i.e. when
processing an INIT from an internal host) to decide if the connection processing an INIT from an internal host) to decide if the connection
should be allowed. The NAT device does the following when processing should be allowed. The NAT device does the following when processing
an INIT: an INIT:
o If the INIT is destined to an external address and port for which o If the INIT is destined to an external address and port for which
the NAT device has no outbound connection, it MUST allow the INIT the NAT device has no outbound connection, it MUST allow the INIT
creating an internal mapping table. creating an NAT binding table entry.
o If the INIT matches the external address and port of an already o If the INIT matches the external address and port of an already
existing connection, it MUST validate that the external server existing connection, it MUST validate that the external server
supports the Disable Restart feature and, if it does, allow the supports the Disable Restart feature and, if it does, allow the
INIT to be forwarded. INIT to be forwarded.
o If the external server does not support the Disable Restart o If the external server does not support the Disable Restart
extension the NAT device MUST send an ABORT with the M-bit set. extension the NAT device MUST send an ABORT with the M-bit set.
The 'Port Number Collision' error cause (see Section 5.2.3) MUST be The 'Port Number Collision' error cause (see Section 5.2.3) MUST be
included in the ABORT chunk. included in the ABORT chunk sent in response to the INIT chunk.
If the collision is triggered by an ASCONF chunk, a packet containing If the collision is triggered by an ASCONF chunk, a packet containing
an ERROR chunk with the 'Port Number Collision' error cause MUST be an ERROR chunk with the 'Port Number Collision' error cause MUST be
sent back. sent in response to the ASCONF chunk.
6.3.2. Endpoint Considerations 6.3.2. Endpoint Considerations
For the external SCTP server on the Internet this means that the For the external SCTP server on the Internet this means that the
External-Port and the External-Address are the same. If they both External-Port and the External-Address are the same. If they both
have chosen the same Internal-Port the server cannot distinguish have chosen the same Internal-Port the server cannot distinguish
between both associations based on the address and port numbers. For between both associations based on the address and port numbers. For
the server it looks like the association is being restarted. To the server it looks like the association is being restarted. To
overcome this limitation the client sends a Disable Restart parameter overcome this limitation the client sends a Disable Restart parameter
in the INIT-chunk. in the INIT-chunk.
skipping to change at page 21, line 14 skipping to change at page 21, line 14
Servers that support this feature will need to be capable of Servers that support this feature will need to be capable of
maintaining multiple connections to what appears to be the same peer maintaining multiple connections to what appears to be the same peer
(behind the NAT) differentiated only by the VTags. (behind the NAT) differentiated only by the VTags.
6.4. Handling of Missing State 6.4. Handling of Missing State
6.4.1. NAT Device Considerations 6.4.1. NAT Device Considerations
If the NAT device receives a packet from the internal network for If the NAT device receives a packet from the internal network for
which the lookup procedure does not find an entry in the NAT table, a which the lookup procedure does not find an entry in the NAT binding
packet containing an ERROR chunk is sent back with the M-bit set. table, a packet containing an ERROR chunk is sent back with the M-bit
The source address of the packet containing the ERROR chunk MUST be set. The source address of the packet containing the ERROR chunk
the destination address of the incoming SCTP packet. The MUST be the destination address of the incoming SCTP packet. The
verification tag is reflected and the T-bit is set. Please note that verification tag is reflected and the T-bit is set. Such a packet
such a packet containing an ERROR chunk SHOULD NOT be sent if the containing an ERROR chunk SHOULD NOT be sent if the received packet
received packet contains an ABORT, SHUTDOWN-COMPLETE or INIT-ACK contains an ABORT, SHUTDOWN-COMPLETE or INIT-ACK chunk. An ERROR
chunk. An ERROR chunk MUST NOT be sent if the received packet chunk MUST NOT be sent if the received packet contains an ERROR chunk
contains an ERROR chunk with the M-bit set. with the M-bit set.
When sending the ERROR chunk, the new error cause 'Missing State' When sending the ERROR chunk, the error cause 'Missing State' (see
(see Section 5.2.2) MUST be included and the new M-bit of the ERROR Section 5.2.2) MUST be included and the M-bit of the ERROR chunk MUST
chunk MUST be set (see Section 5.1.2). be set (see Section 5.1.2).
If the NAT device receives a packet for which it has no NAT table If the NAT device receives a packet for which it has no NAT binding
entry and the packet contains an ASCONF chunk with the VTags table entry and the packet contains an ASCONF chunk with the VTags
parameter, the NAT device MUST update its NAT table according to the parameter, the NAT device MUST update its NAT binding table according
verification tags in the VTags parameter and the optional Disable to the verification tags in the VTags parameter and the optional
Restart parameter. Disable Restart parameter.
6.4.2. Endpoint Considerations 6.4.2. Endpoint Considerations
Upon reception of this ERROR chunk by an SCTP endpoint the receiver Upon reception of this ERROR chunk by an SCTP endpoint the receiver
takes the following actions: takes the following actions:
o It SHOULD validate that the verification tag is reflected by o It SHOULD validate that the verification tag is reflected by
looking at the VTag that would have been included in the outgoing looking at the VTag that would have been included in the outgoing
packet. packet. If the validation fails, discard the incoming ERROR
chunk.
o It SHOULD validate that the peer of the SCTP association supports o It SHOULD validate that the peer of the SCTP association supports
the dynamic address extension, if it does not discard the incoming the dynamic address extension. If the validation fails, discard
ERROR chunk. the incoming ERROR chunk.
o It SHOULD generate a new ASCONF chunk containing the VTags o It SHOULD generate a new ASCONF chunk containing the VTags
parameter (see Section 5.3.2) and the Disable Restart parameter if parameter (see Section 5.3.2) and the Disable Restart parameter if
the association is using the disabled restart feature. By the association is using the disabled restart feature. By
processing this packet the NAT device can recover the appropriate processing this packet the NAT device can recover the appropriate
state. The procedures for generating an ASCONF chunk can be found state. The procedures for generating an ASCONF chunk can be found
in [RFC5061]. in [RFC5061].
The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either The peer SCTP endpoint receiving such an ASCONF chunk SHOULD either
add the address and respond with an acknowledgment, if the address is add the address and respond with an acknowledgment, if the address is
new to the association (following all procedures defined in new to the association (following all procedures defined in
[RFC5061]). Or, if the address is already part of the association, [RFC5061]). Or, if the address is already part of the association,
the SCTP endpoint MUST NOT respond with an error, but instead should the SCTP endpoint MUST NOT respond with an error, but instead SHOULD
respond with an ASCONF-ACK chunk acknowledging the address but take respond with an ASCONF-ACK chunk acknowledging the address and take
no action (since the address is already in the association). no action (since the address is already in the association).
Note that it is possible that upon receiving an ASCONF chunk Note that it is possible that upon receiving an ASCONF chunk
containing the VTags parameter the NAT will realize that it has an containing the VTags parameter the NAT will realize that it has an
'Internal Port Number and Verification Tag collision'. In such a 'Internal Port Number and Verification Tag collision'. In such a
case the NAT MUST send an ERROR chunk with the error cause code set case the NAT MUST send an ERROR chunk with the error cause code set
to 'VTag and Port Number Collision' (see Section 5.2.1). to 'VTag and Port Number Collision' (see Section 5.2.1).
If an SCTP endpoint receives an ERROR with 'Internal Port Number and If an SCTP endpoint receives an ERROR with 'Internal Port Number and
Verification Tag collision' as the error cause and the packet in the Verification Tag collision' as the error cause and the packet in the
Error Chunk contains an ASCONF with the VTags parameter, careful Error Chunk contains an ASCONF with the VTags parameter, careful
examination of the association is required. The endpoint does the examination of the association is required. The endpoint does the
following: following:
o It MUST validate that the verification tag is reflected by looking o It MUST validate that the verification tag is reflected by looking
at the VTag that would have been included in the outgoing packet. at the VTag that would have been included in the outgoing packet.
If the validation fails, it MUST discard the packet.
o It MUST validate that the peer of the SCTP association supports o It MUST validate that the peer of the SCTP association supports
the dynamic address extension. If the peer does not support it, the dynamic address extension. If the peer does not support it,
the NAT Device MUST discard the incoming ERROR chunk. the NAT Device MUST discard the incoming ERROR chunk.
o If the association is attempting to add an address (i.e. following o If the association is attempting to add an address (i.e. following
the procedures in Section 6.6) then the endpoint MUST NOT consider the procedures in Section 6.6) then the endpoint MUST NOT consider
the address part of the association and SHOULD make no further the address part of the association and SHOULD make no further
attempt to add the address (i.e. cancel any ASCONF timers and attempt to add the address (i.e. cancel any ASCONF timers and
remove any record of the path), since the NAT devie has a VTag remove any record of the path), since the NAT devie has a VTag
collision and the association cannot easily create a new VTag (as collision and the association cannot easily create a new VTag (as
it would if the error occurred when sending an INIT). it would if the error occurred when sending an INIT).
o If the endpoint has no other path, i.e. the procedure was executed o If the endpoint has no other path, i.e. the procedure was executed
due to missing a state in the NAT device , then the endpoint MUST due to missing a state in the NAT device, then the endpoint MUST
abort the association. This would occur only if the local NAT abort the association. This would occur only if the local NAT
device restarted and accepted a new association before attempting device restarted and accepted a new association before attempting
to repair the missing state (Note that this is no different than to repair the missing state (Note that this is no different than
what happens to all TCP connections when a NAT device looses its what happens to all TCP connections when a NAT device looses its
state). state).
6.5. Handling of Fragmented SCTP Packets by NAT Devices 6.5. Handling of Fragmented SCTP Packets by NAT Devices
A NAT device MUST support IP reassembly of received fragmented SCTP A NAT device MUST support IP reassembly of received fragmented SCTP
packets. The fragments may arrive in any order. packets. The fragments may arrive in any order.
skipping to change at page 27, line 17 skipping to change at page 27, line 17
+------+ +-----+ / \ / +--------+ \ +------+ +------+ +-----+ / \ / +--------+ \ +------+
| Host | <-----> | NAT | <-> | Internet | == =| Host | | Host | <-----> | NAT | <-> | Internet | == =| Host |
| A | +-----+ \ / \ +--------+ / | B | | A | +-----+ \ / \ +--------+ / | B |
+------+ \--/\--/ \-|Router 2|-/ +------+ +------+ \--/\--/ \-|Router 2|-/ +------+
+--------+ +--------+
INIT-ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129] INIT-ACK[Initiate-tag = 5678, IP-Addr = 203.0.113.129]
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
NAT does need to change the table for second address: NAT does need to change the NAT binding table for the second address:
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
NAT | Int | Int | Ext | Ext | Priv | NAT | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
| 1234 | 1 | 5678 | 2 | 10.0.0.1 | | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
INIT-ACK[Initiate-Tag = 5678] INIT-ACK[Initiate-Tag = 5678]
10.0.0.1:1 <--- 203.0.113.1:2 10.0.0.1:1 <--- 203.0.113.1:2
skipping to change at page 30, line 17 skipping to change at page 30, line 17
+------+ / +-------+ \ / \ +--------+ +------+ / +-------+ \ / \ +--------+
| Host |=== ====| Internet |===| Host B | | Host |=== ====| Internet |===| Host B |
| A | \ +-------+ / \ / +--------+ | A | \ +-------+ / \ / +--------+
+------+ \--------| NAT 2 |--------/ \--/\--/ +------+ \--------| NAT 2 |--------/ \--/\--/
+-------+ +-------+
INIT-ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129] INIT-ACK[Initiate-Tag = 5678, IP-Addr = 203.0.113.129]
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
NAT 1 does not need to update the table for second address: NAT 1 does not need to update the NAT binding table for the second
address:
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
NAT 1 | Int | Int | Ext | Ext | Priv | NAT 1 | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
| 1234 | 1 | 5678 | 2 | 10.0.0.1 | | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
INIT-ACK[Initiate-Tag = 5678] INIT-ACK[Initiate-Tag = 5678]
10.0.0.1:1 <-------- 203.0.113.1:2 10.0.0.1:1 <-------- 203.0.113.1:2
skipping to change at page 31, line 33 skipping to change at page 31, line 33
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
Host A announces its second address in an ASCONF chunk. The address Host A announces its second address in an ASCONF chunk. The address
parameter contains an undefined address (0) to indicate that the parameter contains an undefined address (0) to indicate that the
source address should be added. The lookup address parameter within source address should be added. The lookup address parameter within
the ASCONF chunk will also contain the pair of VTags (external and the ASCONF chunk will also contain the pair of VTags (external and
internal) so that the NAT may populate its table completely with this internal) so that the NAT may populate its NAT binding table entry
single packet. completely with this single packet.
+-------+ +-------+
/--------| NAT 1 |--------\ /--\/--\ /--------| NAT 1 |--------\ /--\/--\
+------+ / +-------+ \ / \ +--------+ +------+ / +-------+ \ / \ +--------+
| Host |=== ====| Internet |===| Host B | | Host |=== ====| Internet |===| Host B |
| A | \ +-------+ / \ / +--------+ | A | \ +-------+ / \ / +--------+
+------+ \--------| NAT 2 |--------/ \--/\--/ +------+ \--------| NAT 2 |--------/ \--/\--/
+-------+ +-------+
ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678] ASCONF [ADD-IP=0.0.0.0, INT-VTag=1234, Ext-VTag = 5678]
10.1.0.1:1 --------> 203.0.113.129:2 10.1.0.1:1 --------> 203.0.113.129:2
Ext-VTag = 5678 Ext-VTag = 5678
NAT 2 creates complete entry: NAT 2 creates a complete entry:
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
NAT 2 | Int | Int | Ext | Ext | Priv | NAT 2 | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
| 1234 | 1 | 5678 | 2 | 10.1.0.1 | | 1234 | 1 | 5678 | 2 | 10.1.0.1 |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
ASCONF [ADD-IP,Int-VTag=1234, Ext-VTag = 5678] ASCONF [ADD-IP, Int-VTag=1234, Ext-VTag = 5678]
192.0.2.129:1 ---------------------> 203.0.113.129:2 192.0.2.129:1 ---------------------> 203.0.113.129:2
Ext-VTag = 5678 Ext-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
skipping to change at page 32, line 47 skipping to change at page 33, line 5
NAT | Int | Int | Ext | Ext | Priv | NAT | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
| 1234 | 1 | 5678 | 2 | 10.0.0.1 | | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
DATA DATA
10.0.0.1:1 ----------> 203.0.113.1:2 10.0.0.1:1 ----------> 203.0.113.1:2
Ext-VTag = 5678 Ext-VTag = 5678
The NAT device cannot find entry for the association. It sends ERROR The NAT device cannot find an entry in the NAT binding table for the
message with the M-Bit set and the cause "NAT state missing". association. It sends ERROR an message with the M-Bit set and the
cause "NAT state missing".
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <----------> | NAT | <----> | Internet | <----> | Host B | | Host A | <----------> | NAT | <----> | Internet | <----> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\--/ \--/\--/
ERROR [M-Bit, NAT state missing] ERROR [M-Bit, NAT state missing]
10.0.0.1:1 <---------- 203.0.113.1:2 10.0.0.1:1 <---------- 203.0.113.1:2
Ext-VTag = 5678 Ext-VTag = 5678
skipping to change at page 33, line 25 skipping to change at page 33, line 29
On reception of the ERROR message, Host A sends an ASCONF chunk On reception of the ERROR message, Host A sends an ASCONF chunk
indicating that the former information has to be deleted and the indicating that the former information has to be deleted and the
source address of the actual packet added. source address of the actual packet added.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <----------> | NAT | <----> | Internet | <----> | Host B | | Host A | <----------> | NAT | <----> | Internet | <----> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\--/ \--/\--/
ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Ext-VTag = 5678]
10.0.0.1:1 ----------> 203.0.113.129:2 10.0.0.1:1 ----------> 203.0.113.129:2
Ext-VTag = 5678 Ext-VTag = 5678
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
NAT | Int | Int | Ext | Ext | Priv | NAT | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
| 1234 | 1 | 5678 | 2 | 10.0.0.1 | | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
ASCONF [ADD-IP,DELETE-IP,Int-VTag=1234, Ext-VTag = 5678] ASCONF [ADD-IP, DELETE-IP, Int-VTag=1234, Ext-VTag = 5678]
192.0.2.2:1 -------------------> 203.0.113.129:2 192.0.2.2:1 -------------------> 203.0.113.129:2
Ext-VTag = 5678 Ext-VTag = 5678
Host B adds the new source address and deletes all former entries. Host B adds the new source address to this association and deletes
all other addresses from this association.
/--\/--\ /--\/--\
+--------+ +-----+ / \ +--------+ +--------+ +-----+ / \ +--------+
| Host A | <----------> | NAT | <----> | Internet | <----> | Host B | | Host A | <----------> | NAT | <----> | Internet | <----> | Host B |
+--------+ +-----+ \ / +--------+ +--------+ +-----+ \ / +--------+
\--/\--/ \--/\--/
ASCONF-ACK ASCONF-ACK
192.0.2.2:1 <------------------- 203.0.113.129:2 192.0.2.2: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
DATA DATA
10.0.0.1:1 ----------> 203.0.113.1:2 10.0.0.1:1 ----------> 203.0.113.1:2
Ext-VTag = 5678 Ext-VTag = 5678
DATA DATA
192.0.2.2:1 -------------------> 203.0.113.129:2 192.0.2.2:1 -------------------> 203.0.113.129:2
Ext-VTag = 5678 Ext-VTag = 5678
7.5. Peer-to-Peer Communication 7.5. Peer-to-Peer Communication
If two hosts are behind NAT devices, they have to get knowledge of If two hosts are behind NAT devices and want to communicate with each
the peer's public address. This can be achieved with a so-called other, they have to get knowledge of the peer's public address. This
rendezvous server. Afterwards the destination addresses are public, can be achieved with a so-called rendezvous server. Afterwards the
and the association is set up with the help of the INIT collision. destination addresses are public, and the association is set up with
The NAT devices create their entries according to their internal the help of the INIT collision. The NAT devices create their entries
peer's point of view. Therefore, NAT A's Internal-VTag and Internal- according to their internal peer's point of view. Therefore, NAT A's
Port are NAT B's External-VTag and External-Port, respectively. The Internal-VTag and Internal-Port are NAT B's External-VTag and
naming of the verification tag in the packet flow is done from the External-Port, respectively. The naming (internal/external) of the
sending peer's point of view. verification tag in the packet flow is done from the sending host's
point of view.
Internal | External External | Internal Internal | External External | Internal
| | | |
| /--\/---\ | | /--\/---\ |
+--------+ +-------+ / \ +-------+ +--------+ +--------+ +-------+ / \ +-------+ +--------+
| Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B |
+--------+ +-------+ \ / +-------+ +--------+ +--------+ +-------+ \ / +-------+ +--------+
| \--/\---/ | | \--/\---/ |
NAT-Tables NAT Binding Tables
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
NAT A | Int | Int | Ext | Ext | Priv | NAT A | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
NAT B | Int | Int | Ext | Ext | Priv | NAT B | Int | Int | Ext | Ext | Priv |
| v-tag | port | v-tag | port | Addr | | v-tag | port | v-tag | port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
skipping to change at page 35, line 42 skipping to change at page 35, line 42
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
| 1234 | 1 | 0 | 2 | 10.0.0.1 | | 1234 | 1 | 0 | 2 | 10.0.0.1 |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
INIT[Initiate-Tag = 1234] INIT[Initiate-Tag = 1234]
192.0.2.1:1 ----------------> 203.0.113.1:2 192.0.2.1:1 ----------------> 203.0.113.1:2
Ext-VTag = 0 Ext-VTag = 0
NAT B processes INIT, but cannot find an entry. The SCTP packet is NAT B processes INIT, but cannot find an entry. The SCTP packet is
silently discarded and leaves the NAT table of NAT B unchanged. silently discarded and leaves the NAT binding table of NAT B
unchanged.
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
NAT B | Int | Int | Ext | Ext | Priv | NAT B | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
Now Host B sends INIT, which is processed by NAT B. Its parameters Now Host B sends INIT, which is processed by NAT B. Its parameters
are used to create an entry. are used to create an entry.
Internal | External External | Internal Internal | External External | Internal
skipping to change at page 37, line 25 skipping to change at page 37, line 25
NAT A | Int | Int | Ext | Ext | Priv | NAT A | Int | Int | Ext | Ext | Priv |
| VTag | Port | VTag | Port | Addr | | VTag | Port | VTag | Port | Addr |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
| 1234 | 1 | 5678 | 2 | 10.0.0.1 | | 1234 | 1 | 5678 | 2 | 10.0.0.1 |
+---------+--------+----------+--------+-----------+ +---------+--------+----------+--------+-----------+
INIT[Initiate-tag = 5678] INIT[Initiate-tag = 5678]
10.0.0.1:1 <-- 203.0.113.1:2 10.0.0.1:1 <-- 203.0.113.1:2
Ext-VTag = 0 Ext-VTag = 0
Host A send INIT-ACK, which can pass through NAT B: Host A sends INIT-ACK, which can pass through NAT B:
Internal | External External | Internal Internal | External External | Internal
| | | |
| /--\/---\ | | /--\/---\ |
+--------+ +-------+ / \ +-------+ +--------+ +--------+ +-------+ / \ +-------+ +--------+
| Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B | | Host A |<--->| NAT A |<-->| Internet |<-->| NAT B |<--->| Host B |
+--------+ +-------+ \ / +-------+ +--------+ +--------+ +-------+ \ / +-------+ +--------+
| \--/\---/ | | \--/\---/ |
INIT-ACK[Initiate-Tag = 1234] INIT-ACK[Initiate-Tag = 1234]
skipping to change at page 43, line 38 skipping to change at page 43, line 38
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, Dynamic Address Reconfiguration", RFC 5061,
DOI 10.17487/RFC5061, September 2007, DOI 10.17487/RFC5061, September 2007,
<https://www.rfc-editor.org/info/rfc5061>. <https://www.rfc-editor.org/info/rfc5061>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. 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
address translation for SCTP", ACM SIGCOMM Computer address translation for SCTP", ACM SIGCOMM Computer
Communication Review Vol. 39, pp. 23, Communication Review Vol. 39, pp. 23,
DOI 10.1145/1496091.1496095, December 2008. DOI 10.1145/1496091.1496095, December 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
 End of changes. 52 change blocks. 
133 lines changed or deleted 151 lines changed or added

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