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 > >>> > >
- [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.t… internet-drafts
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Michael Tuexen
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… mohamed.boucadair
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Michael Tuexen
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… mohamed.boucadair
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Michael Tuexen
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Michael Tuexen
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… mohamed.boucadair
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Michael Tuexen
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… mohamed.boucadair
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Gorry Fairhurst
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Michael Tuexen
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… mohamed.boucadair
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-… Michael Tuexen