Skip to main content

Operational Security Considerations for IPv6 Networks
RFC 9099

Revision differences

Document history

Date Rev. By Action
2021-08-13
27 (System)
Received changes through RFC Editor sync (created alias RFC 9099, changed abstract to 'Knowledge and experience on how to operate IPv4 networks securely is …
Received changes through RFC Editor sync (created alias RFC 9099, changed abstract to 'Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.

This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks.', changed pages to 48, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-08-13, changed IESG state to RFC Published)
2021-08-13
27 (System) RFC published
2021-08-05
27 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9099">AUTH48-DONE</a> from AUTH48
2021-07-22
27 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9099">AUTH48</a>
2021-06-07
27 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-05-14
27 (System) RFC Editor state changed to EDIT
2021-05-14
27 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-05-14
27 (System) Announcement was received by RFC Editor
2021-05-14
27 (System) IANA Action state changed to No IANA Actions from In Progress
2021-05-14
27 (System) IANA Action state changed to In Progress
2021-05-14
27 (System) Removed all action holders (IESG state changed)
2021-05-14
27 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-05-14
27 Amy Vezza IESG has approved the document
2021-05-14
27 Amy Vezza Closed "Approve" ballot
2021-05-14
27 Amy Vezza Ballot approval text was generated
2021-05-14
27 Amy Vezza IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-05-07
27 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-05-07
27 Chittimaneni Kk New version available: draft-ietf-opsec-v6-27.txt
2021-05-07
27 (System) New version approved
2021-05-07
27 (System)
Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo …
Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo <merike@doubleshotsecurity.com>
2021-05-07
27 Chittimaneni Kk Uploaded new revision
2021-04-22
26 (System) Changed action holders to Merike Kaeo, Éric Vyncke, Chittimaneni Kk, Enno Rey (IESG state changed)
2021-04-22
26 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation - Defer
2021-04-22
26 Tim Chown Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list.
2021-04-22
26 Robert Wilton
[Ballot comment]
Hi,

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

I …
[Ballot comment]
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
2021-04-22
26 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-04-22
26 Murray Kucherawy
[Ballot comment]
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 …
[Ballot comment]
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.
2021-04-22
26 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-04-21
26 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-04-21
26 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-04-20
26 Roman Danyliw
[Ballot comment]
** Section 2.1.5.  Per “However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy …
[Ballot comment]
** 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)
2021-04-20
26 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-04-19
26 Benjamin Kaduk
[Ballot comment]
While the guidance of the need to be prepared to postprocess logs to normalize the
string representation of IPv6 addresses (if necessary) is …
[Ballot comment]
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?
2021-04-19
26 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-04-14
26 Erik Kline [Ballot comment]
I think there are still a few nits here and there ("non-legit"?), but I know they'll get cleaned up.  Thanks!
2021-04-14
26 Erik Kline Ballot comment text updated for Erik Kline
2021-04-14
26 Erik Kline [Ballot comment]
I think there are still a few nits here and there ("non-legit"?), but I know they'll get cleaned up.
2021-04-14
26 Erik Kline [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss
2021-04-13
26 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Tim Chown
2021-04-13
26 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Tim Chown
2021-04-09
26 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-04-09
26 Enno Rey New version available: draft-ietf-opsec-v6-26.txt
2021-04-09
26 (System) New version approved
2021-04-09
26 (System)
Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo …
Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo <merike@doubleshotsecurity.com>
2021-04-09
26 Enno Rey Uploaded new revision
2021-04-07
25 Benjamin Kaduk Telechat date has been changed to 2021-04-22 from 2021-04-08
2021-04-07
25 Benjamin Kaduk IESG state changed to IESG Evaluation - Defer from IESG Evaluation
2021-04-07
25 Zaheduzzaman Sarker
[Ballot comment]
I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't  read the …
[Ballot comment]
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.
2021-04-07
25 Zaheduzzaman Sarker Ballot comment text updated for Zaheduzzaman Sarker
2021-04-07
25 Zaheduzzaman Sarker
[Ballot comment]
I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't  read the …
[Ballot comment]
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.
2021-04-07
25 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-04-07
25 Tim Chown Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tim Chown. Sent review to list.
2021-04-06
25 Erik Kline
[Ballot discuss]
[ section 2.1 ]

* "may also force the use of NPTv6" seems like it draws some conclusions.

  Perhaps something like:

  …
[Ballot discuss]
[ section 2.1 ]

* "may also force the use of NPTv6" seems like it draws some conclusions.

  Perhaps something like:

  "may also increase the perceived need for the use of NPTv6"?

[ section 2.2 ]

* "It must also be noted that there is no indication in the IPv6 packet
  as to whether the Next Protocol field points to an extension header
  or to a transport header."

  What is this trying to say?  Is this about what 8200 calls the "Next
  Header" field?  If so, the Next Header field indicates...the next
  header, and whether that's a transport header or not depends on its
  value.

  I guess I read this text as implying that the 8200 standard is somehow
  ambiguous about what NH means, but it's really not.  It's just that
  NH does not always indicate a transport.

[ section 2.3.2.4 ]

* "Only trivial cases [...] should have RA-guard..."

  Only?  This doesn't strike me as being obviously the best recommendation.
  Definitely in trivial cases it should be enabled, but surely it should
  also be enabled even in more complex cases, albeit ones where
  knowledgeable administrators can configure things appropriately
  (vis. the applicability statement in section 1.1)...maybe?
2021-04-06
25 Erik Kline
[Ballot comment]
[ general ]

* There are many uses of ellipses ("...") that probably could be
  tightened up (usually just removed might work). …
[Ballot comment]
[ general ]

* There are many uses of ellipses ("...") that probably could be
  tightened up (usually just removed might work).

[ section 2.1.1 ]

* I think it never hurts to repeat the message that ULA /48s from the
  fd00::/8 space (L=1) MUST be generated with a pseudo-random algorithm,
  per RFC 4193 sections 3.2, 3.2.1, &c.

[ section 2.1.4 ]

* I think the opening sentence might clarify that it's talking about
  stable address assignment for nodes.  On a one-pass reading,
  section 2.1.3 immediately preceding this is discussing router loopback
  addressing, so I found I had routers on the brain when I started 2.1.4.

[ section 2.1.5 ]

* Up to you, but 4941 has been superseded by 8981.

[ section 2.1.6 ]

* "(see Section 2.6.1.5)" -> I think the trailing ")" probably wants to be
  at the end of that sentence; if not, it does not quite make grammatical
  sense (to me).

[ section 2.2.3 ]

* s/ipv6/IPv6/g

[ section 2.3.5 ]

* As an addendum to the final paragraph, it might be noted that such
  filtering can inhibit mDNS (whether or not that's a desirable outcome).

[ section 2.4 ]

* "non-legit": perhaps a bit too casual?

[ section 2.6.1.7 ]

* "as currently collected as in" -> "as currently collected in", I suspect

[ section 2.6.2.1 ]

* There are other motivations for doing forensic analysis that simply
  investigating "malicious activity" (even if this is the most common
  motivation).

  As a concrete proposal, perhaps:

  "At the end of the process, the interface of the host originating,
  or the subscriber identity associated with, the activity in question
  has been determined."

  ...or something

[ section 2.7.2 ]

* "legit": perhaps a bit too casual? "legitimate"?  Or perhaps just
  s/legit and//.

[ section 2.7.2.8 ]

* s/IPV4/IPv4/

* Consider port 123 NTP in your allowlist.  :-)

* "hardly never" -> "hardly ever"

[ section 2.7.3.1 ]

* Does this section belong in this document?  It's all about IPv4, and
  not even particular to IPv4 in the presence of IPv6 -- just IPv4 in
  general.

[ section 2.7.3.2 ]

* "DNSSEC has an impact on DNS64"

  It might also be said that "DNS64 has an impact on DNSSEC", so perhaps
  "DNSSEC and DNS64 negatively interact"?

[ section 4.3 ]

* "and what the respective log retention" ->
  "and the respective log retention", I think
2021-04-06
25 Erik Kline [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline
2021-04-06
25 Lars Eggert
[Ballot comment]
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: …
[Ballot comment]
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
+                                                                    ^^
2021-04-06
25 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-04-05
25 Alvaro Retana
[Ballot comment]

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

a.  The Abstract says that "this document are not applicable to residential user …
[Ballot comment]

(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/
2021-04-05
25 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-04-05
25 Martin Duke
[Ballot comment]
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 …
[Ballot comment]
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.
2021-04-05
25 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-04-02
25 Éric Vyncke [Ballot comment]
As I am an author... BTW, did you notice the publication date?
2021-04-02
25 Éric Vyncke [Ballot Position Update] New position, Recuse, has been recorded for Éric Vyncke
2021-04-01
25 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-04-01
25 Cindy Morgan Placed on agenda for telechat - 2021-04-08
2021-04-01
25 Warren Kumari Ballot has been issued
2021-04-01
25 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2021-04-01
25 Warren Kumari Created "Approve" ballot
2021-04-01
25 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup
2021-04-01
25 Warren Kumari Ballot writeup was changed
2021-04-01
25 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-04-01
25 Éric Vyncke New version available: draft-ietf-opsec-v6-25.txt
2021-04-01
25 (System) New version accepted (logged-in submitter: Éric Vyncke)
2021-04-01
25 Éric Vyncke Uploaded new revision
2021-03-23
24 Acee Lindem Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Acee Lindem. Sent review to list.
2021-03-23
24 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-03-19
24 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-03-19
24 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsec-v6-24, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsec-v6-24, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-03-07
24 Min Ye Request for Last Call review by RTGDIR is assigned to Acee Lindem
2021-03-07
24 Min Ye Request for Last Call review by RTGDIR is assigned to Acee Lindem
2021-03-05
24 Alvaro Retana Requested Last Call review by RTGDIR
2021-03-05
24 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2021-03-05
24 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2021-03-02
24 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-03-23):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Gyan Mishra <hayabusagsm@gmail.com …
The following Last Call announcement was sent out (ends 2021-03-23):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Gyan Mishra <hayabusagsm@gmail.com>, draft-ietf-opsec-v6@ietf.org, hayabusagsm@gmail.com, opsec-chairs@ietf.org, opsec@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-opsec-v6-24.txt> (Operational Security Considerations for IPv6 Networks) to Informational RFC


The IESG has received a request from the Operational Security Capabilities
for IP Network Infrastructure WG (opsec) to consider the following document:
- 'Operational Security Considerations for IPv6 Networks'
  <draft-ietf-opsec-v6-24.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-03-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Knowledge and experience on how to operate IPv4 securely is
  available: whether it is the Internet or an enterprise internal
  network.  However, IPv6 presents some new security challenges.  RFC
  4942
describes the security issues in the protocol, but network
  managers also need a more practical, operations-minded document to
  enumerate advantages and/or disadvantages of certain choices.

  This document analyzes the operational security issues associated
  with several types of network and proposes technical and procedural
  mitigation techniques.  This document is only applicable to managed
  networks, such as enterprise building networks.  The recommendations
  in this document are not applicable to residential user cases, even
  in cases where a Service Provider may be managing the home gateway.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/



No IPR declarations have been submitted directly on this I-D.




2021-03-02
24 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-03-02
24 Cindy Morgan Last call announcement was changed
2021-03-02
24 Cindy Morgan Last call announcement was generated
2021-03-02
24 Warren Kumari Last call was requested
2021-03-02
24 Warren Kumari Second IETF LC - there have been >200 changes, and the last IETF LC was in 2019.
2021-03-02
24 (System) Changed action holders to Warren Kumari (IESG state changed)
2021-03-02
24 Warren Kumari IESG state changed to Last Call Requested from Waiting for Writeup
2021-02-12
24 Éric Vyncke New version available: draft-ietf-opsec-v6-24.txt
2021-02-12
24 (System) New version accepted (logged-in submitter: Éric Vyncke)
2021-02-12
24 Éric Vyncke Uploaded new revision
2021-02-09
23 Éric Vyncke New version available: draft-ietf-opsec-v6-23.txt
2021-02-09
23 (System) New version accepted (logged-in submitter: Éric Vyncke)
2021-02-09
23 Éric Vyncke Uploaded new revision
2021-02-08
22 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-02-08
22 Éric Vyncke New version available: draft-ietf-opsec-v6-22.txt
2021-02-08
22 (System) New version accepted (logged-in submitter: Éric Vyncke)
2021-02-08
22 Éric Vyncke Uploaded new revision
2020-02-10
21 Wesley Eddy Closed request for Last Call review by TSVART with state 'Overtaken by Events'
2019-12-06
21 Tim Chown Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Tim Chown. Sent review to list.
2019-12-03
21 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Acee Lindem.
2019-12-02
21 Erik Kline Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Erik Kline. Sent review to list.
2019-12-02
21 Linda Dunbar Request for Last Call review by SECDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list.
2019-12-02
21 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-11-16
21 Ted Lemon Request for Early review by IOTDIR Completed: On the Right Track. Reviewer: Ted Lemon. Sent review to list.
2019-11-16
21 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Acee Lindem
2019-11-16
21 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Acee Lindem
2019-11-15
21 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2019-11-15
21 Jean Mahoney Request for Last Call review by GENART is assigned to Erik Kline
2019-11-14
21 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-11-14
21 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsec-v6-21, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsec-v6-21, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2019-11-14
21 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2019-11-14
21 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2019-11-14
21 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-11-14
21 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-11-12
21 Wesley Eddy Request for Last Call review by TSVART is assigned to Martin Stiemerling
2019-11-12
21 Wesley Eddy Request for Last Call review by TSVART is assigned to Martin Stiemerling
2019-11-11
21 Alvaro Retana Requested Last Call review by RTGDIR
2019-11-11
21 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-11-11
21 Amy Vezza
The following Last Call announcement was sent out (ends 2019-12-02):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: hayabusagsm@gmail.com, warren@kumari.net, …
The following Last Call announcement was sent out (ends 2019-12-02):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: hayabusagsm@gmail.com, warren@kumari.net, draft-ietf-opsec-v6@ietf.org, opsec@ietf.org, opsec-chairs@ietf.org, Gyan Mishra <hayabusagsm@gmail.com>
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-opsec-v6-21.txt> (Operational Security Considerations for IPv6 Networks) to Informational RFC


The IESG has received a request from the Operational Security Capabilities
for IP Network Infrastructure WG (opsec) to consider the following document:
- 'Operational Security Considerations for IPv6 Networks'
  <draft-ietf-opsec-v6-21.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Knowledge and experience on how to operate IPv4 securely is
  available: whether it is the Internet or an enterprise internal
  network.  However, IPv6 presents some new security challenges.  RFC
  4942
describes the security issues in the protocol but network
  managers also need a more practical, operations-minded document to
  enumerate advantages and/or disadvantages of certain choices.

  This document analyzes the operational security issues in several
  places of a network (enterprises, service providers and residential
  users) and proposes technical and procedural mitigations techniques.
  Some very specific places of a network such as the Internet of Things
  are not discussed in this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-11-11
21 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-11-11
21 Amy Vezza Last call announcement was changed
2019-11-09
21 Warren Kumari Last call was requested
2019-11-09
21 Warren Kumari Ballot approval text was generated
2019-11-09
21 Warren Kumari Ballot writeup was generated
2019-11-09
21 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2019-11-09
21 Warren Kumari Last call announcement was generated
2019-11-09
21 Warren Kumari Changed consensus to Yes from Unknown
2019-11-08
21 Gyan Mishra
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational. It is indicated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document was created to prepare Enterprises, Service Providers and Residential users for security challenges presented with IPv6 deployment by analyzing the operation security issues and proposing technical and procedural mitigation techniques. Operations security considerations are covered in great detail in this document from creating an IPv6 addressing architecture that allows for easily crafted infrastructure access lists to first hop router security, control plane security, securing routing protocols, to external perimeter security best practices guidelines for IPv6 deployments.

Working Group Summary

A number of members in the working group other then the authors expressed support and contributed providing positive feedback to the document and are all listed in the acknowledgement section.  We have working group consensus to publish the document.  Nobody is against publishing the document.

Document Quality

  The authors Eric Vyncke, Kiran Chittimaneni, Merike Kaeo, Enno Rey and the Shepherd carefully reviewed the document and provided a number of comments and ensured the document quality.   

Personnel

  Shepherd is Gyan Mishra.  AD is Warren Kumari.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Shepherd believes the document is ready for publication. AD Warren Kumari identified some grammatical editorial corrections which were made after the Shepherd’s review and was updated in version-21.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No Concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that they are not aware of any IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure has been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

All WG member apart from the authors are supporting this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Ran idnits 2.16.02 and informational reference check found obsolete reference RFC 2460 (Obsoleted by RFC 8200), obsolete reference RFC 3068 (Obsoleted by RFC 7526), and obsolete reference RFC 3627 (Obsoleted by RFC 6547)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

This document includes no request for IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-11-03
21 Chittimaneni Kk New version available: draft-ietf-opsec-v6-21.txt
2019-11-03
21 (System) New version approved
2019-11-03
21 (System)
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk …
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com>
2019-11-03
21 Chittimaneni Kk Uploaded new revision
2019-10-29
20 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Ted Lemon
2019-10-29
20 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Ted Lemon
2019-10-28
20 Éric Vyncke Requested Early review by IOTDIR
2019-10-15
20 Ron Bonica Responsible AD changed to Warren Kumari
2019-10-15
20 Ron Bonica IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2019-10-15
20 Ron Bonica IESG state changed to Publication Requested from I-D Exists
2019-10-15
20 Ron Bonica IESG process started in state Publication Requested
2019-10-15
20 Ron Bonica Notification list changed to Gyan Mishra <hayabusagsm@gmail.com>
2019-10-15
20 Ron Bonica Document shepherd changed to Gyan Mishra
2019-10-12
20 Éric Vyncke New version available: draft-ietf-opsec-v6-20.txt
2019-10-12
20 (System) New version accepted (logged-in submitter: Éric Vyncke)
2019-10-12
20 Éric Vyncke Uploaded new revision
2019-09-23
19 Jen Linkova Tag Revised I-D Needed - Issue raised by WGLC cleared.
2019-09-23
19 Jen Linkova IETF WG state changed to In WG Last Call from WG Document
2019-09-22
19 Éric Vyncke New version available: draft-ietf-opsec-v6-19.txt
2019-09-22
19 (System) New version approved
2019-09-22
19 (System)
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk …
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com>
2019-09-22
19 Éric Vyncke Uploaded new revision
2019-09-21
18 Éric Vyncke New version available: draft-ietf-opsec-v6-18.txt
2019-09-21
18 (System) New version approved
2019-09-21
18 (System)
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk …
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com>
2019-09-21
18 Éric Vyncke Uploaded new revision
2019-07-05
17 Enno Rey New version available: draft-ietf-opsec-v6-17.txt
2019-07-05
17 (System) New version approved
2019-07-05
17 (System)
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk …
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com>
2019-07-05
17 Enno Rey Uploaded new revision
2019-03-11
16 Éric Vyncke New version available: draft-ietf-opsec-v6-16.txt
2019-03-11
16 (System) New version approved
2019-03-11
16 (System)
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk …
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com>
2019-03-11
16 Éric Vyncke Uploaded new revision
2019-03-09
15 Éric Vyncke New version available: draft-ietf-opsec-v6-15.txt
2019-03-09
15 (System) New version approved
2019-03-09
15 (System)
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk …
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com>
2019-03-09
15 Éric Vyncke Uploaded new revision
2018-10-22
14 Éric Vyncke New version available: draft-ietf-opsec-v6-14.txt
2018-10-22
14 (System) New version approved
2018-10-22
14 (System)
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, …
Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com>
2018-10-22
14 Éric Vyncke Uploaded new revision
2018-09-02
13 (System) Document has expired
2018-07-02
13 Tim Chown Request for Early review by OPSDIR Completed: Not Ready. Reviewer: Tim Chown. Sent review to list.
2018-03-26
13 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Tim Chown
2018-03-26
13 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Tim Chown
2018-03-26
13 Gunter Van de Velde Requested Early review by OPSDIR
2018-03-21
13 Éric Vyncke Added to session: IETF-101: opsec  Wed-1520
2018-03-01
13 Éric Vyncke New version available: draft-ietf-opsec-v6-13.txt
2018-03-01
13 (System) New version approved
2018-03-01
13 (System) Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com>
2018-03-01
13 Éric Vyncke Uploaded new revision
2017-10-30
12 Éric Vyncke New version available: draft-ietf-opsec-v6-12.txt
2017-10-30
12 (System) New version approved
2017-10-30
12 (System) Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>
2017-10-30
12 Éric Vyncke Uploaded new revision
2017-10-13
11 (System) Document has expired
2017-09-29
11 Gunter Van de Velde Update of the document was suggested by authors during IETF99 OPSEC WG meeting. Waiting for Update.
2017-09-29
11 Gunter Van de Velde Tag Revised I-D Needed - Issue raised by WGLC set.
2017-09-29
11 Gunter Van de Velde IETF WG state changed to WG Document from In WG Last Call
2017-07-18
11 Éric Vyncke Added to session: IETF-99: opsec  Wed-1330
2017-04-12
11 Gunter Van de Velde WG last call running for 2 weeks and expected to end on 26 April is initiated on 12 April 2017
2017-04-12
11 Gunter Van de Velde IETF WG state changed to In WG Last Call from WG Document
2017-04-12
11 Gunter Van de Velde Intended Status changed to Informational from None
2017-04-11
11 Éric Vyncke New version available: draft-ietf-opsec-v6-11.txt
2017-04-11
11 (System) New version approved
2017-04-11
11 (System) Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com>
2017-04-11
11 Éric Vyncke Uploaded new revision
2017-03-13
10 Éric Vyncke New version available: draft-ietf-opsec-v6-10.txt
2017-03-13
10 (System) New version approved
2017-03-13
10 (System) Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com>
2017-03-13
10 Éric Vyncke Uploaded new revision
2017-01-08
09 (System) Document has expired
2016-07-07
09 Éric Vyncke New version available: draft-ietf-opsec-v6-09.txt
2016-03-21
08 Éric Vyncke New version available: draft-ietf-opsec-v6-08.txt
2015-09-09
07 Éric Vyncke New version available: draft-ietf-opsec-v6-07.txt
2015-03-09
06 Éric Vyncke New version available: draft-ietf-opsec-v6-06.txt
2014-10-27
05 Éric Vyncke New version available: draft-ietf-opsec-v6-05.txt
2013-10-21
04 Chittimaneni Kk New version available: draft-ietf-opsec-v6-04.txt
2013-07-15
03 Éric Vyncke New version available: draft-ietf-opsec-v6-03.txt
2013-02-24
02 Chittimaneni Kk New version available: draft-ietf-opsec-v6-02.txt
2012-11-08
01 Chittimaneni Kk New version available: draft-ietf-opsec-v6-01.txt
2012-09-21
00 Merike Kaeo New version available: draft-ietf-opsec-v6-00.txt