Operational Security Considerations for IPv6 Networks
draft-ietf-opsec-v6-27

I think there are still a few nits here and there ("non-legit"?), but I know they'll get cleaned up.  Thanks!

Thanks for this work.  It's a useful document to have.  I don't have much to add that my fellow ADs have not already mentioned.

One procedural nit: The shepherd writeup lacks an answer to the question "Why is this the proper type of RFC?"  (I realize "Informational" is the right answer here.  I would just prefer it if shepherds answered it anyway.)  It is also almost 18 months old.

** Section 2.1.5.  Per “However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used.”, it might be worth acknowledging that even if these are managed network, the end user and the operators may be at odds on what privacy properties are important.

** Section 2.2.1.  Per “A firewall or edge device should be used to enforce the recommended order and the maximum occurrences of extension headers”, does enforcement mean dropping the packets?

** Section 2.3.2.  Per “Network operators should be aware that RA-Guard and SAVI do not work or could even be harmful in specific network configurations”, please provide a more details, ideally through citation.

** Section 2.3.2, “Enabling RA-Guard by default in … enterprise campus networks …”, what’s the key property of “enterprise campus network”.  The introduction already roughly says this whole document applies to managed networks.

** Section 2.5.2.  Reading this section, the specific recommended practices weren’t clear.

** Section 2.6.  It wasn’t clear how comprehensive this list of logs was intended to be.  A few additional thoughts include:
-- DHCPv6 logs 
-- firewall ACL logs
-- authentication server logs 
-- NEA-like policy enforcement at the time of connection
-- vpn/remote access logs
-- passive DNS from port 53 traffic
-- full packet capture
-- active network and service scanning/audit information

** Section 2.6.1.2.  The recommended fields in this section are helpful, but only in the context of the rest of the five-tuple + timing + interface + vlan + select layer 4 information for each flow.  These open IPFIX information elements aren't mentioned.

** Section 2.6.2.1.  Per “The forensic use case is when the network operator must locate an IPv6 address that was present in the network at a certain time or is currently in the network”, isn’t this use case more precisely an attempt to link an IP address to (a) a specific port in the case of a wired network; (b) a access point (or base station, etc.) in the case of wireless; or (c) an external IP address in the case of a VPN connection?

** Section 2.6.2.1.  Additional techniques/suggestions to consider:
-- Using the IPAM system noted in Section 2.1 or any other inventory system to provide hints in the about where an IP address might belong in the topology.  

-- A reminder that mapping between and IP+port or MAC+IP might not have been the same one as during the time of the event of interest

-- there is discussion about identifying subscribers for an ISP but not in normal enterprise network scenario through SSO logs (if port level security doesn’t exist)

** Section 2.6.2.2.  Per “The first technique is to use the IPFIX information and extract the list of all IPv6 source addresses to find all of the IPv6 nodes that sent packets through the router”.  This framing is mixing the technique with a particular logging format.  I would recommend being clear that the technique is question is passive inspection of network talkers.  There a several ways to get that: a properly configured IPFIX feed from a router, but also from any number of network analysis tools on a span port or a tap.

** Section 2.7.1.  In addition to the two listed practices at the IPv4 edge, I would recommend adding the common practice of application specific flow inspection.

** Section 2.8.  The intent of this section isn’t clear as all of the described practices are equally true of v4.  A few missing hardening practices include:

-- applying firmware, OS and application patches/upgrades to the devices in a timely manner.

-- using multi-factor credentials to authenticate to devices

** Section 3.  This section is titled “Enterprises Specific …”, how is an “enterprise” different than a “managed network” called out in the applicability statement?

** Section 3.1.  This list is helpful.  Is text here and Section 2.5.4 needed?  For example, does one need to say both “discard _packets_ from bogons” (this section) and “discard _routes_ from bogons” (Section 2.5.4)

I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't  read the long list of  referenced documents :-)). I think the collected recommendations in one place will be very helpful.

