Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line Internet-Drafts directories

> On 27. Aug 2021, at 17:24, Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi,
> I've just submitted this draft.
> Please review it for discussing at the next Transport Area Working Group (tsvwg) WG Virtual Meeting:
> 2021-09-03
Hi Claudio,

thank you very much for writing your suggested way of doing NAT for SCTP up.

Sorry for being late, but I have some high level comments, which you might
be able to address in your presentation on Friday. It would at least help
me to get a better understanding of your proposal.

* According to Section 4.3, all outgoing packets can establish a new state at
  the NAT function. So why do you need the INIT/INIT ACK exchange before the
  corresponding ASCONF/ASCONF ACK exchange?

* Section 4.4 states that
  "The main difference is in the NAT to be stateless rather than following
  the status of the association."
  I don't see how the solution described in draft-ietf-tsvwg-natsupp stores
  the state of the association. Could you elaborate on that?

* Section 5.3.1 introduces the Repetitiva Juvant parameter in the INIT chunk.
  Why is it needed since the NAT functions does not care about verification tags?
  Isn't this only required for handling incoming SCTP associations? Isn't this
  a way of load balancing? Isn't this a different problem than NAT? How can
  the Repetitiva Juvant parameter be considered if the packets are not parsed?

* Section 7.2 describes an example with congestion. Why do you use a different
  connection setup in case of congestion? How do you know that there is congestion?
  Or is this an example of a local port number collision and not about congestion?

* How does in Section 7.3 NAT know, that it needs to forward the incoming packet
  containing the INIT chunk to B1 and not B2?

Best regards
Michael

> 
> Thanks and best regards,
> Claudio Porfiri
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Stream Control Transmission Protocol (SCTP) Network Address Translation
> Support
>        Author          : Claudio Porfiri
> 	Filename        : draft-porfiri-tsvwg-sctp-natsupp-00.txt
> 	Pages           : 34
> 	Date            : 2021-08-27
> 
> Abstract:
>   The Stream Control Transmission Protocol (SCTP) provides a reliable
>   communications channel between two end-hosts in many ways similar to
>   the Transmission Control Protocol (TCP).  With the widespread
>   deployment of Network Address Translators (NAT), specialized code has
>   been added to NAT functions for TCP that allows multiple hosts to
>   reside behind a NAT function and yet share a single IPv4 address,
>   even when two hosts (behind a NAT function) choose the same port
>   numbers for their connection.  This additional code is sometimes
>   classified as Network Address and Port Translation (NAPT).
> 
>   This document describes the protocol extensions needed for the SCTP
>   endpoints and the mechanisms for NAT functions necessary to provide
>   similar features of NAPT in the single point and multipoint traversal
>   scenario.
> 
>   Finally, a YANG module for SCTP NAT is defined.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-porfiri-tsvwg-sctp-natsupp/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-porfiri-tsvwg-sctp-natsupp-00.html
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 