All,
Earlier on, we had a bit in the header to indicate whether or not we had an extended header (32 bits of data immediately preceding the payload). Since that time, we agreed to absorb the bit into the pkt_type field, so we had more flexibility in packet
types (we wouldn’t necessarily need to have a standard and extended header version of each packet type). This makes sense.
Since there’s no longer a single bit to say whether or not there’s an extended header, are we now limited to extended headers only being 32 bits? Since the packet type defines the format of the header after the first 48 bits, why couldn’t the definition
for that packet type define whether the extended header portion is 16, 32, 48, 64, 80, or 96 bits? (I’m assuming we’d at least want to be on 16-bit boundaries, if not 32.) I don’t see a solid reason to limit any extended headers to only 32 bits.
That said, I haven’t though through the implications of what this does to our representation of packet formats in the spec. I would expect that the definition of each specific packet type would indicate the length of any extended header portion, and the
examples would show this specific header format. For a given packet type, you can look up exactly how long the header is—there is no variation in header length for a given packet type.
Thoughts?
--kb