linux-sctp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Xin Long <lucien.xin@gmail.com>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	"minyard@acm.org" <minyard@acm.org>,
	Vlad Yasevich <vyasevich@gmail.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Strange problem with SCTP+IPv6
Date: Fri, 26 Jun 2020 16:27:35 +0000	[thread overview]
Message-ID: <66D9D559-23D6-42B0-9401-62B00C4F748E@lurchi.franken.de> (raw)
In-Reply-To: <50b0a6ff186e408bbfe6211221cb3998@AcuMS.aculab.com>

> On 26. Jun 2020, at 18:13, David Laight <David.Laight@ACULAB.COM> wrote:
> 
> From: Xin Long
>> Sent: 23 June 2020 11:14
>>>> It looks like a bug to me. Testing with this test app here, I can see
>>>> the INIT_ACK being sent with a bunch of ipv4 addresses in it and
>>>> that's unexpected for a v6only socket. As is, it's the server saying
>>>> "I'm available at these other addresses too, but not."
>>> I agree.
>> Then we need a fix in sctp_bind_addrs_to_raw():
>> 
>> @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const
>> struct sctp_bind_addr *bp,
>>        addrparms = retval;
>> 
>>        list_for_each_entry(addr, &bp->address_list, list) {
>> +               if ((PF_INET6 = sk->sk_family) && inet_v6_ipv6only(sk) &&
>> +                   (AF_INET = addr->a.sa.sa_family))
>> +                       continue;
>>                af = sctp_get_af_specific(addr->a.v4.sin_family);
>>                len = af->to_addr_param(&addr->a, &rawaddr);
>>                memcpy(addrparms.v, &rawaddr, len);
> 
> Thought.
> 
> Does it make any sense to offer addresses in the INIT_ACK that don't
> have routes to those proposed in the received INIT?
> 
> 'routes' probably isn't exactly the right word.
> You probably only want the local address that will be used
> as the source address for the probes.
> Or, at least, sources addresses that could be used for the probes.
> 
> So if the INIT only contains IPv6 addresses should the INIT_ACK
> ever contain IPv4 ones.
The client (if it not using an IPv6 socket having IPv6 only enabled) could
add an IPv4 address during the lifetime of the association by using the
address reconfiguration extension.

What could be done is to not send IPv4 addresses if the INIT contains
a Supported Address Types parameter indicating IPv6, but not IPv4 support.
As a client you might want to send this parameter, when the IPv6 socket has
enabled the IPV6_ONLY socket option.
Also if the client uses an IPv4 socket, it can indicate in the Supported
Address Parameter that it only support IPv4, and the server does not need
to list IPv6 addresses.

Best regards
Michael
> 
> 	David.
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

  reply	other threads:[~2020-06-26 16:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-21 15:56 Strange problem with SCTP+IPv6 Corey Minyard
2020-06-22 11:52 ` Xin Long
2020-06-22 12:32   ` Michael Tuexen
2020-06-22 16:57   ` Corey Minyard
2020-06-22 18:01     ` Michael Tuexen
2020-06-22 18:32       ` Marcelo Ricardo Leitner
2020-06-22 18:34         ` Michael Tuexen
2020-06-23 10:13           ` Xin Long
2020-06-23 13:29             ` Corey Minyard
2020-06-23 15:40               ` Xin Long
2020-06-23 16:00                 ` Corey Minyard
2020-06-24  6:58                   ` Xin Long
2020-06-26 16:13             ` David Laight
2020-06-26 16:27               ` Michael Tuexen [this message]
2020-06-23 13:17         ` David Laight
2020-06-23 16:04           ` [PATCH] sctp: Don't advertise IPv4 addresses if ipv6only is set on the socket minyard
2020-06-24 20:31             ` Marcelo Ricardo Leitner
2020-06-24 20:34             ` [PATCH net] " Marcelo Ricardo Leitner
2020-06-24 20:53               ` Corey Minyard
2020-06-25 23:12               ` David Miller
2020-06-23 16:17           ` Strange problem with SCTP+IPv6 Corey Minyard
2020-06-23 21:21             ` 'Marcelo Ricardo Leitner'
2020-06-23 21:24               ` Michael Tuexen
2020-06-23 21:31                 ` Marcelo Ricardo Leitner
2020-06-23 21:48                   ` Michael Tuexen
2020-06-24  7:25                     ` Xin Long
2020-06-24  9:18                       ` Michael Tuexen
2020-06-23 17:09           ` Michael Tuexen

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=66D9D559-23D6-42B0-9401-62B00C4F748E@lurchi.franken.de \
    --to=michael.tuexen@lurchi.franken.de \
    --cc=David.Laight@ACULAB.COM \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=minyard@acm.org \
    --cc=nhorman@tuxdriver.com \
    --cc=vyasevich@gmail.com \
    /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).