Re: Proposal on IPv6 link-local host discovery features

[Xu Weilin <mzweilin () gmail com>]

Hi all,
Thank you for your feedbacks! But I'm sorry I could only give some brief
answers since I'm busy doing my final exams now.

On Thu, Jun 9, 2011 at 6:28 AM, David Fifield <david () bamsoftware com> wrote:
> But we also want to allow general parsing, because for example someone
might want to put a /16 or something in an --excludefile.

On Thu, Jun 9, 2011 at 11:16 AM, Fyodor <fyodor () insecure org> wrote:
> What about ranges?  In IPv4 we allow things like "10.*.*.1" or
192.168.0.1-254.
> ...
> And if that sort of syntax is allowed, do you do multicast by default
> like you would with a /netmask?

Since there are resonable application scenarios of the IPv6 ranges, we shall
allow the sorts of syntax.

Yes, we can do multicast probes and exclude that alive hosts out of the
range.

On Thu, Jun 9, 2011 at 11:16 AM, Fyodor <fyodor () insecure org> wrote:
> In that case, would scanning even larger spaces be feasible?

Actually, the multicast ping scans don't need to know the prefix length.

Most ethernets use a 64bits-long prefix. Some OSes (e.g. Windows XP) even
couldn't work with SLAAC when given a non-64-bits prefix.

> On Thu, Jun 9, 2011 at 6:28 AM, David Fifield <david () bamsoftware com>
wrote:
> I like these new methods. But would like to have even more of them

I don't think it is the more the better. I select two sorts from the dozens
of multicast probes provided by the alive6 tool because other types are not
so efficient in my tests. In addition, TCP and multicast seems to be
mutually exclusive. And multicast UDP probes seems to be invalid unless the
port is open. (Maybe it can be used to do multicast port scanning but I'm
not sure at the moment.)

I also agree that we can add more multicast probes listed by Luis if they
are tested to be helpful to host discovery.


On Thu, Jun 9, 2011 at 11:16 AM, Fyodor <fyodor () insecure org> wrote:
> -PH (Invalid hop-by-hop extension header)
> ...
> What sort of packet is sent with the hop-by-hop extnesion header?
> Like is it always an echo request or SYN to port 80 or what?  So by
> default (if -PH is specified by itself) it is sent to every potential
> IP address, but with --multicast it is sent to the IPv6 multicast
> address and only those hosts which reply are considered up?  In what
> way is the header invalid?  I guess it is only supported on the local
> subnetwork because any router would drop it for being invalid?

Yes this probe is only available on the local subnetwork. The valid option
types in hop-by-hop header include the Jumbo Payload (RFC2675) and the
Router Alert (RFC2711). We can specify an invalid option with the
highest-order two bits '10' so that the  processing IPv6 node will reply a
Parameter Problem packet.

I think any higher-layer message can be over the invalid header because the
IPv6 node won't process it. But we can specify it to be echo request
message.

I have realized that the multicast feature should be enabled automatically
if Nmap detects the targets are on a local ethernet network unless users
specify the --unicast option. I will tell something about the --multicast
option later.


On Thu, Jun 9, 2011 at 11:16 AM, Fyodor <fyodor () insecure org> wrote:
> > -PL (SLAAC-based method over IPv6 network)
> Does this cause any negative side effects?  Like is their a risk that
> when Nmap tries to distribute new IPv6 addresses, other machines will
> take them and reconfigure?  Can you describe the technique in a little
> more detail or provide a link?

The side effects of this method can be avoided indeed. I have a detailed
design in my GSoC proposal.
http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/mzweilin/1

> What happens if -PH or -PL are given and some of the targets are not
> on the local network?

Nmap should give a warning and send other default probes, I think.

> > --multicast (Multicast ping over IPv6 network)
Fyodor raised lots of questions about this option. I suppose it will be
better if we define a --unicast option instead. In this way, the several
multicast probes will be sent automatically when Nmap detects the targets
are in the local subnetwork and the --unicast option isn't specified.

> What should it do if the /64 is not on the local network?
Nmap should give a warning before starting the unicast ping scanning if the
prefix is too short. I think the scanning time is acceptable if the prefix
is longer than 112 bits.

-- 
Regards
许伟林 (Xu Weilin)
Beijing University of Posts & Telecommunications
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/