Comments on 4.1. Section Header Block - don't allow multiple SHB's

[erik4711]

4.1. Section Header Block

From the pcapng spec:
“Please note: The endianness is indicated by the Section Header Block [section_shb]. Since this block can appear several times in a pcapng file, a single file can contain both endianness variants.”

• I would prefer if the spec would only allow for one SHB per pcapng file. I'm guessing the reason for allowing multiple SHB's is to facilitate merging of pcapng files, but such freedom comes with a too high cost. One problem that comes with allowing multiple SHB's is that the trailing "Block Total Length" at the end of each block can't be used to move backwards in a pcapng file, since a change of endian by an SHB will cause the length field to be interpreted incorrectly. Even skipping forward in a pcapng file can be dangerous unless care is taken to read the endian of each newly encountered SHB. Merging pcapng files is an easy task, even if we allow only one SHB per file, so there is no need to simplify this task even more. There are just too many downsides to having multiple SHB's in a pcapng file. Which reminds me of this quote by Einstein: “Everything should be made as simple as possible, but no simpler.”
• There is no real point in allowing for both big-endian and little-endian. Requiring all pcapng writers to use one endianness will not even affect performance notably. Just think of all the network protocols specified for big endian even though many CPU's are little endian. TCP is, for example, forced to transmit sequence numbers and window size values in big endian, yet you will never see the endianness conversion being a performance issue in TCP. I would personally prefer to have all pcapng files to be big endian ONLY.
• Section Length field isn't used, it can be removed from the spec.
• Having the “Byte-Order Magic” field after the “Block Total Length” isn't great, since we need to know the endian (from the magic field) before we can parse the length field anyway. I understand that this is an attempt of having the SHB to extend the generic “General Block Structure”. However, the SHB can NEVER be parsed as a generic block anyway since it allows for a change of endianness which must be dealt with by all parsers.
• Please refrain from padding stuff to 32 bit boundaries. Doing so actually introduces unnecessary complexity rather than solving a problem.

My recommendation: Only allow one SHB per pcapng file.