From: Michael Tuexen <tuexen@freebsd.org>
To: Xin Long <lucien.xin@gmail.com>
Cc: Sérgio <surkamp@gmail.com>,
"linux-sctp @ vger . kernel . org" <linux-sctp@vger.kernel.org>
Subject: Re: draft-stewart-tsvwg-sctp-ipv4 enforcement
Date: Fri, 18 Jun 2021 22:35:49 +0200 [thread overview]
Message-ID: <E440156C-0164-4F55-83A9-860C1180CFDD@freebsd.org> (raw)
In-Reply-To: <CADvbK_d8=rfzObEYEG35jVdm-yDzc4gN+v4EvRRCnrh8j36h9g@mail.gmail.com>
> On 18. Jun 2021, at 18:35, Xin Long <lucien.xin@gmail.com> wrote:
>
> On Thu, Jun 17, 2021 at 4:40 PM Sérgio <surkamp@gmail.com> 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.
Please note, the ID was never published as an RFC, so there might be more
errors...
Best regards
Michael
next prev parent reply other threads:[~2021-06-18 20:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 19:01 draft-stewart-tsvwg-sctp-ipv4 enforcement Sérgio
2021-06-18 16:35 ` Xin Long
2021-06-18 20:35 ` Michael Tuexen [this message]
2021-06-18 20:54 ` Xin Long
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=E440156C-0164-4F55-83A9-860C1180CFDD@freebsd.org \
--to=tuexen@freebsd.org \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=surkamp@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.