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.
David.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
