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