RE: Adrian Farrel's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

["Templin, Fred L" <[e-mail]>]

Sorry Brian; here is the correct explanation:

> > They must have just made that up; there's no justification for it.
> > It could be an unknown extension header of unknown length, or it
> > could be an unknown payload of unknown length. In real life
> > I'd expect firewalls to default-drop such packets.
> 
> It could be that Wireshark has some kind of inference engine that
> says: "let's look ahead and see if the next octet looks like another
> NEXTHDR field, and if so keep on plowing through". It certainly
> surprised me. It might also be worth noting that tcpdump does not
> take this leap of faith and stops when it hits the first 253/254.

What is actually happening is that Wireshark assumes that the octet
that follows the NEXTHDR field that encodes 253/254 is a length field
and then seeks ahead by the number of octa-words indicated by the
"length".

In the case of my experimental protocol (SEAL, of course), the octet
that follows the NEXTHDR is *not* a length field, i.e., the same as
for the IPv6 fragment header. It just so happened that the octet
encoded the value 0 making the experimental header look like an
8-octet field. When I change the value to something other than 0,
Wireshark fails.

But, in the final analysis, there is no justification for assuming
that the field that follows the NEXTHDR field is a length field.
It's just that you might get lucky once in a while.

Thanks - Fred
[e-mail]