On 5/05/11 05:09 PM, Guy Harris wrote:
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.
I looked over the other 16 bit fields and came to the same conclusion as
yourself about the above so didn't mention them.
In the breakup where you were suggesting 10 bits that could be an
organization ID, reserve "0" for the publicly recognised set and all 1's
for private/experimental. Is 10 bits enough for an organisation ID? How
many organisations have received a number for use with SNMP? I'm not
saying that as many organisations will need an identifier here but
rather that the number of organisations might be larger than you would
suspect at first.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