Some comments - 

  *  The abstract says - "The recommendations in this document are not applicable to residential user cases". However, later on in section 1.1 it says - "This covers Service Provider (SP), enterprise networks and some knowledgeable-home-user-managed residential network." Furthermore in section 5, it recommends configurations for residential users.    May be I am not getting the distinction among residential user cases, managed residential network and residential users correct but I think further clarification is needed on what is written in thee abstract and what is in the rest of the document.

  * I noted that section 2.3.4 refers to 3GPP 4G terminologies while describing the case. If this section is not supposed to restricted to certain generations of 3GPP technologies then I would recommend to update the section with 5G terminologies as well.

  * In section 2.6 there is an ask for the network operators to log "of all applications using the network (including user space and kernel space) when available (for example web servers)". How realistic is this? I hardly see the web servers sharing logging files with network operators ( I would be happy to be corrected here ). I am also missing the discussion on -- if not available how much this affects the forensic research in the event of security incident and abnormal behavior.

(1) The applicability statement in §1.1 is confusing to me.

a.  The Abstract says that "this document are not applicable to residential user cases", but that seems not to be true because this section says that the contents do apply to "some knowledgeable-home-user-managed residential network[s]", and §5 is specific to residential users.

b. "This applicability statement especially applies to Section 2.3 and Section 2.5.4."  Those two sections represent a small part of the document; what about the rest?   It makes sense to me for the applicability statement to cover most of the document.  

c. "For example, an exception to the generic recommendations of this document is when a residential or enterprise network is multi-homed."  I'm not sure if this sentence is an example of the previous one (above) or if "for example" is out of place.


(2) §5 mentions "early 2020" -- I assume that the statement is still true now.


(3) It caught my attention that there's only one Normative Reference (besides rfc8200, of course).  Why?  What is special about the IPFIX registry?

It seems that an argument could be made to the fact that to secure OSPFv3, for example, an understanding of the protocol is necessary.  This argument could be extended to other protocols or mechanisms, including IPv6-specific technology: ND, the addressing architecture, etc.  Consider the classification of the references in light of [1].

[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

While the guidance of the need to be prepared to postprocess logs to normalize the
string representation of IPv6 addresses (if necessary) is good, I am not
sure that the specific perl code provided in Section 2.6.1.1 is useful
to include.  In addition to my specific comments in the
section-by-section comments, it is in a sense a very blunt instrument
that assumes whitespace-separated records and blindly tries to treat
every word as an IPv6 address with no regard for the message/record
format.  This can easily induce collateral damage, and it seems that in
most cases it will be possible to use a much more targeted
normalization procedure that takes into account knowledge of the message
structure.  So my recommendation would be to just remove the specific
example perl script.

Section 2.1.1

   Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
   where interfaces are not globally reachable, despite being routed
   within a domain.  They formally have global scope, but [RFC4193]
   specifies that they must be filtered at domain boundaries.  [...]

I'm not seeing something quite so strong in RFC 4193.  It has a note
that "[i]f BGP is being used at the site border with an ISP, the default
BDP configuration must filter out [...]", but that is only a default,
and the guidance about non-BGP mechanisms is not even this strong.

Section 2.1.2

Is there a reference for "the ping-pong attack" (where the use of the
definite article implies there is a specific well-known attack)?

Section 2.1.4

   Stable addresses also allow easy enforcement of a security policy at
   the perimeter based on IPv6 addresses.  [RFC8520] is a mechanism
   where the perimeter defense can retrieve security policy template
   based on the type of internal device.

IIUC when using MUD there is a need to have a mapping from IP address to
type of device (or MUD file), which doesn't seem to be mentioned by the
text here.

Section 2.1.7

Please call out the privacy considerations (already discussed in RFC
8273) of using a /64 per host.

Section 2.2.3

   If those requirements are not met, stateless filtering could be
   bypassed by a hostile party.  [RFC6980] applies a stricter rule to
   Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented
   NDP packets.  [...]

As is clarified later in Section 2.3.2.1, fragmented Certification Path
Advertisement messages are not required to be dropped.  In my opinion we
should provide a consistent treatment of the topic across all locations
we mention it.

Section 2.2.4

   The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP
   [RFC4303]) are required if IPsec is to be utilized for network level
   security.  But IPsec is no longer required for normal IPv6 nodes: in

