Do bitfields really need to be up to 62 bits long?

[LPardue]

In a few places there is Capabilities Flags (i), which is a varint that can provide between 6 and 62 bits. Given that there are only two things currently defined, this is a slight waste of space if implementations don't minimally encode. It also introduces potential interop issues if you don't define MSB or LSB. If we stick with that design, some more text would probably be required.

A different approach here is to just list out the bits e.g. assuming 8-bit alignment is desirable, the smallest thing we could do is

IPv4 capable (1),
IPv6 capable (1),
Reserved(6),

this would give back 2 bits otherwise consumed by the varint encoding, and allow up to 6 more future capabilities.

There's a tradoff either way but given that these fields won't be sent often, I don't think we need to over-optimize.

[GrumpyOldTroll]

I agree it doesn't much matter in terms of performance, and that if we leave it the way it is a bit more text is required.

A bit of brainstorming came up with 2-3 more bits that might theoretically be worthwhile additions for future extensions if anyone ever has a use case (namely: dns, asm, and a new ip version).

So I guess I'd be comfortable making this an 8-bit fixed field and requiring a heavier weight extension if we run out due to unforeseen needs.