From: Xin Long <lucien.xin@gmail.com> Date: 2018-03-05 12:44:29
This patchset is to add support for 3 msg_control options described
in RFC6458:
5.3.7. SCTP PR-SCTP Information Structure (SCTP_PRINFO)
5.3.9. SCTP Destination IPv4 Address Structure (SCTP_DSTADDRV4)
5.3.10. SCTP Destination IPv6 Address Structure (SCTP_DSTADDRV6)
one send flag described in RFC6458:
SCTP_SENDALL: This flag, if set, will cause a one-to-many
style socket to send the message to all associations that
are currently established on this socket. For the one-to-
one style socket, this flag has no effect.
Note there is another msg_control option:
5.3.8. SCTP AUTH Information Structure (SCTP_AUTHINFO)
It's a little complicated, I will post it in another patchset after
this.
Xin Long (3):
sctp: add support for PR-SCTP Information for sendmsg
sctp: add support for SCTP_DSTADDRV4/6 Information for sendmsg
sctp: add support for snd flag SCTP_SENDALL process in sendmsg
include/net/sctp/structs.h | 2 +
include/uapi/linux/sctp.h | 23 ++++++++
net/sctp/socket.c | 143 +++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 163 insertions(+), 5 deletions(-)
--
2.1.0
From: Xin Long <lucien.xin@gmail.com> Date: 2018-03-05 12:44:37
This patch is to add support for PR-SCTP Information for sendmsg,
as described in section 5.3.7 of RFC6458.
With this option, you can specify pr_policy and pr_value for user
data in sendmsg.
It's also a necessary send info for sctp_sendv.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/structs.h | 1 +
include/uapi/linux/sctp.h | 15 +++++++++++++++
net/sctp/socket.c | 31 ++++++++++++++++++++++++++++++-
3 files changed, 46 insertions(+), 1 deletion(-)
From: Xin Long <lucien.xin@gmail.com> Date: 2018-03-05 12:44:45
This patch is to add support for Destination IPv4/6 Address options
for sendmsg, as described in section 5.3.9/10 of RFC6458.
With this option, you can provide more than one destination addrs
to sendmsg when creating asoc, like sctp_connectx.
It's also a necessary send info for sctp_sendv.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/structs.h | 1 +
include/uapi/linux/sctp.h | 6 ++++
net/sctp/socket.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 84 insertions(+)
From: Xin Long <lucien.xin@gmail.com> Date: 2018-03-05 12:44:54
This patch is to add support for snd flag SCTP_SENDALL process
in sendmsg, as described in section 5.3.4 of RFC6458.
With this flag, you can send the same data to all the asocs of
this sk once.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/uapi/linux/sctp.h | 2 ++
net/sctp/socket.c | 35 +++++++++++++++++++++++++++++++----
2 files changed, 33 insertions(+), 4 deletions(-)
@@ -284,6 +284,8 @@ enum sctp_sinfo_flags {SCTP_ADDR_OVER=(1<<1),/* Override the primary destination. */SCTP_ABORT=(1<<2),/* Send an ABORT message to the peer. */SCTP_SACK_IMMEDIATELY=(1<<3),/* SACK should be sent without delay. */+/* 2 bits here have been used by SCTP_PR_SCTP_MASK */+SCTP_SENDALL=(1<<6),SCTP_NOTIFICATION=MSG_NOTIFICATION,/* Next message is not user msg but notification. */SCTP_EOF=MSG_FIN,/* Initiate graceful shutdown process. */};
@@ -1820,6 +1820,10 @@ static int sctp_sendmsg_check_sflags(struct sctp_association *asoc,if(sctp_state(asoc,CLOSED)&&sctp_style(sk,TCP))return-EPIPE;+if((sflags&SCTP_SENDALL)&&sctp_style(sk,UDP)&&+!sctp_state(asoc,ESTABLISHED))+return0;+if(sflags&SCTP_EOF){pr_debug("%s: shutting down association:%p\n",__func__,asoc);sctp_primitive_SHUTDOWN(net,asoc,NULL);
@@ -2007,6 +2011,29 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)lock_sock(sk);+/* SCTP_SENDALL process */+if((sflags&SCTP_SENDALL)&&sctp_style(sk,UDP)){+list_for_each_entry(asoc,&ep->asocs,asocs){+err=sctp_sendmsg_check_sflags(asoc,sflags,msg,+msg_len);+if(err==0)+continue;+if(err<0)+gotoout_unlock;++sctp_sendmsg_update_sinfo(asoc,sinfo,&cmsgs);++err=sctp_sendmsg_to_asoc(asoc,msg,msg_len,+NULL,sinfo);+if(err<0)+gotoout_unlock;++iov_iter_revert(&msg->msg_iter,err);+}++gotoout_unlock;+}+/* Get and check or create asoc */if(daddr){asoc=sctp_endpoint_lookup_assoc(ep,daddr,&transport);
On Mon, Mar 05, 2018 at 08:44:19PM +0800, Xin Long wrote:
quoted hunk
This patch is to add support for Destination IPv4/6 Address options
for sendmsg, as described in section 5.3.9/10 of RFC6458.
With this option, you can provide more than one destination addrs
to sendmsg when creating asoc, like sctp_connectx.
It's also a necessary send info for sctp_sendv.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/structs.h | 1 +
include/uapi/linux/sctp.h | 6 ++++
net/sctp/socket.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 84 insertions(+)
@@ -1741,6 +1742,67 @@ static int sctp_sendmsg_new_asoc(struct sock *sk, __u16 sflags,gotofree;}+if(!cmsgs->addrs_msg)+return0;++/* sendv addr list parse */+for_each_cmsghdr(cmsg,cmsgs->addrs_msg){+structsctp_transport*transport;+structsctp_association*old;+unionsctp_addr_daddr;+intdlen;++if(cmsg->cmsg_level!=IPPROTO_SCTP||+(cmsg->cmsg_type!=SCTP_DSTADDRV4&&+cmsg->cmsg_type!=SCTP_DSTADDRV6))+continue;++daddr=&_daddr;+memset(daddr,0,sizeof(*daddr));+dlen=cmsg->cmsg_len-sizeof(structcmsghdr);+if(cmsg->cmsg_type==SCTP_DSTADDRV4){+if(dlen<sizeof(structin_addr))+gotofree;++dlen=sizeof(structin_addr);+daddr->v4.sin_family=AF_INET;+daddr->v4.sin_port=htons(asoc->peer.port);+memcpy(&daddr->v4.sin_addr,CMSG_DATA(cmsg),dlen);+}else{+if(dlen<sizeof(structin6_addr))+gotofree;++dlen=sizeof(structin6_addr);+daddr->v6.sin6_family=AF_INET6;+daddr->v6.sin6_port=htons(asoc->peer.port);+memcpy(&daddr->v6.sin6_addr,CMSG_DATA(cmsg),dlen);+}+err=sctp_verify_addr(sk,daddr,sizeof(*daddr));+if(err)+gotofree;++old=sctp_endpoint_lookup_assoc(ep,daddr,&transport);+if(old&&old!=asoc){+if(old->state>=SCTP_STATE_ESTABLISHED)+err=-EISCONN;+else+err=-EALREADY;+gotofree;+}++if(sctp_endpoint_is_peeled_off(ep,daddr)){+err=-EADDRNOTAVAIL;+gotofree;+}++transport=sctp_assoc_add_peer(asoc,daddr,GFP_KERNEL,+SCTP_UNKNOWN);+if(!transport){+err=-ENOMEM;+gotofree;+}+}+return0;free:
@@ -7778,6 +7840,21 @@ static int sctp_msghdr_parse(const struct msghdr *msg, struct sctp_cmsgs *cmsgs)if(cmsgs->prinfo->pr_policy==SCTP_PR_SCTP_NONE)cmsgs->prinfo->pr_value=0;break;+caseSCTP_DSTADDRV4:+caseSCTP_DSTADDRV6:+/* SCTP Socket API Extension+*5.3.9/10SCTPDestinationIPv4/6AddressStructure(SCTP_DSTADDRV4/6)+*+*ThiscmsghdrstructurespecifiesSCTPoptionsforsendmsg().+*+*cmsg_levelcmsg_typecmsg_data[]+*---------------------------------------------+*IPPROTO_SCTPSCTP_DSTADDRV4structin_addr+*---------------------------------------------+*IPPROTO_SCTPSCTP_DSTADDRV6structin6_addr+*/+cmsgs->addrs_msg=my_msg;
I think this is being handled differently from what the RFC specifies.
AFAIU the rfc defines these two options being each one an array of a
specific element type, in_addr and in6_addr.
The patch is saving both options into a single pointer, which later is
processed as a list of (in_addr or in6_addr) elements.
If an application specifies both options, each with a list of its own
addresses, it will ignore one of the options.
On Mon, Mar 05, 2018 at 08:44:17PM +0800, Xin Long wrote:
This patchset is to add support for 3 msg_control options described
in RFC6458:
5.3.7. SCTP PR-SCTP Information Structure (SCTP_PRINFO)
5.3.9. SCTP Destination IPv4 Address Structure (SCTP_DSTADDRV4)
5.3.10. SCTP Destination IPv6 Address Structure (SCTP_DSTADDRV6)
one send flag described in RFC6458:
SCTP_SENDALL: This flag, if set, will cause a one-to-many
style socket to send the message to all associations that
are currently established on this socket. For the one-to-
one style socket, this flag has no effect.
From: Xin Long <lucien.xin@gmail.com> Date: 2018-03-06 07:03:15
On Tue, Mar 6, 2018 at 7:39 AM, Marcelo Ricardo Leitner
[off-list ref] wrote:
On Mon, Mar 05, 2018 at 08:44:19PM +0800, Xin Long wrote:
quoted
This patch is to add support for Destination IPv4/6 Address options
for sendmsg, as described in section 5.3.9/10 of RFC6458.
With this option, you can provide more than one destination addrs
to sendmsg when creating asoc, like sctp_connectx.
It's also a necessary send info for sctp_sendv.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/structs.h | 1 +
include/uapi/linux/sctp.h | 6 ++++
net/sctp/socket.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 84 insertions(+)
@@ -1741,6 +1742,67 @@ static int sctp_sendmsg_new_asoc(struct sock *sk, __u16 sflags,gotofree;}+if(!cmsgs->addrs_msg)+return0;++/* sendv addr list parse */+for_each_cmsghdr(cmsg,cmsgs->addrs_msg){+structsctp_transport*transport;+structsctp_association*old;+unionsctp_addr_daddr;+intdlen;++if(cmsg->cmsg_level!=IPPROTO_SCTP||+(cmsg->cmsg_type!=SCTP_DSTADDRV4&&+cmsg->cmsg_type!=SCTP_DSTADDRV6))+continue;++daddr=&_daddr;+memset(daddr,0,sizeof(*daddr));+dlen=cmsg->cmsg_len-sizeof(structcmsghdr);+if(cmsg->cmsg_type==SCTP_DSTADDRV4){+if(dlen<sizeof(structin_addr))+gotofree;++dlen=sizeof(structin_addr);+daddr->v4.sin_family=AF_INET;+daddr->v4.sin_port=htons(asoc->peer.port);+memcpy(&daddr->v4.sin_addr,CMSG_DATA(cmsg),dlen);+}else{+if(dlen<sizeof(structin6_addr))+gotofree;++dlen=sizeof(structin6_addr);+daddr->v6.sin6_family=AF_INET6;+daddr->v6.sin6_port=htons(asoc->peer.port);+memcpy(&daddr->v6.sin6_addr,CMSG_DATA(cmsg),dlen);+}+err=sctp_verify_addr(sk,daddr,sizeof(*daddr));+if(err)+gotofree;++old=sctp_endpoint_lookup_assoc(ep,daddr,&transport);+if(old&&old!=asoc){+if(old->state>=SCTP_STATE_ESTABLISHED)+err=-EISCONN;+else+err=-EALREADY;+gotofree;+}++if(sctp_endpoint_is_peeled_off(ep,daddr)){+err=-EADDRNOTAVAIL;+gotofree;+}++transport=sctp_assoc_add_peer(asoc,daddr,GFP_KERNEL,+SCTP_UNKNOWN);+if(!transport){+err=-ENOMEM;+gotofree;+}+}+return0;free:
@@ -7778,6 +7840,21 @@ static int sctp_msghdr_parse(const struct msghdr *msg, struct sctp_cmsgs *cmsgs)if(cmsgs->prinfo->pr_policy==SCTP_PR_SCTP_NONE)cmsgs->prinfo->pr_value=0;break;+caseSCTP_DSTADDRV4:+caseSCTP_DSTADDRV6:+/* SCTP Socket API Extension+*5.3.9/10SCTPDestinationIPv4/6AddressStructure(SCTP_DSTADDRV4/6)+*+*ThiscmsghdrstructurespecifiesSCTPoptionsforsendmsg().+*+*cmsg_levelcmsg_typecmsg_data[]+*---------------------------------------------+*IPPROTO_SCTPSCTP_DSTADDRV4structin_addr+*---------------------------------------------+*IPPROTO_SCTPSCTP_DSTADDRV6structin6_addr+*/+cmsgs->addrs_msg=my_msg;
I think this is being handled differently from what the RFC specifies.
AFAIU the rfc defines these two options being each one an array of a
specific element type, in_addr and in6_addr.
Hi, Marcelo.
From section 5.3.9 of RFC6458:
This ancillary data can be used to provide more than one destination
address to sendmsg(). It can be used to implement sctp_sendv() using
sendmsg().
It doesn't say to put "more than one destination address" into an array of
one option, or put "more than one destination address" into many options.
I was also confused, then I checked sctp_process_cmsgs_for_init() in
freebsd, I think it's in MANY options.
The patch is saving both options into a single pointer, which later is
processed as a list of (in_addr or in6_addr) elements.
It's not, 'my_msg' is the whole msghdr, not only in_addr or in6_addr.
later in sctp_sendmsg_new_asoc, it will parse this msghdr again but
this time only to pick up SCTP_DSTADDRV4/6 options.
(by this way I don't need to alloc list or array to save them)
Note that: one option is just one address, NOT a list of addresses.
like, it can even be:
SCTP_DSTADDRV4 (one option)
SCTP_DSTADDRV6 (one option)
SCTP_DSTADDRV4 (one option)
SCTP_DSTADDRV4 (one option)
SCTP_DSTADDRV6 (one option)
Maybe the name of cmsgs->addrs_msg is confusing here, but I
actually think it as a flag to see if there is addrs info in the msghdr,
and also as a parameter to pass the msghdr into sctp_sendmsg_new_asoc.
If an application specifies both options, each with a list of its own
addresses, it will ignore one of the options.
If an application specifies many options, some are SCTP_DSTADDRV4
and some are SCTP_DSTADDRV6, none of them will be ignored in
sctp_sendmsg_new_asoc().
On Tue, Mar 06, 2018 at 03:03:13PM +0800, Xin Long wrote:
On Tue, Mar 6, 2018 at 7:39 AM, Marcelo Ricardo Leitner
[off-list ref] wrote:
quoted
On Mon, Mar 05, 2018 at 08:44:19PM +0800, Xin Long wrote:
quoted
This patch is to add support for Destination IPv4/6 Address options
for sendmsg, as described in section 5.3.9/10 of RFC6458.
With this option, you can provide more than one destination addrs
to sendmsg when creating asoc, like sctp_connectx.
It's also a necessary send info for sctp_sendv.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/structs.h | 1 +
include/uapi/linux/sctp.h | 6 ++++
net/sctp/socket.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 84 insertions(+)
@@ -1741,6 +1742,67 @@ static int sctp_sendmsg_new_asoc(struct sock *sk, __u16 sflags,gotofree;}+if(!cmsgs->addrs_msg)+return0;++/* sendv addr list parse */+for_each_cmsghdr(cmsg,cmsgs->addrs_msg){+structsctp_transport*transport;+structsctp_association*old;+unionsctp_addr_daddr;+intdlen;++if(cmsg->cmsg_level!=IPPROTO_SCTP||+(cmsg->cmsg_type!=SCTP_DSTADDRV4&&+cmsg->cmsg_type!=SCTP_DSTADDRV6))+continue;++daddr=&_daddr;+memset(daddr,0,sizeof(*daddr));+dlen=cmsg->cmsg_len-sizeof(structcmsghdr);+if(cmsg->cmsg_type==SCTP_DSTADDRV4){+if(dlen<sizeof(structin_addr))+gotofree;++dlen=sizeof(structin_addr);+daddr->v4.sin_family=AF_INET;+daddr->v4.sin_port=htons(asoc->peer.port);+memcpy(&daddr->v4.sin_addr,CMSG_DATA(cmsg),dlen);+}else{+if(dlen<sizeof(structin6_addr))+gotofree;++dlen=sizeof(structin6_addr);+daddr->v6.sin6_family=AF_INET6;+daddr->v6.sin6_port=htons(asoc->peer.port);+memcpy(&daddr->v6.sin6_addr,CMSG_DATA(cmsg),dlen);+}+err=sctp_verify_addr(sk,daddr,sizeof(*daddr));+if(err)+gotofree;++old=sctp_endpoint_lookup_assoc(ep,daddr,&transport);+if(old&&old!=asoc){+if(old->state>=SCTP_STATE_ESTABLISHED)+err=-EISCONN;+else+err=-EALREADY;+gotofree;+}++if(sctp_endpoint_is_peeled_off(ep,daddr)){+err=-EADDRNOTAVAIL;+gotofree;+}++transport=sctp_assoc_add_peer(asoc,daddr,GFP_KERNEL,+SCTP_UNKNOWN);+if(!transport){+err=-ENOMEM;+gotofree;+}+}+return0;free:
@@ -7778,6 +7840,21 @@ static int sctp_msghdr_parse(const struct msghdr *msg, struct sctp_cmsgs *cmsgs)if(cmsgs->prinfo->pr_policy==SCTP_PR_SCTP_NONE)cmsgs->prinfo->pr_value=0;break;+caseSCTP_DSTADDRV4:+caseSCTP_DSTADDRV6:+/* SCTP Socket API Extension+*5.3.9/10SCTPDestinationIPv4/6AddressStructure(SCTP_DSTADDRV4/6)+*+*ThiscmsghdrstructurespecifiesSCTPoptionsforsendmsg().+*+*cmsg_levelcmsg_typecmsg_data[]+*---------------------------------------------+*IPPROTO_SCTPSCTP_DSTADDRV4structin_addr+*---------------------------------------------+*IPPROTO_SCTPSCTP_DSTADDRV6structin6_addr+*/+cmsgs->addrs_msg=my_msg;
I think this is being handled differently from what the RFC specifies.
AFAIU the rfc defines these two options being each one an array of a
specific element type, in_addr and in6_addr.
Hi, Marcelo.
From section 5.3.9 of RFC6458:
This ancillary data can be used to provide more than one destination
address to sendmsg(). It can be used to implement sctp_sendv() using
sendmsg().
It doesn't say to put "more than one destination address" into an array of
one option, or put "more than one destination address" into many options.
Spot on. And I went with the first interpretation, thus why the
difference.
I was also confused, then I checked sctp_process_cmsgs_for_init() in
freebsd, I think it's in MANY options.
Nice, ok
quoted
The patch is saving both options into a single pointer, which later is
processed as a list of (in_addr or in6_addr) elements.
It's not, 'my_msg' is the whole msghdr, not only in_addr or in6_addr.
later in sctp_sendmsg_new_asoc, it will parse this msghdr again but
this time only to pick up SCTP_DSTADDRV4/6 options.
(by this way I don't need to alloc list or array to save them)
Which is nice, btw.
Note that: one option is just one address, NOT a list of addresses.
like, it can even be:
SCTP_DSTADDRV4 (one option)
SCTP_DSTADDRV6 (one option)
SCTP_DSTADDRV4 (one option)
SCTP_DSTADDRV4 (one option)
SCTP_DSTADDRV6 (one option)
Maybe the name of cmsgs->addrs_msg is confusing here, but I
actually think it as a flag to see if there is addrs info in the msghdr,
and also as a parameter to pass the msghdr into sctp_sendmsg_new_asoc.
What was more confusing to me is that it seems to overwrite the
pointer at every other addr option, but I should have noticed that it
is saving the entire cmsg.
quoted
If an application specifies both options, each with a list of its own
addresses, it will ignore one of the options.
If an application specifies many options, some are SCTP_DSTADDRV4
and some are SCTP_DSTADDRV6, none of them will be ignored in
sctp_sendmsg_new_asoc().
On Mon, Mar 05, 2018 at 08:44:18PM +0800, Xin Long wrote:
This patch is to add support for PR-SCTP Information for sendmsg,
as described in section 5.3.7 of RFC6458.
With this option, you can specify pr_policy and pr_value for user
data in sendmsg.
It's also a necessary send info for sctp_sendv.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
On Mon, Mar 05, 2018 at 08:44:19PM +0800, Xin Long wrote:
This patch is to add support for Destination IPv4/6 Address options
for sendmsg, as described in section 5.3.9/10 of RFC6458.
With this option, you can provide more than one destination addrs
to sendmsg when creating asoc, like sctp_connectx.
It's also a necessary send info for sctp_sendv.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
On Mon, Mar 05, 2018 at 08:44:20PM +0800, Xin Long wrote:
This patch is to add support for snd flag SCTP_SENDALL process
in sendmsg, as described in section 5.3.4 of RFC6458.
With this flag, you can send the same data to all the asocs of
this sk once.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
@@ -284,6 +284,8 @@ enum sctp_sinfo_flags {SCTP_ADDR_OVER=(1<<1),/* Override the primary destination. */SCTP_ABORT=(1<<2),/* Send an ABORT message to the peer. */SCTP_SACK_IMMEDIATELY=(1<<3),/* SACK should be sent without delay. */+/* 2 bits here have been used by SCTP_PR_SCTP_MASK */+SCTP_SENDALL=(1<<6),SCTP_NOTIFICATION=MSG_NOTIFICATION,/* Next message is not user msg but notification. */SCTP_EOF=MSG_FIN,/* Initiate graceful shutdown process. */};
@@ -1820,6 +1820,10 @@ static int sctp_sendmsg_check_sflags(struct sctp_association *asoc,if(sctp_state(asoc,CLOSED)&&sctp_style(sk,TCP))return-EPIPE;+if((sflags&SCTP_SENDALL)&&sctp_style(sk,UDP)&&+!sctp_state(asoc,ESTABLISHED))+return0;+if(sflags&SCTP_EOF){pr_debug("%s: shutting down association:%p\n",__func__,asoc);sctp_primitive_SHUTDOWN(net,asoc,NULL);
@@ -2007,6 +2011,29 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)lock_sock(sk);+/* SCTP_SENDALL process */+if((sflags&SCTP_SENDALL)&&sctp_style(sk,UDP)){+list_for_each_entry(asoc,&ep->asocs,asocs){+err=sctp_sendmsg_check_sflags(asoc,sflags,msg,+msg_len);+if(err==0)+continue;+if(err<0)+gotoout_unlock;++sctp_sendmsg_update_sinfo(asoc,sinfo,&cmsgs);++err=sctp_sendmsg_to_asoc(asoc,msg,msg_len,+NULL,sinfo);+if(err<0)+gotoout_unlock;++iov_iter_revert(&msg->msg_iter,err);+}++gotoout_unlock;+}+/* Get and check or create asoc */if(daddr){asoc=sctp_endpoint_lookup_assoc(ep,daddr,&transport);
From: David Miller <davem@davemloft.net> Date: 2018-03-07 15:57:18
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 5 Mar 2018 20:44:17 +0800
This patchset is to add support for 3 msg_control options described
in RFC6458:
5.3.7. SCTP PR-SCTP Information Structure (SCTP_PRINFO)
5.3.9. SCTP Destination IPv4 Address Structure (SCTP_DSTADDRV4)
5.3.10. SCTP Destination IPv6 Address Structure (SCTP_DSTADDRV6)
one send flag described in RFC6458:
SCTP_SENDALL: This flag, if set, will cause a one-to-many
style socket to send the message to all associations that
are currently established on this socket. For the one-to-
one style socket, this flag has no effect.
Note there is another msg_control option:
5.3.8. SCTP AUTH Information Structure (SCTP_AUTHINFO)
It's a little complicated, I will post it in another patchset after
this.