I think at this point AH is in practice deprecated, because ESP with
NULL cipher can perform the same role.

Also, is there any further commentary about IPsec in general that is
appropriate for this document?

Section 2.3.2.3

   Isolating hosts for the NDP traffic can be done by using a /64 per
   host, refer to Section 2.1.7, as NDP is only relevant within a /64
   on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism.

I recall some previous discussion about whether the prefix/IID boundary
must fall at exactly 64 bits, but I trust the authors to have a better
handle on this topic than I do.

Section 2.6

   Please note that there are privacy issues or regulations related to
   how these logs are collected, stored, and safely discarded.

Also to how they are *used*, e.g., the "correlation" behavior listed
below.

Section 2.6.1.1

   my (@words, $word, $binary_address) ;

@words is unused.

       $binary_address = inet_pton AF_INET6, $word ;
       if ($binary_address) {
         print inet_ntop AF_INET6, $binary_address ;

I'd strongly recommend using parentheses for at least the function calls
inet_pton and inet_ntop.

I also get warnings trying to run this code:

Subroutine main::pack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66.
 at ... line 5.
Subroutine main::unpack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66.
 at ... line 5.
Subroutine main::sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66.

Section 2.6.1.4

   This is an important source of information because it is trivial (on
   a switch not using the SAVI [RFC7039] algorithm) to defeat the
   mapping between data-link layer address and IPv6 address.  Let us
   rephrase the previous statement: having access to the current and
   past content of the neighbor cache has a paramount value for the
   forensic and audit trail.

And if it's interesting to the operator it's interesting to other
parties as well; in certain threat models this information could itself
be a target.

Section 2.7.2

   o  reflection attack: another specific use case of tunnel injection
      where the attacker injects packets with an IPv4 destination
      address not matching the IPv6 address causing the first tunnel
      endpoint to re-encapsulate the packet to the destination... Hence,
      the final IPv4 destination will not see the original IPv4 address
      but only the IPv4 address of the relay router.

Is it possible at least sometimes to configure the tunnel endpoints to
drop traffic rather than "hairpin" it back out?

   To mitigate the bypassing of security policies, it is recommended to
   block all default configuration tunnels by denying IPv4 packets
   matching:
   [...]

This is not something I'd expect in a general-purpose recommendation, so
I wonder if a reminder (and backreference) of the Applicability
Statement in Section 1.1 would help.

   o  UDP protocol 3544: this will block the default encapsulation of
      Teredo (Section 2.7.2.8) tunnels.

(really a nit, but up here since it's important) s/protocol/port/.

Section 2.7.2.2

   Special care must be taken to avoid a looping attack by implementing
   the measures of [RFC6324] and [RFC6964].

I see a section 3.6 in RFC 6964 entitled "Loop Avoidance"; are we
intending to refer to just that guidance or the entire document?  (I
could easily imagine that there are other parts of the document that
have relevance for this topic, but did not read closely enough to
attempt to make my own determination of that.)

Section 2.7.2.3

   While 6rd tunnels share the same encapsulation as 6to4 tunnels
   (Section 2.7.2.7), they are designed to be used within a single SP
   domain, in other words, they are deployed in a more constrained
   environment than 6to4 tunnels and have few security issues other than
   lack of confidentiality.  [...]

My current guess is that the "more constrained environment" is intended
to refer to a restricted or restricted-access environment that is
assumed to not have any potential for (e.g.) traffic injection.  But if
lack of confidentiality remains an issue, it seems that the risk of an
attacker or compromised device on the path is considered in scope, so
I'm not sure how injection and the other attacks would be impossible in
that case.  I think we need some more clarity on what this sentence is
intended to say.

Section 2.7.2.4

   Organizations using MPLS in their core can also use 6PE [RFC4798] and
   6VPE [RFC4659] to enable IPv6 access over MPLS.  As 6PE and 6VPE are
   really similar to BGP/MPLS IP VPNs described in [RFC4364], the
   security properties of these networks are also similar to those
   described in [RFC4381].  They rely on:

(RFC 4381 is, of course, an ISE doc, so we are in some sense endorsing
its content by referencing it in this way.)

   LDPv6 itself does not induce new risks, see also [RFC7552].

Should we say which security considerations continue to apply (i.e., the
LDPv4 ones)?

Section 2.7.2.8

   Internet.  While host policies can be deployed to block Teredo in an
   IPv4-only network in order to avoid this firewall bypass, it would be
   enough to block all UDP outbound traffic at the IPv4 firewall if
   deemed possible (of course, at least port 53 should be left open for
   DNS traffic, port 123 for NTP, port 443 for QUIC, port 500 for IKE,
   port 3478 for STUN, i.e., filter judiciously).

I find it hard to accept as useful a recommendation to "block all UDP
outbound traffic if deemeed possible" followed by a necessarily
incomplete list of exceptions.  Perhaps it is enough to note that when
outbound UDP is blocked, outbound Teredo is likewise blocked, and keep
the list of common UDP services.

Section 2.7.3.2

   The Security Consideration sections of [RFC6146] and [RFC6147] list
   the comprehensive issues.  A specific issue with the use of NAT64 is
   that it will interfere with most IPsec deployments unless UDP
   encapsulation is used.  DNSSEC and DNS64 negatively interact, see
   section 3.1 of [RFC7050].

My reading of Section 3.1 of RFC 7050 is more about using DNSSEC to
secure the discovery of Pref64::/n than about the negative interactions
between DNSSEC and DNS64.  The latter seems to be covered in the
(already referenced) security considerations section of RFC 6147,
though.

I might say something stronger than just "negatively interact", too.

Section 2.8

   o  Use cryptographically protected protocols for device management if
      possible (SCP, SNMPv3, SSH, TLS, etc.)

Since these are already only guidelines, I would strike "if possible".

Section 3.1

In light of RFC 2804, I wonder whether more of a disclaimer is
appropriate when referencing RFC 3924 and otherwise discussing lawful
intercept.

   o  Filter specific extension headers by accepting only the required
      ones (permit list approach) such as ESP, AH (not forgetting the
      required transport layers: ICMP, TCP, UDP, ...), where possible at
      the edge and possibly inside the perimeter; see also
      [I-D.ietf-opsec-ipv6-eh-filtering]

[This seems to be another place where general-purpose and
managed-network-specific advice diverge, and reiteration of the
applicability statement might be in order.]

   o  Implement appropriate rate-limiters and control-plane policers

Is there a reference to give guidance on what is "appropriate"?


NITS

Section 1

   This document complements [RFC4942] by listing all security issues

I'm always a little wary of "all" or "comprehensive" when covering
security issues; it's hard to be sure that we really have captured
everything.

Section 2.1

   A common question is whether companies should use Provider
   Independent (PI) vs. Provider Allocated (PA) space [RFC7381], but

The terminology used in 7381 seems to be about requesting address space
from a LIR/RIR/NIR vs using "Provider-Aggregated" address space, so just
searching for the terms listed here doesn't find much useful discussion.
Perhaps linking to specifically Section 2.6 thereof would help.

Section 2.1.4

   While in some environments obfuscating addresses could be considered
   an added benefit, it does not preclude enforcement of perimeter rules
   and that stable addresses follow some logical allocation scheme for
   ease of operation (as simplicity always helps security).

This sentence might be a bit long for a paragraph.  I'd suggest breaking
after "enforcement of perimeter rules" and continuing with "It also does
not preclude stable addresses from following [...]" (assuming I'm even
parsing the current version correctly).

Section 2.1.5

   Historically, stateless address autoconfiguration (SLAAC) makes up
   the globally unique IPv6 address based on an automatically generated

Is "makes up" accurate for something that was only historically the
recommended practice but no longer is?

   Disabling SLAAC and privacy extension addresses can be done for most
   operating systems by sending RA messages with a hint to get addresses
   via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting
   all A-bits in all prefix information options.  [...]

I think s/but/and/?

   However, in scenarios where anonymity is a strong desire (protecting
   user privacy is more important than user attribution), privacy
   extension addresses should be used.  When [RFC8064] is available, the

RFC 8064 is a "recommendation" (and seems to defer to RFC 7217 for the
actual computation), so maybe we are concerned about the "mechanisms
recommended by RFC 8064" being available?

Section 2.2.1

   A firewall or edge device should be used to enforce the recommended
   order and the maximum occurrences of extension headers.

If it's only a recommended order, why do we want to strictly enforce it?
;)

