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

[[e-mail]]

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

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. 


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

[Med] The 

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