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

mohamed.boucadair@orange.com Tue, 07 April 2020 12:35 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 E110C3A0407 for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 05:35:33 -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 J1Tzk88KiZNA for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 05:35:32 -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 1D3303A0820 for <tsvwg@ietf.org>; Tue, 7 Apr 2020 05:35:32 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 48xRhL2zmmzBs3n; Tue, 7 Apr 2020 14:35:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586262930; bh=lhbLnnRpAeXenCuShnpeODrpBJgodKFfLEo4ugGCzcM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FgIe24X9QpO7w8XPrc8ObUR5VmPsppQwgrLsM1zqumkk3HWE+8t/SRIgrCiFccTIW JFc6EqUst3GYsuPi51Ha9yjGmc+q1K1IitM1uPsV1+kv2FePTAtHk3EVdGhfWx4Wv8 tWFLBGXghJkSYnvQiKYw9UE0cmIgE2mALZox2SVLj53KKQvMKNHlcLvckNVAt6r8Qq 3QPOer6tmmMZhv/XqbuD3/R3Gy+IKgcplSSrXHeL0QttlIimmBG7cdZoRZS05p6n+f VlC1vzqn5TR3PZu75LhQb1waUfy9L/huPyf8bTxkYnz784o1tRCHU5zkO76cytNy4g zn7NfvpdIqDbQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48xRhL243zzCql0; Tue, 7 Apr 2020 14:35:30 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
Thread-Index: AQHWDNVxzdv62Bebz0qcBDa2nniDsKhtlWEQ
Date: Tue, 07 Apr 2020 12:35:29 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330314902D1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <158377886936.5575.9623052267692928298@ietfa.amsl.com> <4C917C1B-74C0-4E5E-B26C-3CD6A0B2544C@lurchi.franken.de> <787AE7BB302AE849A7480A190F8B93303148DE10@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F3B1520B-593F-426A-8AC4-9B2371A82B37@lurchi.franken.de>
In-Reply-To: <F3B1520B-593F-426A-8AC4-9B2371A82B37@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.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/eOsR_zHtNOZZzHt3yL8nTtgpMfg>
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: Tue, 07 Apr 2020 12:35:34 -0000

Hi Michael,

Your new "Basic network setup" is better. Thanks.

I would add a note saying the following:

"The NAT in the document refers to NAPT described in Section 2.2 of [RFC3022], NAT64 [RFC6146], or DS-Lite [RFC6333]."

Cheers,
Med

> -----Message d'origine-----
> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> Envoyé : mardi 7 avril 2020 14:10
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : tsvwg@ietf.org
> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
> 
> > On 3. Apr 2020, at 18:42, mohamed.boucadair@orange.com wrote:
> >
> > 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 :-)
> I was looking at
> * https://tools.ietf.org/html/rfc2663
> * https://tools.ietf.org/html/rfc4787
> for example, which use NAT device.
> 
> Other documents just use NAT (in the sense of Network Address
> Translator). I'll bring that up at the interim.
> >
> > 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.
> Concrete suggestions?
> >
> >
> >> (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.
> >>
> What about using
> 
>   Internal Network    |         External Network
>                       |
>            Internal   |   External             Remote
> +--------+ Address    |   Address  /--\/--\    Address +--------+
> |  SCTP  |         +-----+        /        \           |  SCTP  |
> |endpoint|=========| NAT |=======| Internet |==========|endpoint|
> |    A   |         +-----+        \        /           |    B   |
> +--------+ Internal   |            \--/\--/      Remote+--------+
>  Internal     Port    |                            Port    Remote
>    VTag               |                                      VTag
> 
> instead of
> 
>   Internal Network    |         External Network
>                       |
>            Private    |   Public               External
> +--------+ Address    |   Address  /--\/--\    Address +--------+
> |  SCTP  |         +-----+        /        \           |  SCTP  |
> |endpoint|=========| NAT |=======| Internet |==========|endpoint|
> |    A   |         +-----+        \        /           |    B   |
> +--------+ Internal   |            \--/\--/    External+--------+
>  Internal     Port    |                            Port  External
>    VTag               |                                      VTag
> 
> That should address your comment and still provides a clear naming.
> >
> > [Med] The
> ???
> 
> Best regards
> Michael
> >
> >> 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
> >>>
> >