Displaying / filtering IPv6 ICMP types and codes

Wed Aug 5 11:12:01 EDT 2015

Hey Carter,

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.

-Ken

(These are from 
http://www.iana.org/assignments/icmpv6-params/icmpv6-params.xhtml, 
hacked up by me.)

Type,String
-----------
1,dst-unreach
2,pkt-too-big
3,time-exc
4,param-prob
128,echo-req
129,echo-reply
130,mcast-lstnr-query
131,mcast-lstnr-rpt
132,mcast-lstnr-done
133,rtr-sol
134,rtr-adv
135,neigh-sol
136,neigh-adv
137,redir
138,rtr-renum
139,icmp-node-info-query
140,icmp-node-info-resp
141,inv-neigh-disc-sol
142,inv-neigh-disc-adv
143,v2-mcast-lstnr-rpt
144,home-agt-addr-disc-req
145,home-agt-addr-disc-reply
146,mob-pref-sol
147,mob-pref-adv
148,cert-path-sol
149,cert-path-adv
151,mcast-rtr-adv
152,mcast-rtr-sol
153,mcast-rtr-term
154,fmipv6
155,rpl-cont
156,ilnpv6-lctr-update
157,dup-addr-req
158,dup-addr-confm
159,mpl-cont

Type,Code,String
----------------
1,0,no-rt-to-dst
1,1,dst-admin-prohib
1,2,beyond-scope-src-addr
1,3,addr-unreach
1,4,port-unreach
1,5,src-addr-fail-ingr-egr-pol
1,6,rej-rt-to-dst
1,7,err-src-rtg-hdr

3,0,hop-limit-exc
3,1,frag-rsmb-time-exc

4,0,err-hdr-field
4,1,unrec-next-hdr-type
4,2,unrec-ipv6-opt
4,3,first-frag-incompl-ipv6-hdr-chain

138,0,rtr-renum-cmd
138,1,rtr-renum-result
138,255,seq-num-reset

139,0,ipv6-addr-query
139,1,name-query
139,2,ipv4-addr-query

140,0,success
140,1,resp-refused
140,2,unk-qtype

Ken Welker
kwelker at vt.edu
540-231-0635

On 8/4/2015 2:06 PM, Ken Welker wrote:
> Carter,
>
> 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
>
> Ken Welker
> kwelker at vt.edu
> 540-231-0635
> 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:
>>    ‘echo’
>>    ‘unreach’
>>    ‘redirect’
>>    ‘timexed’
>>
>> We’ll need to extend the keywords so that they generate filters for 
>> ipv6-icmp.
>>
>> 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)
>> Carter
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20150805/cebcb5d4/attachment.html>