mailing list archives
Re: Gsoc 2011 idea about IPv6
From: Xu Weilin <mzweilin () gmail com>
Date: Tue, 5 Apr 2011 10:34:40 +0800
On Fri, Apr 1, 2011 at 1:56 PM, David Fifield <david () bamsoftware com>wrote:
I see that the latest THC-IPV6 release (1.4) additionally can do UDP,
TCP ACK, and TCP SYN. I haven't tested to see if these are unicast-only.
I've tried alive6 tool of THC-IPV6 ver.1.4. Here is the discription of -s
-s NUMBER scan type, bit-wise add: 1-ping, 2-invalid header,
4-invalid hop-by-hop, 8-udp dns, 16-tcp ack highport,
32-tcp syn ssh, 64-tcp syn web, 128-tcp syn ssl; default: 5
I made an efficiency ranking of scan types:
4-invalid hop-by-hop, Found 30 systems alive
1-ping, Found 27 systems alive
8-udp dns, Found 2 systems alive (Only that hosts with DNS service)
2-invalid header, Found 0 systems alive
16-tcp ack highport, Found 0 systems alive
32-tcp syn ssh, Found 0 systems alive
64-tcp syn web, Found 0 systems alive
128-tcp, Found 0 systems alive
From the tests we know that alive6 can send multicast UDP and TCP packets,
but it is nearly useless in host discovery. Moreover, the combinition of
scan type is also useless.
However, the multicast UDP and TCP packets can be used to do high efficient
port scanning in local link. The scan type of 8-udp dns is a good example.
In order not to disturb the network, the RA packet should be carefully
constructed within three principles:
1) Not a default router;
2) Address prefix should be insignificant in the network. A random
Unique-local Address prefix is suitable.
Short valid life time.
I just noticed a few days ago that there is a Metasploit module that
does this: (at least if I understand you correctly)
I'm sorry I didn't notice this before, but we can do a better job. I've read
the code of this Metasploit module and found some problems. Wuntee just
neglected the 3 principles of constructing RA packet I mentioned before. My
other hosts couldn't access IPv6 network after receiving the RA packet and I
saw 2001:1234:DEAD:BEEF:: in the routing table. The procedure of host
discovery should be stealthy I think.
For hosts discovery over Internet, it becomes harder on IPv6 for its
2. Take use of SLAAC mechanism.
Since most IPv6 networks use SLAAC mechanism to configuring IPv6 address
most OSes generate EUI-64 by use of MAC,the scanning space is reduced to
if the prefix and ether vendor have been confirmed.
The vendor codes are available on these pages:
Yesterday I found WinXP and Win7 didn't use standard EUI-64 by default. The
situation on other Windows products may be the same. Considering the market
share of Windows, the efficiency of the method may decrease.
In addition, I found even many administrators don’t like this feature for
the sake of management and compatibility. Some of them will disable this
feature when configuring networks.
Windows users can type this with administrator privilege to enable standard
netsh interface ipv6 set global randomizeidentifiers=disabled store=active
netsh interface ipv6 set global randomizeidentifiers=disabled
Windows users can type this with administrator privilege to disabled
temporary identifier (RFC 3041):
netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent
I think that both host discovery and OS detection are big enough to be
their own projects.
Thanks. I will take host discovery into first consideration.
Beijing University of Posts & Telecommunications
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/
- Re: Gsoc 2011 idea about IPv6 Xu Weilin (Apr 05)