Network Reconnaissance in IPv6 Networks
RFC 7707

Note: This ballot was opened for revision 07 and is now closed.

(Stephen Farrell) Yes

Comment (2015-08-19 for -07)
No email
send info
- general: @Fernando: thank you for writing a document that does
not recommend turning off IPv6:-)

- general: shouldn't you recommend a honeynet approach as another
way of spotting scans when there ought be none? That might fit in
3.5 I guess.

- intro: what evidence is there that the number of hosts per
subnet is likely to stay the same? (And what do you consider an
IPv4 subnet here? a /16 is it? Maybe worth saying.) The density
point still applies though, but good to not assume things that
aren't needed.

- 3.1.1 - I would recommend you check with Christian Huitema
about Windows10 which has some new features related to MAC
addresses. I don't know if there is new IPv6 handling associated
with those changes.

- 3.4.1 s/patters/patterns/

(Joel Jaeggli) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

Comment (2015-08-19 for -07)
No email
send info
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.

(Spencer Dawkins) No Objection

Comment (2015-08-16 for -07)
No email
send info
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.

Barry Leiba No Objection

Comment (2015-08-14 for -07)
No email
send info
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.

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-08-20 for -07)
No email
send info
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.

Alvaro Retana No Objection

Comment (2015-08-19 for -07)
No email
send info
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]

(Martin Stiemerling) No Objection