Re: Proposal on IPv6 link-local host discovery features

[David Fifield <david () bamsoftware com>]

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/