Displaying / filtering IPv6 ICMP types and codes
kwelker at vt.edu
Wed Aug 5 11:12:01 EDT 2015
Here's a first stab at defining text equivalents of the defined Types
and Codes. Hopefully they're consistent and distinctive, though people
can weigh in on that. These would allow users to make filter commands
more readable, at least for defined ones, if they so choose.
(These are from
hacked up by me.)
kwelker at vt.edu
On 8/4/2015 2:06 PM, Ken Welker wrote:
> Agree that printing and filtering are the most important tasks.
> From my testing, it looks like the ICMPv6 Type is printed in the low
> byte of the Sport field, while the Code is in the high byte, such that
> Sport = (Code*256) + Type; Dport is always 0. That's not horrible to
> decode, but requires a bit of effort if Code is nonzero. These are
> printed in decimal, but allowing a choice between hex and decimal
> would allow the user to express their preference.
> Looks like IPv4 also stuffs both Type and Code in the Sport like that
> as well, but prints in hex.
> Perhaps there's a few defined combinations of Type/Code that can be
> added to the State field; haven't looked at that yet thoroughly. I'm
> mostly thinking about all the *undefined* ones, like Type 128
> (echo-request) and code 42 (??? from IANA). That's why I think it
> would be good to allow displaying Type and Code in their own columns
> if desired.
> As for filtering, compiler keywords for Type and Codes will be good,
> but again, I'm thinking about all the undefined ones that I eventually
> will want to be able to filter on as needed. I agree that the icmp
> keyword should include both in filtering (but I just got syntax errors
> with it), and I like the icmpv4 and icmpv6 shortcuts.
> Ken Welker
> kwelker at vt.edu
> On 8/4/2015 11:12 AM, Carter Bullard wrote:
>> Hey Ken,
>> There are a number of basic operations that argus clients need to do
>> with the data that is in an argus record. Print, filter, sort,
>> graph, aggregate, union, join, intersection, split, anonymize, etc …
>> The most important first step is printing and filtering.
>> For printing, if you think the State field for ICMPv6 needs work,
>> we’ll need to figure out which types and codes need help. The type
>> and code fields are in the src and dst port fields, just like IPv4.
>> If that doesn’t look to be working, then we need to fix that. ICMP
>> type and code fields by default are hex outputs, do you think you
>> want to be able to change that format, say to a decimal value ???
>> Can we get a list of the compiler keywords we want to use to filter
>> on type and code values for ICMPv6 ??? Numbers are not the best way
>> to do that.
>> We don’t make a distinction between ipv4 and ipv6 when you use the
>> icmp keyword to get any icmp traffic, so we could add shortcut terms
>> ‘icmpv4’ and ‘icmpv6’. To get just ipv6-icmp, you have to say “
>> proto ipv6-icmp “, so we can add that.
>> We currently support 4 icmp type filter keywords, but they apply to
>> only v4 icmp:
>> We’ll need to extend the keywords so that they generate filters for
>> The keywords ‘type’ and ‘code’ are not used, so we can add that
>> support to the filter, with the notion that they refer to icmp
>> traffic. Generating a list of keywords for all the types and codes
>> will be most of the heavy work we need.
>> but to provide v4 vs v6 differentiation, we’ll need a filter like
>> “icmpv4 and type unreach and code port”
>> It maybe cool to be able to type:
>> “icmpv4 unreachable port”
>> “icmpv4 redirect host"
>> That is possible, but we’ll need to get the syntax down pat.
>> If we get these issues nailed down, we may be able to say we did good ;O)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the argus