Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-opsec-v6-21.txt
Reviewer: Acee Lindem
Review Date: 12/2/2019
IETF LC End Date: Soon
Intended Status:  Informational

Summary: The document contains a lot of useful recommendations and
         references for Operational Security in IPv6 networks. Since
                the document has "Informational" status, none of the text is
                normative.

                While the information content is very good, parts of the
                document are very hard to read and need revision. In general,
                the usage of long clauses connected by semicolons should be
                discouraged and the lists connected in this manner should
                be replaced with complete sentences. I've attached a diffs
                with editorial suggests but didn't try and rewrite all the
                semicolon connected text segments.

                There are also minor issues that need to be addressed.

Major Issues: None

Minor Issues:

    1. Section 1.0 - What do you mean by "updating it with that have been
       standardized since 2007."? It just doesn't read right.

    2. Section 2.1 - IPv4 also allows multiple addresses per interface,
       i.e., secondary addresses. So what is new?

    3. Section 2.1.5 - The whole discussion on how to use Router
       Advertisement (RA) messages lacks enough context to understand.
       Also, expand RA in the first occurrence.

    4. Section 2.2.3 - Expand out NDP since it is not clear that it is
       Neighbor Discovery Protocol from the context. It is expanded later
       in section 2.3.

    5. Section 2.4 - RFC 6192 not only defines the "router control plane"
        but provides much better guidance for control plane filtering than
        section 2.4.1 and 2.4.2.

    6. Section 2.4.1 and 2.4.2 - The ingress ACL should only be applied on
       the packets punted to the RP.

    7. Section 2.4.1 - If OSPFv3 vitual links are used, the destination
       address will not be a link-local address.

    8. Section 2.4.3 - Suggest references for Path MTU Discovery
       and traceroute.

    9. Section 2.5.1 - HMAC MD5 is considered vulnerable.

   10. Section 2.5.2 - What prior section describes the operational
       costs of IPsec?

   11. Section 2.5.3 - Need expansion and reference for RADB.

   12. Section 2.6 - Need expansion and reference for GDPR.

   13. Section 2.7.1 - ACLs are typically per address family so this
       recommendation isn't
       really feasible. Please revise.

   14. Section 2.7.2.6 - Expand MAP-E and MAP-T.

   15. Section 3.1 and 4.1 - Define bogon and provide reference.

   16. Section 3.2 - Bad reference in fourth paragraph.

   17. Section 5 - Suggest references for Teredo tunnels and NAT-PT.
       Also, expand NAT-PT on first occurrence.

Nits: Attached diff with suggested edits.

Thanks,
Acee