[Guy Harris <guy@xxxxxxxxxxxx>]

Ulf Lamping wrote:

> As far as I understand the problem, this applies to any what I would 
> call "combined fields" like ip.addr being a combination of source and 
> (or) destination address.

It applies to any field that can appear more than once in a packet. 
"combined fields" are one example, as they appear in the packet as 
copies of more than one existing field, but there can be other types of 
fields that can appear more than once - for example, even "ip.src" or 
"ip.dst" can appear more than once if the traffic involves tunneling of 
a packet layer that includes IPv4 inside a protocol stack that includes 
IPv4, and some protocols might have multiple instances of a given field 
even if you aren't doing tunneling.

Oh, and it could also appear in many (all?) fields for a protocol 
carried over TCP or carried over a protocol carried over TCP or 
(...transitive closure), because you can have more than one packet for 
such a protocol inside a link-layer frame if they'll fit.

The only fields it doesn't apply to are those that can never ever 
appear more than once in a given packet - and one should never 
underestimate the ingenuity of networking engineers in figuring out new 
ways of doing tunneling, so one should never underestimate the 
likelihood that you'll see more than one instance of a field for a 
protocol that you can't imagine appearing more than once in a packet. 
(I suspect there is at least one capture out there with more than one 
eth.type field in at least one packet).

So the question is whether we should give this warning for all fields 
that are "combined" fields", those fields plus all fields that could 
show up in a tunneled protocol or any protocol that can be carried by a 
tunneled protocol, all those fields plus fields that could appear more 
than once in a packet, or just for all fields.