mailing list archives
Re: -sO for IPv6
From: David Fifield <david () bamsoftware com>
Date: Wed, 15 Jun 2011 19:08:19 -0700
On Wed, Jun 15, 2011 at 05:40:27PM -0500, Dario Ciccarone (dciccaro) wrote:
Hm. This may end in a "TL;DR" . . .
I tried it against a couple devices - some observations:
1) For the actual extension headers (Hop-by-Hop (0), Routing (43),
Fragment (44), Destination Options (60), No Next Header (59)) - we're
just setting the NH field on the IPv6 header to each value. There's no
attempt to actually build a valid extension header (well, it IS valid
for 59 ;)). I think it would be more accurate if the extension header
was properly formed. I can provide pcaps for each one of them, if so
This is the same situation as for IPv4. We only send proper payloads for
a small number of protocols (ICMPv6, TCP, UDP, SCTP) and for the rest we
send empty payloads. Please send your packet captures so we can make it
2) Because of (1), 0, 43, 44 and 60 are erroneously reported as
"open|filtered", with reason "no-response". Actually, the thing is that
for the other ones being reported as "closed", the OS is indeed sending
back an ICMPv6(4,1) - but for those four I mention before, it's sending
back an ICMPv6(4,0) - which we aren't checking for as a return value.
Oops, you're right. In fact we are testing for ICMPv6(4, 0) (and marking
"open" in that case), but there is another bug that prevents that test
3) On top - if a device between the nmap scanning host & the target is
filtering traffic for those protocols, the filtered protocols are being
reported as (again) "open|filtered", "no-response" - even when the
filtering device *does send back* an ICMPv6(1,1) - which again, looks
like we're not checking for.
We are checking for ICMPv6(1, 1) (dest unreachable, admin prohibited),
but it might not be taking effect due to the same bug I mentinoed above.
4) There will never be anything back for an IPv6 packet with NH = 59 -
unless being filtered, and filtering device sending back ICMPv6(1,1).
Should, IMHO, be assumed open - if you're doing IPv6, you *have* to
support them all (0, 43, 44, 59 and 60) - so.
I think then that open|filtered/no-response is appropriate.
5) A Routing Header can either be type 0, 1 or 2 - RH0 was deprecated by
RFC-5095. If the actual RH was to be sent, we should probably test for
(at least) RH0 and RH2. It isn't enough to just test for "routing
6) Some devices, like Cisco IOS, can not only filter on a given
extension header (ie: "deny ipv6 any any dest-option", to filter any
IPv6 packet including a Destination Option extension header), but can
also filter on a specific option type within the extension header (ie:
"deny ipv6 any any dest-option-type 0" to filter a Destination Option
extension header including a Pad1 option). This could also be
implemented to further determine if *any packet with a given extension
header* would be dropped/filtered, or only those with a specific option
within their "payload"
I think that numbers 5 and 6 are better handled by a specialized script.
Protocol scanning is more like port scanning: try all these numbers and
see if they work. We don't have a way to express in the output table
that some variations of a protocol work and some don't, but that could
easily fit in a script with a portrule matching that particular
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/