Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Proposal on IPv6 link-local host discovery features
From: David Fifield <david () bamsoftware com>
Date: Wed, 8 Jun 2011 15:28:09 -0700

On Tue, Jun 07, 2011 at 02:39:41PM +0800, Xu Weilin wrote:
HI all,
I have written a draft about the link-local host discovery features. I added
3 options and modified one option in the HOST DISCOVERY section, and
modified the TARGET SPECIFICATION section. Then I gave some examples at the
end of the draft. Please don't hesitate to express your suggestions.


*TARGET SPECIFICATION
Modified:
IPv6 addresses not only can be specified by their fully qualified IPv6
address or hostname. but also can be specified by CIDR. You can append
/numbits to an IPv6 address or hostname and Nmap will try to reduce the
(sometimes huge) set of IPv6 ranges into a list of active hosts during the
host discovery phase. The smalllest allowed value is /64, which scans a
typical IPv6 subnetwork. The largest value is /128, which scans just the
named host or IPv6 address.

This looks good. I agree we want to show a warning or an error if
someone specifies too big of a network, because it's probably a mistake.
But we also want to allow general parsing, because for example someone
might want to put a /16 or something in an --excludefile.

One modified option´╝Ü
-PR(ARP Ping or ND Ping)
On IPv4 ethernet LAN, ARP scan is much faster and more reliable than
IP-based scans. So it is done by default when scanning ethernet hosts that
Nmap detects are on a local ethernet network. Even if different ping types
(such as -PE or -PS) are specified, Nmap uses ARP instead for any of the
targets which are on the same LAN.

The IPv6 Neighbor Discovery (ND) protocol includes a feature of address
resolution that could be seen as the equivalent of ARP for the IPv6 over
ethernet. Unlike APR Ping has the highest priority on IPv4 ethernet LAN, ND
Ping won't be used if the --multicast option or the -PL option is specified.

Note that the -PR option only works on native IPv6 connection over Ethernet,
since the tunneling IPv6 links ususally contains a NOARP link flag.

I agree with this one completely. -PR does unicast neighbor discovery,
but unlike in IPv4 it's not the highest-priority method.

*HOST DISCOVERY
I added three new options and modified one option. All of them need the root
privileges.

-PH (Invalid hop-by-hop extension header)
Nmap sends an invalid hop-by-hop extention header to the target IPv6 hosts,
expecting an ICMPv6 of Parameter Problem in return from available hosts.
Considering some hosts may refuse echo ping, this method is a backup. Note
that this option is only available when the target is on the local
subnetwork.

-PL (SLACC-based method over IPv6 network)
The new probe method for IPv6 network is based on StateLess Address
AutoConfiguration mechanism. Nmap tries to disguise as a router and
distribute new IPv6 addresses to targets which are on the same LAN. Then the
available hosts will send a NS packet to the LAN under the Duplicate Address
Detection mechanism.

--multicast (Multicast ping over IPv6 network)
Nmap sends ping packets to ff02::1, expecting tons of replys from all alive
hosts on the same LAN. The --multicast option sends an ICMPv6 echo request
and an invalid hop-by-hop extension header by default. It also can be
combined with the -PE and the -PH. If any of the two probe types is used,
the default probes are overriden. Though the SLACC-based method uses
multicast feature as a part, it is irrelevant to the --multicast option.

I like these new methods. But would like to have even more of them, and
I think we'll run out of letters to use. Instead, how about we make all
of these the default for IPv6 local-net scans? (And we could give it a
letter like ARP scan has -PR, knowing that it would not often be used.)

My thinking is that we can have dozens or hundreds of these multicast
probes, because they are so cheap. We can add more as we think of them
and find that they are effective.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]