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

mohamed.boucadair@orange.com Fri, 03 April 2020 16:42 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA583A0402 for <tsvwg@ietfa.amsl.com>; Fri, 3 Apr 2020 09:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Apli9evgi3X for <tsvwg@ietfa.amsl.com>; Fri, 3 Apr 2020 09:42:45 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBB13A03FC for <tsvwg@ietf.org>; Fri, 3 Apr 2020 09:42:44 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 48v5MQ6xGSz5vmV; Fri, 3 Apr 2020 18:42:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585932163; bh=w/Tw7kcZjfOsWTXXjyf67xiWVpbzDSJprueV3tJw3H0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VFOKeN3F9u9FS2SvoZc8nyzuEklhShKc7ktlG/wxZ2eJUpDb2PjhCP9UlzFR/GfQc fWf2FrZZuQt6Uyj0Xown/zKjWiupfzu2A1GpkwTuu8S7Xy/S17dRxg0tdtvjgor6Wh j2EScdgac6ujaxT8CoxMfZ1qa7932Qy/sr+/CKj3hEdIAoPGdJo++NDaoQAF9BGa9C zCLrcLq7pl5XR4fcPVDUDQTtkn81sZuc1k9JkcCVdcNEEVviUJ6Hwt8rUv+ksRl5qS ZBXSx1pn9r2VS+3EObHHG9bfUfpR4Tv9D4wQWjQtOQD51mNlZDNab3kLAlnv6xBB/w N2dn3bsjryUFA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 48v5MQ663sz2xCR; Fri, 3 Apr 2020 18:42:42 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
Thread-Index: AQHV9kOhWJF65mzuIkS6xfuPZJuHI6hnvZfg
Date: Fri, 3 Apr 2020 16:42:41 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93303148DE10@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <158377886936.5575.9623052267692928298@ietfa.amsl.com> <4C917C1B-74C0-4E5E-B26C-3CD6A0B2544C@lurchi.franken.de>
In-Reply-To: <4C917C1B-74C0-4E5E-B26C-3CD6A0B2544C@lurchi.franken.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jNOtMSJ7NUb82Rlp8MC8e9w2zK0>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 16:42:46 -0000

Hi Michael,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Michael
> Tuexen
> Envoyé : lundi 9 mars 2020 19:50
> À : tsvwg@ietf.org
> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
> 
> > On 9. Mar 2020, at 19:34, internet-drafts@ietf.org 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.

[Med] The is basically to align with recent RFCs in this area, e.g., 

RFC6888 defines CGN as follows: 

   Carrier-Grade NAT (CGN):  A NAT-based [RFC2663] logical function used
      to share the same IPv4 address among several subscribers.  A CGN
      is not managed by the subscribers.

The NAT is a function that is embedded in a device :-)

BTW a generic comment: the NAT document should not be specific to NAT44, but should cover a variety of NAT flavors that are out there: NAT64, DS-Lite, etc. 


> (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).

[Med] Private address has a specific a meaning. For example, the draft applies in the context of NAT64 as well, but there is no private IPv4 address in the internal side of the NAT. The terminology should be carefully chosen, IMO. 

> (c) replacing Public Address by External Address
>     This would leave us with no name for the host on the External
> network

[Med] The external IP address is not necessary a public address;, see for example the NAT in the CPE* .


                                   :
                                   |       Internet
                   ............... | ...................
                                   |       ISP network
                   External pool:  |
                   192.0.2.1/26    |
                               ++------++  External realm
                   ........... |  CGN   |...............
                               ++------++  Internal realm
                        10.0.0.1 |    |
                                 |    |
                                 |    |    ISP network
                   ............. | .. | ................
                                 |    |  Customer premises
                      10.0.0.100 |    | 10.0.0.101
                         ++------++  ++------++
                         |  CPE1  |  |  CPE2  |  etc.
                         ++------++  ++------++
                              |
                              H (192.168.0.1)

>     the host behind the NAT wants to connect to and need to fit with
>     Ext-Port and Ext-VTag.
> 

[Med] The 

> 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
> >