Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt

Michael Tuexen <> Mon, 09 March 2020 18:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCF2B3A0E6A for <>; Mon, 9 Mar 2020 11:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.614
X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WHkzV-DUkGgs for <>; Mon, 9 Mar 2020 11:50:22 -0700 (PDT)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22D333A0E6C for <>; Mon, 9 Mar 2020 11:50:06 -0700 (PDT)
Received: from [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931] (unknown [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931]) (Authenticated sender: lurchi) by (Postfix) with ESMTPSA id 0654D72106C26 for <>; Mon, 9 Mar 2020 19:50:02 +0100 (CET)
From: Michael Tuexen <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Mon, 9 Mar 2020 19:50:02 +0100
References: <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2020 18:50:25 -0000

> On 9. Mar 2020, at 19:34, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
>        Title           : Stream Control Transmission Protocol (SCTP) Network Address Translation Support
>        Authors         : Randall R. Stewart
>                          Michael Tuexen
>                          Irene Ruengeler
> 	Filename        : draft-ietf-tsvwg-natsupp-16.txt
> 	Pages           : 47
> 	Date            : 2020-03-09
Dear all,

this tries to
* address issues brought up by Maxim (see separate mail)
* add the YANG module provided by Mohamed
* address some of the issues reported bu Mohamed in a private mail
The .xml was also changed from v2 to v3.

The following suggestions from Mohamed were not integrated:
(a) replacing of NAT device to NAT function
    It is not clear to me what would be gained by this. Also other documents
    (for example RFC 4787) also use NAT device.
(b) replacing Private Address by Internal Address
    I would be fine with it (it would match Internal Port and Internal VTag).
    But it would break some relation we use for Private Address and Public
    Address (the non-private IP address assigned to the NAT device).
(c) replacing Public Address by External Address
    This would leave us with no name for the host on the External network
    the host behind the NAT wants to connect to and need to fit with
    Ext-Port and Ext-VTag.

I'm open to (a) if someone clarifies why NAT function is better than
NAT device and explains why it wasn't used that way in, for example,
RFC 4787.

I'm open to (b) and (c), I actually like (b), if someone can suggest
than also a better name for the address/port/vtag the NATted host
is connecting to. We currently use Ext-Addr, Ext-Port, and Ext-VTag
for it.

However, these three issues are editorial and can be changed during WGLC.

Best regards
> Abstract:
>   The Stream Control Transmission Protocol (SCTP) provides a reliable
>   communications channel between two end-hosts in many ways similar to
>   the Transmission Control Protocol (TCP).  With the widespread
>   deployment of Network Address Translators (NAT), specialized code has
>   been added to NAT for TCP that allows multiple hosts to reside behind
>   a NAT and yet share a single IPv4 address, even when two hosts
>   (behind a NAT) choose the same port numbers for their connection.
>   This additional code is sometimes classified as Network Address and
>   Port Translation (NAPT).
>   This document describes the protocol extensions required for the SCTP
>   endpoints and the mechanisms for NAT devices necessary to provide
>   similar features of NAPT in the single point and multi point
>   traversal scenario.
>   Finally, a YANG module for SCTP NAT is defined.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at: