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

From: [email-masked]
Date: Mon, 09 Mar 2020 11:34:29 -0700

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

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:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-16
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-natsupp-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 9 Mar 2020 19:50:02 +0100

> On 9. Mar 2020, at 19:34, [email-masked] wrote:
> 
> 
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
Michael