http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1459
------- Comment #7 from sebastien@xxxxxxxxx 2007-04-01 14:16 GMT -------
(In reply to comment #6)
> Ah, OK, so it's the other way around: Add an ip.version to the ipv6 dissector.
> No I'm not happy with that either, because it is a different protocol and if
> someone wants to see ipv6 frames then just typing ipv6 instead of ip.version==6
> would be somewhat more intuitive.
I don't think so. IPv4 can be filtered easily by typing "ip" and not "ipv4".
Therefore, what does an alpha user to filter IPv6 which he tought is an
evolution of IPv4 (as said by IPng ;))? As Ulf said, they will remember first
there was a version field and probably won't think there is a l2 type to
differentiate them and even less that they have to type "ipv6" as "ipv4" does
not even exist. (That's my point of view of course)
> Nobody would identify ipx by just saying
> ip.version==15 and ip.hdr_len=15 and expecting this to work.
That's true ... but you're thinking as an expert.
> And the same goes for ipv6! Making a program user friendly doesn't mean that
> you have to catch each and every corner case that one individual meets under
> very specific (not to say broken) conditions.
>
> Regarding the idea of only matching on ip.version in ipv6 packets: A very
> strong no to that: So far we had *1* user who tried to identify ipv6 frames in
> a rather broken capture which fails to identify the protocol type because it is
> supposed to be ipv4 by DLT_TYPE. The idea of not being able to filter on any
> element in an ipv6 packet with a filter that starts with "ipv6." is plain
> wrong. *That* would be very user unfriendly.
>
ok with that ...
To conclude (on my side, maybe Ulf wants to discuss a litte bit more), I let
the ipv6 dissector unchanged as you seem strongly against this display filter.
;)
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.