Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

This draft analyses operational security issues related to the deployment of IPv6, and describes appropriate mechanisms and practices to mitigate potential threats.

The document is Not Ready for publication. 

General comments:

The draft is well written, and the authors are clearly experts in the area, but the evolution of 13 versions of the draft since WG adoption in 2012 means the draft is somewhat disjoint, and has a number of sections where current best practices and related RFCs are not included.  A prime example is in the area of address configuration.

There are seven pages on transition technologies; might that be better homed in a -bis of RFC 4942?

The sections on control plane and routing (2.4, 2.5) are somewhat generic to IPv4 and IPv6; there is very little IPv6-specific information in there. While this isn't bad per se, it pads the length of the document somewhat without much new material.

There are many typos and grammatical errors throughout the document.

Specific comments:

p.3 

"subtle differences between IPv4 and IPv6" - I don't think L2 vs L3 resolution, ND vs ARP, is that subtle?

Do we need to mention NPTv6 here?

p.4

Mention 6renum and the gaps draft it produced (RFC 7010)?

The recommendation to use PI for a larger network implicitly means no NPTv6?

Any value in adding a note about the size of prefix an ISP offers?  (6177, etc)  That affects how the network is configured.

Where is topology discovery / probing mentioned?  Cite RFC 4864?

p.5

I think the phrase in para 1 is "security by obscurity".  I would argue that that can complement other security, but must not be depended upon!

Para 2 - or do both!  

p.6

Section 2.1.3 - and ND cache exhaustion protection

Section 2.1.4 - "Normal" SLAAC no longer relies on EUI-64 from MAC addresses - now RFC 8064 recommends the RFC 7217 version of SLAAC.

This whole section is written in a jumbled order.

There should be a separate section on address accountability - whether it's needed in a given scenario, and where it is, how best to achieve it - there's bits of this scattered around in many places, but it's independent of privacy addressing.

Para 3 - see section 2.1.7.

p.7

first line - you can't always control managed vs unmanaged of course; a university eduroam WiFi is unmanaged, generally, where admin systems probably are managed.  

second para - these are just hints; and for a host not supporting DHCPv6, it gets no address at all.  Perhaps also mention SAVI here.

Section 2.1.6 - Should mentioned DHCPv6 anonymity profile - RFC 7824 and RFC 7844.  RFC 7934 suggests not using DHCPv6 in certain circumstances as a result.  Also RFC 7077 recommends to not issue DHCPv6 addresses sequentially from a small pool.

Section 2.1.7 - note RFC 8273 is designed for shared environments, and isolation is a primary goal; add reference to RFC 7934.

p.8

Perhaps check against text in draft-ietf-6man-rfc6434-bis-08 in section 5.2, and the excessive EH option processing text in 5.3 there.

p.9

Section 2.2.4 - worth adding RFC 8221 and RFC 8247?

Section 2.3 - split out the NS/NA messaging here from ND in general, else you should include SLAAC.  Given you discuss SLAAC later, focus on NS/NA here in its own subsection?

p.10

Spurious DHCP-Shield wording at end of para 2.

Section 2.3.2 - mention ND cache exhaustion

p.11

Rate limit also on ICMP messages?

Perhaps separate out the power drain issue as a threat?  RFC 7772 is relevant here.

The two drafts cited here by thubert and chakrabarti died in 2012 and 2015 respectively?   Maybe RFC 6775 instead?

Section 2.3.3 - or just supply a 'bad' DNS resolver address

p.12

After para 3 emphasise still need RAs in a DHC environment for default router and on-link prefix(es)

p.13

A lot of text on something hardly used?

p.14 - 20 
Lots of generic text applicable to IPv4 too?

p.16

Replace RFC 2460 with RFC 8200?

p.17

There is now draft-ietf-6man-rfc6434-bis-08

p.20

What's required to differentiate logging of different IP versions?

Value in mentioning RFC 8096?

Or YANG modules (as per Section 16 of draft-ietf-6man-rfc6434-bis-08)

p.21

And RESTCONF?

Windows 7?

At bottom, "was usually done in the IPv4 era" -> "is commonly used in IPv4 networking"

p.22

"era" again.

Mention DHCPv6 anonymity profiles - RFC 7844

P.23

Forensics - that's *one* way - can e.g. use a NMS; one that harvests network device data via SNMP; many open source options available.

p.24

Mostly duplicating RFC 7077.

Section 2.6.2.3 - rfer to RFC 5952, or se Sec 2.6.1.1

p.26

Perhaps be consistent with rather than maintain parity?

p.29

6to4...?

p.31

Last para is very handwavey!  Device OSes are more secure these days to work in IPv4 hotspots too?

p.33

A campus enterprise is different - BYOD vs managed, esp. wifi/eduroam, or Science DMZ networks; perhaps mention RFC 7381, esp. sections 2.4, 3.2 and 4.1?

p.35 

last para - better to omit, I think?