From: Xin Long <lucien.xin@gmail.com>
To: Michael Tuexen <tuexen@fh-muenster.de>
Cc: network dev <netdev@vger.kernel.org>,
linux-sctp@vger.kernel.org,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Neil Horman <nhorman@tuxdriver.com>,
Tom Herbert <therbert@google.com>, davem <davem@davemloft.net>
Subject: Re: [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation of SCTP
Date: Tue, 29 Sep 2020 17:49:45 +0000 [thread overview]
Message-ID: <CADvbK_eWR8yw-kV_cVg93caRpEVziCwN_V6gnB7TLM9xxKWpeg@mail.gmail.com> (raw)
In-Reply-To: <F02013B3-C485-4998-B68A-26118D8ACF9C@fh-muenster.de>
On Wed, Sep 30, 2020 at 12:40 AM Michael Tuexen <tuexen@fh-muenster.de> wrote:
>
> > On 29. Sep 2020, at 15:48, Xin Long <lucien.xin@gmail.com> wrote:
> >
> > Description From the RFC:
> >
> > The Main Reasons:
> >
> > o To allow SCTP traffic to pass through legacy NATs, which do not
> > provide native SCTP support as specified in [BEHAVE] and
> > [NATSUPP].
> >
> > o To allow SCTP to be implemented on hosts that do not provide
> > direct access to the IP layer. In particular, applications can
> > use their own SCTP implementation if the operating system does not
> > provide one.
> >
> > Implementation Notes:
> >
> > UDP-encapsulated SCTP is normally communicated between SCTP stacks
> > using the IANA-assigned UDP port number 9899 (sctp-tunneling) on both
> > ends. There are circumstances where other ports may be used on
> > either end, and it might be required to use ports other than the
> > registered port.
> >
> > Each SCTP stack uses a single local UDP encapsulation port number as
> > the destination port for all its incoming SCTP packets, this greatly
> > simplifies implementation design.
> >
> > An SCTP implementation supporting UDP encapsulation MUST maintain a
> > remote UDP encapsulation port number per destination address for each
> > SCTP association. Again, because the remote stack may be using ports
> > other than the well-known port, each port may be different from each
> > stack. However, because of remapping of ports by NATs, the remote
> > ports associated with different remote IP addresses may not be
> > identical, even if they are associated with the same stack.
> >
> > Because the well-known port might not be used, implementations need
> > to allow other port numbers to be specified as a local or remote UDP
> > encapsulation port number through APIs.
> Hi Xin Long,
>
> I really appreciate that UDP encapsulation gets implemented in Linux.
>
> The FreeBSD implementation initially had a bug due to missing text in
> RFC6951. Please make sure the implementation also follows
> https://www.ietf.org/id/draft-tuexen-tsvwg-sctp-udp-encaps-cons-03.html
Hi, Michael
Thanks for sharing this doc.
3. Handling of Out of the Blue Packets:
This patchset can handle it well.
4. Handling of SCTP Packets Containing an INIT Chunk Matching an
Existing Associations:
These cases responding with ABORT, I will need to add.
>
> The plan is to revise RFC6951 and let RFC6951bis include the contents of
> the above Internet Draft. But this most likely will happen after the
> NAT document is ready and RFC4960bis finished...
understand.
>
> If you want to do some interop testing, a web server supporting SCTP/UDP
> is running at interop.fh-muenster.de. You can find a client (phttpget) at
> https://github.com/NEAT-project/HTTPOverSCTP.
got it.
WARNING: multiple messages have this Message-ID (diff)
From: Xin Long <lucien.xin@gmail.com>
To: Michael Tuexen <tuexen@fh-muenster.de>
Cc: network dev <netdev@vger.kernel.org>,
linux-sctp@vger.kernel.org,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Neil Horman <nhorman@tuxdriver.com>,
Tom Herbert <therbert@google.com>, davem <davem@davemloft.net>
Subject: Re: [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation of SCTP
Date: Wed, 30 Sep 2020 02:04:51 +0800 [thread overview]
Message-ID: <CADvbK_eWR8yw-kV_cVg93caRpEVziCwN_V6gnB7TLM9xxKWpeg@mail.gmail.com> (raw)
Message-ID: <20200929180451.Z1ZiiQO2eJi_gxd9IVb8M88M-ayt_ZH2uZkq73ABY4c@z> (raw)
In-Reply-To: <F02013B3-C485-4998-B68A-26118D8ACF9C@fh-muenster.de>
On Wed, Sep 30, 2020 at 12:40 AM Michael Tuexen <tuexen@fh-muenster.de> wrote:
>
> > On 29. Sep 2020, at 15:48, Xin Long <lucien.xin@gmail.com> wrote:
> >
> > Description From the RFC:
> >
> > The Main Reasons:
> >
> > o To allow SCTP traffic to pass through legacy NATs, which do not
> > provide native SCTP support as specified in [BEHAVE] and
> > [NATSUPP].
> >
> > o To allow SCTP to be implemented on hosts that do not provide
> > direct access to the IP layer. In particular, applications can
> > use their own SCTP implementation if the operating system does not
> > provide one.
> >
> > Implementation Notes:
> >
> > UDP-encapsulated SCTP is normally communicated between SCTP stacks
> > using the IANA-assigned UDP port number 9899 (sctp-tunneling) on both
> > ends. There are circumstances where other ports may be used on
> > either end, and it might be required to use ports other than the
> > registered port.
> >
> > Each SCTP stack uses a single local UDP encapsulation port number as
> > the destination port for all its incoming SCTP packets, this greatly
> > simplifies implementation design.
> >
> > An SCTP implementation supporting UDP encapsulation MUST maintain a
> > remote UDP encapsulation port number per destination address for each
> > SCTP association. Again, because the remote stack may be using ports
> > other than the well-known port, each port may be different from each
> > stack. However, because of remapping of ports by NATs, the remote
> > ports associated with different remote IP addresses may not be
> > identical, even if they are associated with the same stack.
> >
> > Because the well-known port might not be used, implementations need
> > to allow other port numbers to be specified as a local or remote UDP
> > encapsulation port number through APIs.
> Hi Xin Long,
>
> I really appreciate that UDP encapsulation gets implemented in Linux.
>
> The FreeBSD implementation initially had a bug due to missing text in
> RFC6951. Please make sure the implementation also follows
> https://www.ietf.org/id/draft-tuexen-tsvwg-sctp-udp-encaps-cons-03.html
Hi, Michael
Thanks for sharing this doc.
3. Handling of Out of the Blue Packets:
This patchset can handle it well.
4. Handling of SCTP Packets Containing an INIT Chunk Matching an
Existing Associations:
These cases responding with ABORT, I will need to add.
>
> The plan is to revise RFC6951 and let RFC6951bis include the contents of
> the above Internet Draft. But this most likely will happen after the
> NAT document is ready and RFC4960bis finished...
understand.
>
> If you want to do some interop testing, a web server supporting SCTP/UDP
> is running at interop.fh-muenster.de. You can find a client (phttpget) at
> https://github.com/NEAT-project/HTTPOverSCTP.
got it.
next prev parent reply other threads:[~2020-09-29 17:49 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 13:48 [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation of SCTP Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:48 ` [PATCH net-next 01/15] udp: check udp sock encap_type in __udp_lib_err Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:48 ` [PATCH net-next 02/15] udp6: move the mss check after udp gso tunnel processing Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:48 ` [PATCH net-next 03/15] udp: do checksum properly in skb_udp_tunnel_segment Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:48 ` [PATCH net-next 04/15] udp: support sctp over udp " Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:48 ` [PATCH net-next 05/15] sctp: create udp4 sock and add its encap_rcv Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:48 ` [PATCH net-next 06/15] sctp: create udp6 sock and set " Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:48 ` [PATCH net-next 07/15] sctp: add encap_err_lookup for udp encap socks Xin Long
2020-09-29 13:48 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 08/15] sctp: add encap_port for netns sock asoc and transport Xin Long
2020-09-29 13:49 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 09/15] sctp: add SCTP_REMOTE_UDP_ENCAPS_PORT sockopt Xin Long
2020-09-29 13:49 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 10/15] sctp: allow changing transport encap_port by peer packets Xin Long
2020-09-29 13:49 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 11/15] sctp: add udphdr to overhead when udp_port is set Xin Long
2020-09-29 13:49 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 12/15] sctp: call sk_setup_caps in sctp_packet_transmit instead Xin Long
2020-09-29 13:49 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 13/15] sctp: support for sending packet over udp4 sock Xin Long
2020-09-29 13:49 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 14/15] sctp: support for sending packet over udp6 sock Xin Long
2020-09-29 13:49 ` Xin Long
2020-09-29 13:49 ` [PATCH net-next 15/15] sctp: enable udp tunneling socks Xin Long
2020-09-29 13:49 ` Xin Long
2020-10-03 4:12 ` Marcelo Ricardo Leitner
2020-10-03 4:12 ` Marcelo Ricardo Leitner
2020-10-03 8:20 ` Xin Long
2020-10-03 8:20 ` Xin Long
2020-09-29 16:25 ` [PATCH net-next 13/15] sctp: support for sending packet over udp4 sock kernel test robot
2020-09-29 16:25 ` kernel test robot
2020-09-30 6:26 ` Xin Long
2020-09-30 6:26 ` Xin Long
2020-09-29 19:19 ` kernel test robot
2020-09-29 19:19 ` kernel test robot
2020-10-03 4:09 ` [PATCH net-next 12/15] sctp: call sk_setup_caps in sctp_packet_transmit instead Marcelo Ricardo Leitner
2020-10-03 4:09 ` Marcelo Ricardo Leitner
2020-10-03 7:45 ` Xin Long
2020-10-03 7:45 ` Xin Long
2020-09-29 19:00 ` [PATCH net-next 11/15] sctp: add udphdr to overhead when udp_port is set kernel test robot
2020-09-29 19:00 ` kernel test robot
2020-10-03 4:08 ` Marcelo Ricardo Leitner
2020-10-03 4:08 ` Marcelo Ricardo Leitner
2020-10-03 7:57 ` Xin Long
2020-10-03 8:12 ` Xin Long
2020-10-03 11:23 ` Xin Long
2020-10-03 11:23 ` Xin Long
2020-10-03 12:24 ` Xin Long
2020-10-03 12:24 ` Xin Long
2020-10-05 19:01 ` Marcelo Ricardo Leitner
2020-10-05 19:01 ` Marcelo Ricardo Leitner
2020-10-05 20:08 ` Michael Tuexen
2020-10-05 20:08 ` Michael Tuexen
2020-10-08 9:37 ` Xin Long
2020-10-08 9:37 ` Xin Long
2020-10-03 4:07 ` Marcelo Ricardo Leitner
2020-10-03 4:07 ` Marcelo Ricardo Leitner
2020-10-03 7:54 ` Xin Long
2020-10-03 7:54 ` Xin Long
2020-10-03 4:06 ` [PATCH net-next 10/15] sctp: allow changing transport encap_port by peer packets Marcelo Ricardo Leitner
2020-10-03 4:06 ` Marcelo Ricardo Leitner
2020-10-03 4:05 ` [PATCH net-next 09/15] sctp: add SCTP_REMOTE_UDP_ENCAPS_PORT sockopt Marcelo Ricardo Leitner
2020-10-03 4:05 ` Marcelo Ricardo Leitner
2020-10-03 7:41 ` Xin Long
2020-10-03 7:41 ` Xin Long
2020-10-03 4:04 ` [PATCH net-next 03/15] udp: do checksum properly in skb_udp_tunnel_segment Marcelo Ricardo Leitner
2020-10-03 4:04 ` Marcelo Ricardo Leitner
2020-10-03 7:40 ` Xin Long
2020-10-03 7:40 ` Xin Long
2020-09-29 16:39 ` [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation of SCTP Michael Tuexen
2020-09-29 16:39 ` Michael Tuexen
2020-09-29 17:49 ` Xin Long [this message]
2020-09-29 18:04 ` Xin Long
2020-10-01 12:41 ` Marcelo Ricardo Leitner
2020-10-01 12:41 ` Marcelo Ricardo Leitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADvbK_eWR8yw-kV_cVg93caRpEVziCwN_V6gnB7TLM9xxKWpeg@mail.gmail.com \
--to=lucien.xin@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=therbert@google.com \
--cc=tuexen@fh-muenster.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).