Section 2.3.1

   o  Using a /127 on point-to-point link per [RFC6164].

either "a point-to-point link" or "links"

   o  Using link-local addresses only on links where there are only
      routers, see [RFC7404]

Is the first "only" correct?

Section 2.3.2.3

   A more drastic technique to prevent all NDP attacks is based on
   isolation of all hosts with specific configurations.  Hosts (i.e.,
   all nodes that are not routers) are unable to send data-link layer

I suggest starting the second sentence with something like "When this
technique is used" or "In such a scenario", since (AFAICT) the statement
is not true in the general case.

Section 2.3.2.4

   hosts.  This recommendation also applies when DHCPv6 is used as RA
   messages are used to discover the default router(s) and for on-link

comma after "is used".

   in Section 2.2.3.  The generated log should also be analyzed to
   identify and act on violations.  Network operators should be aware

What generated log?  This document does not have a prior mention of
logging.

   Enabling RA-Guard by default in Wi-Fi networks or enterprise campus
   networks should be strongly considered unless specific use cases such
   as the presence of devices Homenet devices emitting router
   advertisements preclude this.

spurious (first?) "devices".

Section 2.3.3

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
   in [RFC8415], enables DHCP servers to pass configuration parameters
   such as IPv6 network addresses and other configuration information to
   IPv6 nodes such as a recursive DNS server.  DHCP plays an important

