From: Of Xin Long
> Sent: 25 August 2016 05:04
...
> But I still prefer the current patch.
> 1. This issue only happens when server bind 'ANY' addresses.
> we don't need to add any new members to struct sctp_sockaddr_entry.
> especially if it's a really corner issue, we fix this as an improvement.
>
> 2. It's yet two issues here, the duplicate addrs may be from
> a) different local NICs.
> b) the same one NIC.
> It may be unexpectable to filter them in NETDEV_UP/DOWN events.
>
> 3. We check it only when sctp really binds it, just like sctp_do_bind.
>
> What do you think ?
I want to know what kind of weed the SCTP authors were smoking when they
decided it was appropriate to put all of a systems IP addresses in the
cookie and cookie-ack messages.
It would be nice to have the local addresses selected by the kernel on the
basis of the remote address - removing the necessity of the application
to know the current network topology (and IP addresses) in order to bind
to the correct local addresses before making an outward call.
This sort of requires that local addresses for a connection are more of a
property of the routing table than anything else.
Consider the following network:
----+---------------+----------------------+---------
| | |
x.x.1.1 x.x.1.2 y.y.1.2
10.1.1.1 10.1.1.2 10.1.1.2
| | |
----+---------------+ +---------
A connection from x.x.1.1 to x.x.1.2 needs to specify the 10.1.1.* addresses,
but a connection for x.x.1.1 to y.y.1.2 must not.
I'm not at sure whether it is possible to setup listener(s) on x.x.1.1
that can accept connections from both x.x.1.2 and y.y.1.2.
David
��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
