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

From: <[email-masked]>
Date: Fri, 3 Apr 2020 16:42:41 +0000

Hi Michael,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tsvwg [mailto:[email-masked]] De la part de Michael
> Tuexen
> Envoyé : lundi 9 mars 2020 19:50
> À : [email-masked]
> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
> 
> > On 9. Mar 2020, at 19:34, [email-masked] 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
> >

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 7 Apr 2020 14:09:48 +0200

> On 3. Apr 2020, at 18:42, [email-masked] wrote:
> 
> Hi Michael,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
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?
> [Med] The external IP address is not necessary a public address;, see for example the NAT in the CPE* .
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

---

From: <[email-masked]>
Date: Tue, 7 Apr 2020 12:35:29 +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

> De : Michael Tuexen [mailto:[email-masked]]
> Envoyé : mardi 7 avril 2020 14:10
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]
> 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?
> >
> >
> > [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.
> >

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 7 Apr 2020 16:50:48 +0200

> On 7. Apr 2020, at 14:35, [email-masked] wrote:
> 
> Hi Michael,
> 
OK.
> "The NAT in the document refers to NAPT described in Section 2.2 of [RFC3022], NAT64 [RFC6146], or DS-Lite [RFC6333]."
OK.

Thanks for the quick feedback.

Best regards
Michael