[pcap-ng-format] Proposed new Alternative Packet Block

[Serge Aleynikov]

On Sun, Aug 14, 2016 at 12:25 AM, Guy Harris <guy at alum.mit.edu> wrote:

> On Aug 13, 2016, at 8:57 PM, Serge Aleynikov <serge at aleynikov.org> wrote:
>
> > ​So, with this revision, let's ​modify the layout of this option type,
> and also for the purpose of preserving alignment, let's keep the code/value
> 2 octets each:
> >
> > ​ 0                   1                   2                   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |0 0 1|      Option Code        |         Option Value          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Hence, revised option codes become (with added apb_iface_id option):
> >
> > Options:
> >    Name          Code    Length  Multiple?  Description
> >    apb_opt_size  0x2001  -       no         Total byte size of options
> >    apb_orig_len  0x2002  -       no         Packet's Original Length
>
> That means that the APB can't be used if the original length was > 65535.
>
> Preserving alignment for short options might not be *that* important if
> supporting packets > 65535 bytes in length *is* important.
>

​
​But how practical is it to have a packet whose size is > 64k?  TCP/UDP is
limited to 64k.

If we go with the unaligned option value (3 octets), and 1 octet for the
option code, then given the loss of 3 highest bits, that leaves only 5 bits
for option values, leaving only 32 possible choices, which is still plenty.

So if unaligned layout is acceptable that would be preferable.

>> There's no ​​FCS length field; do these packets have an FCS iff the "FCS
> length" field for interface 0's IDB is non-zero (so that all packets for
> that interface, whether they were transmitted by this host or received by
> this host, either have an FCS or don't have an FCS)?
> >
> > ​Wouldn't that frame check sequence be part of the packet data?
>
> Yes, but there needs to be a way to indicate whether it's present, as it's
> not *always* part of the packet data.  For the EPB, there's both the IDB
> indication and a per-frame indication, in case either
>
>         1) the FCS length changes over time (e.g., if the presence or size
> are changed by negotiation in the middle of a PPP connection)
>
> or
>
>         2) not all frames have an FCS (e.g., if received frames have one
> but transmitted frames don't).
>
> For the SPB, the FCS must be present, or absent, in all frames, and, if
> it's present, it must have the same length in all frames, as there's no
> per-frame indication.
>
> For the APB, if there's no per-frame FCS indication, it must be present,
> or absent, in all frames, and, if it's present, it must have the same
> length in all frames.
>

​So, introduce another short option code for presence of the FCS
indication, or reserve a bit #12 in the apb_flags option?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20160814/75419cd3/attachment.html>