[Guy Harris <gharris@xxxxxxxxx>]

Visser, Martin wrote:

> The fieldds ip.src,ip.dst and ip.addr are "special" and can't be indexed
> directly.

Actually, that's true of any IPv4 address, as well as being true of 
integral types.  "ip.src", "ip.dst", and "ip.addr" aren't different from 
any other IPv4 address fields, they just happen to have a type (IPv4 
address) that doesn't support "slicing".

IPv6 addresses, however, are "sliceable"; I'm not sure there's a strong 
reason to forbid it on IPv4 addresses (or perhaps even on any of the 
integral data types).

> Unfortunately (and the manual isn't all that clear on this) though
> integers are able to be represented by "decimal, octal, or hexadecimal",
> this doesn't apply to the byte values in the substring. These have to be
> hex (also shown above)

The manual should probably be fixed to make that clear.  If there's a 
bug (and I'd argue that there is), that's the bug - the manual doesn't 
indicate that it's the numbers in the index expression, not the numbers 
in a byte string, that can be in decimal, octal, or hex.

(In any case, as noted, the right way to do subnet comparisons is with 
"{IPv4 field} == {addr}/{subnet bits}"; that can do more than comparing 
particular bytes of an IPv4 address can, *and* it's arguably closer to 
the way most people would express it, and more convenient to express as 
a result.)