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 [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
