[Snort-users] IPv6 support in Snort rule syntax
Suresh Kumar J
suresh.kumar.j at ...11827...
Mon Aug 18 15:09:22 EDT 2008
Learnt that the upcoming Snort v3.x will have the IPv6 support. Wanted
to know if there are any updations to be made in the Snort rule syntax
to accommodate the IPv6 header parsing.
As you know, the IPv6 header has gone through significant changes from
the IPv4 header:
* Length of the Source and destination IP addresses are 128-bits now
* Some of the fields have been renamed such as Type-of-Service(ToS) ->
Traffic Class, TTL -> Hop Limit, Protocol --> Next header
* A new field is introduced as 'Flow Label'
* New set of extension headers are introduced like Hop-by-Hop,
Destination, Routing, Fragment, AH, ESP.
* The IPv4 header fields such as Identification, fragment-bits,
fragment-offset have been moved to Fragment extension header in IPv6
As of now, the Snort syntax supports matching on a particular protocol
be specifying the protocol 'ip', 'tcp', 'udp' and 'icmp'. User can
configure to match on particular header fields on IPv4, ICMPv4, TCP and
* With the IPv6 support, will there be new protocol constructs
introduced something like 'ipv6' and 'icmpv6' for matching only on the
IPv6/ICMPv6 traffic?. Or else, the existing 'ip', 'icmp' protocol
constructs in the Snort syntax still be used to match on both the IPv4
and IPv6 traffic?.
BTW, in a real-world network, is it possible for both the ipv4 and ipv6
traffic to be seen in a single network segment?.
Cisco Firewall's ACL CLI syntax allows the user to specify the ipv4 and
ipv6 protocols separately. If the user wants to match on both IPv4 and
IPv6 traffic then it seems like he need to write two ACLs with one with
ipv4 and another with ipv6. For your reference,
* What if the user specifies 'alert tcp ...' or 'alert udp ...' rules,
will the Snort match on both IPv4 and IPv6 traffic?
* The Snort syntax should for sure accommodate the 128-bit IPv6
* Will there be new Snort options introduced for matching on the IPv6
header fields such as 'tclass', 'hlimit', 'ip6_proto', 'flabel'. Or the
existing IPv4 snort options(tos, ttl and ip_proto) to be overloaded for
matching on these fields?
* As the fragmentation related fields have been moved to the extension
header in IPv6, do the Snort syntax allow the existing options such as
'id', 'fragoffset', 'fragbits' to be used even for matching on the IPv6
* Will there be any new snort options introduced to match on the
individual fields in the IPv6 extension headers?.
* If there are any new options to be introduced for IPv6 support, how
are they going to be accommodated in the already published Snort rules?
Just thought of posting these questions to know if there are any
decisions already made, otherwise start on a discussion in this regard.
More information about the Snort-users