"such as a recursive DNS server" should come before "to IPv6 nodes".

   The two most common threats to DHCP clients come from malicious
   (a.k.a., rogue) or unintentionally misconfigured DHCP servers.  A
   malicious DHCP server is established with the intent of providing

I'd suggest a transition phrase, such as "in these scenarios", as the
current phrasing could be misread as an authoritative statement of the
only reason why one might maliciously set up a DHCP server.

   incorrect configuration information to the clients to cause a denial-
   of-service attack or to mount on path attack.  While unintentional, a

"an on-path attack".

Section 2.3.5

   [RFC7772], [RFC6775] (for specific wireless networks) discuss methods
   to rate-limit RAs and other ND messages on wireless networks in order
   to address this issue.

s/,/and/?

Section 2.4

   [RFC6192] defines the router control plane and provides detailed
   guidance to secure it for IPv4 and IPv6 networks.  This definition is
   repeated here for the reader's convenience.  Please note that the

There is some churn in the diff, added commas and a few removed words.
If possible, it might be worth using some formatting to indicate that
only the one paragraph is quoted.

   its input queue with more packets than it can process.  The control
   plane processor is then unable to process valid control packets and
   the router can lose OSPF or BGP adjacencies which can cause a severe
   network disruption.

Why do we privilege OSPF as the only IGP mentioned?  (Also later on.)

Section 2.4.2

   o  Drop packets destined to the routers except those belonging to
      protocols which are used (for example, permit TCP 22 and drop all
      others when only SSH is used);

