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
