Extending flags

[martinthomson]

We need to define how the public flags might be extended, or if it could be. This has a pretty serious impact on #55.

[alagoutte]

Use 0x80 bitmap flag to say, there is a another byte flag ? (like radiotap) or already change to use 2 or 4 bytes ?

[ianswett]

I agree with Alexis the obvious approach is to use 0x80 to indicate another byte of flags. If we think extended flags will be common, I think we should change to 2 bytes as a minimum, because variable length fields before the connection id are more annoying to process in some systems(ie: BPFs), particularly if the number of times one can add more flags is unbounded.(ie: IPv6 extension headers).

I would lean towards suggesting that extended flags should come after the connection id.

[martinduke]

I think a 2-byte field will be annoying in the near to medium-term, where the second byte is unused. Having the second byte after connection ID (and version?) would be annoying in the more distant future when 8+ flags are routine.

But in either case, this is a matter of taste and I see no showstoppers with having the extra flags come later. Especially since we might end up having lots of these flags.

On the other hand, I can imagine future protocol tweakers "abusing" unlimited public flags to put whole bitfields in there. I'm not sure if this is a "problem" we need to solve or not.

[martinduke]

In any case it might be worthwhile to spell out what's acceptable in the bounds of a version. If a given version has 6 defined flags, can there be any number of public flag bytes? If so, do I simply ignore whatever's there?

[mnot]

As discussed in Tokyo, @ekr to write up "special packets" proposal & then we'll revisit this

[MikeBishop]

#361 purports to address this; please re-open or file a new issue if that's incorrect.