On May 5, 2011, at 4:54 PM, Guy Harris wrote:
> On May 5, 2011, at 2:45 PM, Darren Reed wrote:
>
>> Looking through it, the first observation I'd make is that there should not
>> have been any 16 bit fields. The one that concerns me most is the IDB which
>> has a 16bit link type.
>
> We could add an "enhanced IDB" with a 32-bit LinkType field.
...and the only remaining 16-bit fields are:
the major and minor version numbers in the Section Header Block - yeah,
I know, 640K and all that, but I doubt that'll be an issue, especially for the
major version number (if you completely incompatibly change the file format
more than 65535 times in the next 1000 years, UR DOING IT WRONG, and even for
the minor version number, given the extensibility of the format, I don't see
much need for version number changes);
the Interface ID and Drops Count in the Packet Block, but that's been
deprecated in favor of the Extended Packet Block, with a 32-bit interface ID
and a 64-bit drop count as an option;
the Record Type and Record Length in the Name Resolution Block - I'm
not sure there will be more than 65533 more name types, so the Record Type is
probably OK at 16 bits, but I guess you could either have really really long
network addresses or, more likely, a huge number of names corresponding to an
address, so the 16-bit Record Length might be an issue, so there might have to
be an Extended Name Resolution Block.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
