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

[Michael Tuexen <[e-mail]>]

> On 3. Apr 2020, at 18:42, [e-mail] wrote:
> 
> Hi Michael,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : tsvwg [mailto:[e-mail]] De la part de Michael
>> Tuexen
>> Envoyé : lundi 9 mars 2020 19:50
>> À : [e-mail]
>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>> 
>>> On 9. Mar 2020, at 19:34, [e-mail] 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
>>> 
>