On Fri, Jun 18, 2021 at 4:35 PM Michael Tuexen <tuexen@xxxxxxxxxxx> wrote: > > > On 18. Jun 2021, at 18:35, Xin Long <lucien.xin@xxxxxxxxx> wrote: > > > > On Thu, Jun 17, 2021 at 4:40 PM Sérgio <surkamp@xxxxxxxxx> wrote: > >> > >> Hello, > >> > >> I am troubleshooting a deployment with SCTP and eventually found that > >> the client has configured the equipment using addresses within the > >> RFC2544 annex C.2.2 test network (198.18.0.0/15). > >> > >> Although I think the deployment network may be changed to use another > >> address space in order to "solve" the issue, the restriction > >> enforcement on the SCTP kernel driver (implemented by function > >> sctp_v4_addr_valid -- net/sctp/protocol.c -- in expansion of > >> IS_IPV4_UNUSABLE_ADDRESS -- include/net/sctp/consntans.h) seems odd to > >> me, because the address is a valid unicast IPv4 address and should be > >> acceptable as per RFC4960 clause 8.4: > >> > >> The receiver of an OOTB packet MUST do the following: > >> > >> 1) If the OOTB packet is to or from a non-unicast address, a > >> receiver SHOULD silently discard the packet. Otherwise, > >> > >> The source code states that this restriction came from > >> draft-stewart-tsvwg-sctp-ipv4, which is true, and the sysctl > >> net.sctp.addr_scope_policy is documented in ip-sysctl.txt as a switch > >> for the desired draft behavior, but changing the sysctl value has no > >> effect because IS_IPV4_UNUSABLE_ADDRESS macro expansion has no > >> verification of any sysctl configuration nor the sctp_v4_addr_valid. > >> > >> The draft-stewart-tsvwg-sctp-ipv4 enforcement seems like a bug or I am > >> missing something? > >> > > There must be a reason for not using 198.18.0.0/24 in SCTP, as in > > > > https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctp-ipv4-00#section-3.1 > > > > [1] IANA, I., "Special-Use IPv4 Addresses", draft-iana-special-ipv4- > > 03 (work in progress), April 2002. > > > > https://datatracker.ietf.org/doc/html/draft-iana-special-ipv4-03 > I think not allowing it at all is wrong. > https://datatracker.ietf.org/doc/html/rfc6890 > states that it is not global. So maybe level 3 would be more appropriate. > I will fix it, thanks. > Please note, the ID was never published as an RFC, so there might be more > errors... > > Best regards > Michael >
