Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-08

Interesting work, thanks.

On the VMWare ESX example given in Sec. 3.1.1.1, the OUI given for automatically-generated MAC addresses (00:05:59) does not seem correct. In the linked documentation, it is listed as 00:0C:29. In the IEEE OUI list, 00:0C:29 is registered to VMWare but 00:05:59 is registered to some other company.

In Sec. 3.1.1.3 and 3.1.1.4, I wonder if you might want to re-use the terminology from draft-ietf-6man-ipv6-address-generation-privacy in the section headings, in particular to differentiate "Constant" IIDs from "Stable" IIDs. I think this would be better than using "Privacy-Enhanced" as the term "privacy" is now overloaded when it comes to different types of v6 addresses.

I think the tables in 3.1.5 would be a lot more useful if the table captions noted the total number of addresses investigated (N).

In Section 3.5, wouldn't using RFC 4941 addresses count as a mitigation as well (first bullet)?

Sections 5-13 seem like they belong as subsections of an overarching section about "Other Network Reconnaissance Techniques" or some such. It might also help to provide some indication of how resource-intensive these techniques might be relative to each other. There are other application-specific ways of gathering information about active IP addresses that aren't listed here (the example that comes to mind is an attacker standing up a TURN server) but are probably also more trouble than they're worth for most attackers, which is presumably why they are not included in the list.

Just a couple of nits:  

1. If this document obsoletes rfc5157, then it can’t really update it, can it?   You mention it updates and obsoletes 5157 in the Abstract and Introduction.

2. Introduction.  I think you meant:  s/[van-Dijk] describes a technique for leveraging DNS reverse mappings for discovering IPv6 nodes./Section 4 describes a technique for leveraging DNS reverse mappings for discovering IPv6 nodes [van-Dijk]

Nice document you have here.  Just two really small comments, neither of which needs any response, and both of which you can ignore if you prefer.

An observation: Three times, you say that something is "obvious", and this can come across as condescending -- and can be frustrating to a reader for whom it isn't obvious.  I suggest omitting that, so 

- In Section 3.1.1.1, change "Firstly, as it should be obvious from the algorithm described above" to "Firstly, as shown by the algorithm described above".

- In Section 3.1.3.2, change "For obvious reasons, the search space for addresses following" to "The search space for addresses following".

- In Section 3.3, change "Obviously, a number of other network reconnaissance vectors" to "A number of other network reconnaissance vectors".

-- Section 3.1.1.1 --

An observation, for which the response is probably "everyone knows this, so no change is needed," but please think about it for a fleeting moment:

   1.  The "Universal" bit (bit 6, from left to right) of the address is
       set to 1

Bit 6, starting from 0, or from 1?  The answer (which I can see from the example) is "starting from 0."

   Firstly, as it should be obvious from the algorithm described above,
   two bytes (bytes 4-5) of the resulting address always have a fixed
   value (0xff, 0xfe)

Bytes 4-5, starting from 0 or from 1?  The answer (which I can see from the example) is "starting from 1."

The fact that the origins differ makes me think that it'd be nice if that were made clear.  Please give it a thought, to say that bits are numbered from left to right starting at 0, and bytes are numbered from left to right starting at 1.

Thanks for your work pulling together a summary of reconnaissance techniques for IPv6.  I think this is a useful document, that will be helpful to operators and security professionals.  I don't have any comments to add that have not already been mentioned.

I echo Barry's "nice document", and would support the changes he suggested.

I did notice what I believe is a repeated "not" in "it is not not only the lowest-order byte".

In this text:

3.4.1.  Remote IPv6 Network Scanners

   Many address scanning tools such as nmap [nmap2012] do not even
   support sweeping an IPv6 address range.
                           ^ 
does this mean "sweeping an IPv6 address range in a remote IPv6 network"? I think that's implicit from the section title, but what nmap supports is clearer in the corresponding text in the next section:

3.4.2.  Local IPv6 Network Scanners

   There are a variety of publicly-available local IPv6 network
   scanners:

   o  Current versions of nmap [nmap2012] implement this functionality.