Re: Accurate ECN support in tcpdump/libpcap

[Michael Tuexen <michael.tuexen () lurchi franken de>]

> On 13. Nov 2025, at 15:34, Denis Ovsienko <denis () ovsienko info> wrote:
>
> On Thu, 13 Nov 2025 08:17:00 +0000
> "Scheffenegger, Richard" <Richard.Scheffenegger () netapp com> wrote:
>
> > Hi Denis,
> >
> > Before discussing the various alternate ways - what exactly are you
> > referring to with "breaking compatibility" when tcp[tcpflags] maps to
> > 12:2 instead of 13:1?
> >
> > Is there an expectation that people use "tcpflags" as a "shorthand"
> > for 13:1? Or that is being used in contexts outside of the tcp header
> > flags?
> >
> > Because within the context of the tcp header, the flags were always
> > defined to be 12 bits wide, since 1981, or 2003 at the latest.
>
> Hello Richard.
>
> Please note that as far as the specifications define it, they never
> were.
>
> RFC 793 (published in September 1981) Section 3.1 says:
>
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Data |           |U|A|P|R|S|F|                               |
>   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
>   |       |           |G|K|H|T|N|N|                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
>  Reserved:  6 bits
>    Reserved for future use.  Must be zero.
>
>
> RFC 3168 (published in September 2001) Section 23.2 says:
>
>   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>   |               |               | C | E | U | A | P | R | S | F |
>   | Header Length |    Reserved   | W | C | R | C | S | S | Y | I |
>   |               |               | R | E | G | K | H | T | N | N |
>   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>
>
> RFC 9293 (published in August 2022) Section 3.1 says:
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Data |       |C|E|U|A|P|R|S|F|                               |
>   | Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
>   |       |       |R|E|G|K|H|T|N|N|                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
> Reserved (Rsrvd):    4 bits
> A set of control bits reserved for future use. Must be zero in
>    generated segments and must be ignored in received segments if the
>    corresponding future features are not implemented by the sending or
>    receiving host.
>
>
> In all diagrams you can see the reserved space is a unstructured block
> rather than a bitmap pre-allocated into individual 1-bit flags with
> names such as ReservedFlag-16, ReservedFlag-15, ReservedFlag-14 etc.
Have a look at the IANA registry:
https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags
IANA handles them as 12 bits.

Best regards
Michael
> Arguably, RFC 9293 says "a set of control bits", so perhaps the
> guess/impression/idea/figure of speech (but not the formally
> specified norm) is that the rest of the available bit space will be
> allocated to more flags later.  But RFC 793 conveyed no such guess, and
> for 20 years until ECE and CWR were allocated it was not obvious
> whether even the rest of the byte 13 would become more flags, let alone
> byte 12.
>
> This way, when the named offset "tcpflags" meaning 13 (with the implied
> load size of 1 byte) was added to libpcap in what is now known as git
> commit 4ed1792 (February 2001) and became generally available in
> release 0.7.1 (October 2001), the equivalence of "tcp[13:1]" and
> "tcp[tcpflags]" was a good fit for 20 years of Internet development
> before that, and remained a good fit for more than 20 years afterwards,
> so it seems almost certain "tcp[tcpflags]" has been baked into some
> non-interactive software that uses libpcap.
>
> It is conceivable that some of such software trusts "tcp[tcpflags]" to
> evaluate to an 8-bit value, and uses it as a part of a more complex
> arithmetic expression that would not handle an overflow correctly.  Or,
> for example, the software captures packets that match "tcp[tcpflags] !=
> 0" and runs them through a switch block that assumes that at that point
> at least one of the 8 TCP flags it knows is set, but this would no
> longer be the case if tcp-ae matched, but none of the other flags did.
> Or, for example, the software prints to a string buffer an exact 8-bit
> value for the specific combination of flags it needs to match, but then
> one day for no apparent reason "tcp[tcpflags] == 0x02" no longer
> matches all packets with only SYN set in byte 13.  
>
> Or this is not a software, but a firewall rule, because some firewalls
> can take, via BPF, libpcap filter expressions to match packets.  And/or
> the matching is offloaded to some sort of network hardware, where
> problems could cascade further.
>
> So let's be wise to choose a solution space that does not make the
> problem space larger.
>
> > But back to the issue - what compatibility issue is expected to
> > arise?  As user, who infrequently uses tcpdump with all the
> > functionalities - I'd expect there to be only one way to access *all*
> > tcp flags by name; and if i need something special, it'll be possible
> > to convert scripts that somehow (I don't know how, my imagination
> > fails me) require tcp[tcpflags] to return only a 8 bit value, to be
> > redefined tcp[13:1] in those scripts as a one-off change after
> > updating tcpdump which has proper tcp header flags support...
>
> Interactive use with a relatively short feedback loop is one important
> use case, but not the only.
>
> -- 
>    Denis Ovsienko
> _______________________________________________
> tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
> To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s