(Isn't NETCONF on port 22 as well, given its use of ssh as substrate?)

Section 2.4.3

   o  processing of the hop-by-hop options header, new implementations
      follow section 4.3 of [RFC8200] where this processing is optional;

comma splice.

   On some routers, not everything can be done by the specialized data
   plane hardware which requires some packets to be 'punted' to the

It's nice that we pseudo-define "punted" but we've used the term earlier
already.

   packet exceptions.  The only protection for the RP is to rate-limit
   those packet exceptions that are forwarded to the RP, this means that
   some data plane packets will be dropped without an ICMP message sent
   to the source which may delay Path MTU discovery and cause drops.

comma splice

Section 2.5.2

   [RFC7166] changes OSPFv3 reliance on IPsec by appending an
   authentication trailer to the end of the OSPFv3 packets; it does not

I suggest "adds an authentication mechanism for OSPFv3 other than
IPsec"; the phrasing about "reliance" is a bit surprising since (I
assume) many sites run without any cryptographic protection at all.

   specifically authenticate the specific originator of an OSPFv3

Maybe the specifically/specific are redundant and one could be dropped?

   With all authentication mechanisms, operators should confirm that
   implementations can support re-keying mechanisms that do not cause
   outages.  There have been instances where any re-keying causes

BCP 107 might be a good reference here for re-keying concepts.

   outages and therefore, the tradeoff between utilizing this
   functionality needs to be weighed against the protection it provides.

