Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 13 July 2020 15:45 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 35ACC3A146E for <tsvwg@ietfa.amsl.com>; Mon, 13 Jul 2020 08:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 7trJpmbDQs8q for <tsvwg@ietfa.amsl.com>; Mon, 13 Jul 2020 08:45:48 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [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 ietfa.amsl.com (Postfix) with ESMTPS id 72DBC3A16B0 for <tsvwg@ietf.org>; Mon, 13 Jul 2020 08:44:15 -0700 (PDT)
Received: from [10.211.21.224] (unknown [194.95.11.175]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id CC659721BE032; Mon, 13 Jul 2020 17:44:11 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314902D1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Mon, 13 Jul 2020 17:44:10 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC1544B5-87B1-4A46-BEA7-00541206883A@lurchi.franken.de>
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> <787AE7BB302AE849A7480A190F8B9330314902D1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HO-cyx3QlE7FtQFUFEAlkFS5GLo>
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: Mon, 13 Jul 2020 15:45:51 -0000
> > Hi Michael, > > Your new "Basic network setup" is better. Thanks. OK, using it. > > 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]." Added. Best regards Michael > > 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