This phrasing seems to imply that even now there is a tradeoff to weigh
between using cryptographic protection and risk of outage.  I'd suggest
rewording to use the past tense and qualify that it is only the
scenarios where re-keying requires outage that has such a pronounced
tradeoff.  (To be clear, there is still a tradeoff for using any
cryptographic protection, but that is more along the lines of "fail-safe
vs fail-open".)

Section 2.5.3

   Many routing protocols support the use of cryptography to protect the
   routing updates, the use of this protection is recommended; [RFC8177]
   is a YANG data model key chains including the renewal.

"YANG data model for key chains that includes re-keying functionality".

Section 2.5.4

   o  Configure ingress route filters that validate route origin, prefix
      ownership, etc. through the use of various routing databases,
      e.g., [RADB].  There is additional work being done in this area to
      formally validate the origin ASs of BGP announcements in
      [RFC8210].

To what extent is this still "work being done" vs a realized result,
protocol-wise?

Section 2.6.1.3

   o  interfaces-state/interface/statistics from ietf-
      interfaces@2018-02-20.yang [RFC8343] which contains counters for
      interface .

I can't tell if this sentence ended prematurely or not.

Section 2.6.1.4

   The neighbor cache of routers contains all mappings between IPv6
   addresses and data-link layer addresses.  There are multiple ways to

I think we've also used the terms "physical layer", "link-layer address",
and "MAC address" already as well.

   o  using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to
      collect the operational state of the neighbor cache;

Since RFC 8040 is RESTCONF this line doesn't scan very well.

Section 2.6.1.5

   address, some being data-link layer address prepended with time
   information, or even an opaque number which is useless for
   operational security.  Moreover, when the DUID is based on the data-

I suggest "that requires correlation with another data source to be
usable for operational security".

Section 2.6.1.6

   used by the user.  This technique can be used notably for Wi-Fi
   networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X
   [IEEE-802.1X] wired interface on an Ethernet switch.

Wi-Fi networks are not 802.1X wired interfaces (last I checked), so
s/other//.

Section 2.6.2.1

   a subscriber via the RADIUS log.  Alternatively, the Forwarding
   Information Base of the CMTS or BNG indicates the CPE of the

Please expand CMTS and BNG.

Section 2.6.2.3

   In order to do correlation in IPv6-related logs, it is advised to
   have all logs in a format with only canonical IPv6 addresses
   [RFC5952].  Then, the neighbor cache current (or historical) data set

(We made this recommendation already earlier.)

Section 2.7.2

   There are many tunnels used for specific use cases.  Except when
   protected by IPsec [RFC4301], all those tunnels have a couple of
   security issues as described in RFC 6169 [RFC6169];

s/couple/number/

   o  bypassing security policy: if a firewall or an IPS is on the path

Expand IPS.

Section 2.7.2.1

   tunnel injection are still possible.  Therefore, the use of IPsec
   [RFC4301] in transport mode and protecting the encapsulated IPv4
   packets is recommended for those tunnels.  Alternatively, IPsec in

s/and protecting/to protect/

Section 2.7.2.4

   o  Hiding the IPv4 core, hence removing all attacks against
      P-routers;

This is the only place we use the term "P-router", so we might just
expand out the definition to avoid the jargon.

Section 2.7.2.6

                                                    As MAP has a
   predictable IPv4 address and port mapping, the audit logs are easier
   to manage.

Easier to manage than what?

Section 2.7.2.8

   Teredo is now hardly never used and no longer enabled by default in

s/hardly never/hardly ever/

   most environments, so, it is less of a threat, however, special
   consideration must be taken in case of devices with older or non-

s/case of/cases when/

Section 3.1

   o  Filter internal-use IPv6 addresses at the perimeter this will also
      mitigate the vulnerabilities listed in [RFC7359]

Some kind of punctuation (sentence break; semicolon) after "perimeter".

   o  Implement ingress and egress anti-spoofing in the forwarding and
      control planes, see [RFC2827] and [RFC3704]

Using a BCP 84 reference would also pick up the updates in RFC 8704.

                           It is recommended to filter at Internet
   connection(s) packets having a source or destination address
   belonging to the site internal prefix(es); this should be done for
   ingress and egress traffic.

Do we want to say "respectively" here?  (Filtering any traffic with
source or destination belonging to internal prefixes would seem to
result in the site being an island, disconnected from the internet...)

Section 5

   Some residential users have less experience and knowledge about
   security or networking.  [...]

Less than who/what?

Section 2.3.1, paragraph 6, comment:
>    o  Tuning of NDP process (where supported).

Tuning in which way?

Section 2.7.2, paragraph 2, comment:
>    There are many tunnels used for specific use cases.  Except when
>    protected by IPsec [RFC4301], all those tunnels have a couple of
>    security issues as described in RFC 6169 [RFC6169];

IPsec is not the only security mechanism that will protect tunnels, most
tunnel encryption mechanisms would.

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions. 

Section 2.5.3, paragraph 4, nit:
>    Many routing protocols support the use of cryptography to protect the
>    routing updates, the use of this protection is recommended; [RFC8177]
>    is a YANG data model key chains including the renewal.
> 

I can't parse the part after the semicolon.

Section 2.6.2.2, paragraph 9, nit:
Might also want to mention http://www.entropy-ip.com/ and similar tools.

Section 2.2.3, paragraph 3, nit:
-       not contain the entire ipv6 header chain (including the transport-
-                              ^^
+       not contain the entire IPv6 header chain (including the transport-
+                              ^^

Section 2.2.3, paragraph 4, nit:
-       contain the entire ipv6 header chain (including the transport-
-                          ^^
+       contain the entire IPv6 header chain (including the transport-
+                          ^^

Section 2.2.4, paragraph 2, nit:
-    the updated IPv6 Nodes Requirement standard [RFC8504] IPsec is a
+    the updated IPv6 Nodes Requirement standard [RFC8504], IPsec is a
+                                                         +

Section 2.3, paragraph 2, nit:
-    operations such as discovering other nodes on the link, resolving
+    operations, such as discovering other nodes on the link, resolving
+              +

Section 2.3, paragraph 2, nit:
-    secured, NDP is vulnerable to various attacks such as router/neighbor
+    secured, NDP is vulnerable to various attacks, such as router/neighbor
+                                                 +

Section 2.3, paragraph 2, nit:
-    documented in IPv6 ND Trust Models and Threats [RFC3756] and in

Section 2.3.1, paragraph 2, nit:
-    Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial
+    The Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial
+   ++++

Section 2.3.1, paragraph 6, nit:
-    o  Using /127 on point-to-point link per [RFC6164].
+    o  Using a /127 on a point-to-point link, per [RFC6164].
+             ++       ++                    +

Section 2.3.2.3, paragraph 2, nit:
-    on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism.
+    on-link prefix; 3GPP (see Section 2.3.4) uses a similar mechanism.
+                         +++++             +

Section 2.3.3, paragraph 2, nit:
-    Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
-    in [RFC8415], enables DHCP servers to pass configuration parameters
-    such as IPv6 network addresses and other configuration information to
-    IPv6 nodes such as a hostile recursive DNS server.  DHCP plays an
+    The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
+   ++++
+    in [RFC8415], enables DHCP servers to pass configuration parameters,
+                                                                       +
+    such as IPv6 network addresses and other configuration information, to
+                                                                      +
+    IPv6 nodes, such as a hostile recursive DNS server.  DHCP plays an
+              +

Section 2.3.3, paragraph 3, nit:
-    of-service attack or to mount on path attack.  While unintentional, a
-                                    ^
+    of-service attack or to mount an on-path attack.  While unintentional, a
+                                  +++  ^

Section 2.3.4, paragraph 2, nit:
-    address.  This implies there can only be an end host (the mobile
-                                             ^
+    address.  This implies there can only be one end host (the mobile
+                                             ^ +

Section 2.3.4, paragraph 2, nit:
-    address built by the mobile host.  The GGSN/PGW always provides an
-            ^^^^
+    address generated by the mobile host.  The GGSN/PGW always provides an
+            ^^^^^^ ++

Section 2.3.4, paragraph 4, nit:
-    link model, NDP on it and the address configuration details.  In some
-                   ------
+    link model, NDP and the address configuration details.  In some

Section 2.5, paragraph 8, nit:
-    interface where it is required.
+    interfaces where it is required.
+             +

Section 2.5.4, paragraph 2, nit:
-    pertain to edge route filtering vs internal route filtering.  At a
+    pertain to edge route filtering vs. internal route filtering.  At a
+                                      +

Section 2.6.1.5, paragraph 2, nit:
-    clients.  It is indeed quite similar to DHCP for IPv4 so it can be
+    clients.  It is indeed quite similar to DHCP for IPv4, so it can be
+                                                         +

Section 2.6.1.5, paragraph 3, nit:
-    It is not so easy in the IPv6 networks because not all nodes will use
-                         ----
+    It is not so easy in IPv6 networks, because not all nodes will use
+                                      +

Section 2.7.3.1, paragraph 2, nit:
-    Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT
-                                                   ^^^
+    Carrier-Grade NAT (CGN), also called NAT444 CGN, Large Scale NAT
+                                                   ^

Section 4.3, paragraph 3, nit:
-    (e.g., his/her PPP session, physical line, or CPE MAC address).  With
-                                                                     ^^^^
+    (e.g., his/her PPP session, physical line, or CPE MAC address).  In
+                                                                     ^^

I haven't gone through the dozens of references to verify the claims about them, so I'm trusting the WG and ADs here...

In Sec 2.3.2.4, RA-Guard and SAVI are recommended, but then in the same paragraph it says that "only trivial cases" should enable it by default. I can't reconcile these two statements.

Hi,

I would like to thank the authors for persevering with this document that has been in development for a long time.

I was also like to thank Tim for his detailed OPSDIR reviews.

I found the document informative to read, but in terms of the technical content, I don't have anything further to add beyond the other reviews comments.

My overriding impression from reading this document (both due to the text and large number of references) is that deploying IPv6 seems to be very complex.  I don't know how that complexity compares to v4 deployments.   In several cases, this document alludes to different alternatives to how particular IPv6 features may be deployed, and the operational security considerations as they pertain to those choices.  Not for this document, but it makes me wonder whether some useful future work in this area might be some BCP recommendations for how IPv6 should be deployed in particular types of networks .. although it is entirely possible that ship has already sailed, or there is too much variation on how v6 is being deployed to make such a recommendation.

Regards,
Rob