< draft-ietf-opsec-v6-26.txt   draft-ietf-opsec-v6-27.txt >
OPSEC E. Vyncke OPSEC E. Vyncke
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational K. Chittimaneni Intended status: Informational K. Chittimaneni
Expires: October 11, 2021 WeWork Expires: November 7, 2021 Square
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
E. Rey E. Rey
ERNW ERNW
April 9, 2021 May 6, 2021
Operational Security Considerations for IPv6 Networks Operational Security Considerations for IPv6 Networks
draft-ietf-opsec-v6-26 draft-ietf-opsec-v6-27
Abstract Abstract
Knowledge and experience on how to operate IPv4 networks securely is Knowledge and experience on how to operate IPv4 networks securely is
available: whether it is an Internet Service Provider or an available: whether it is an Internet Service Provider or an
enterprise internal network. However, IPv6 presents some new enterprise internal network. However, IPv6 presents some new
security challenges. RFC 4942 describes security issues in the security challenges. RFC 4942 describes security issues in the
protocol, but network managers also need a more practical, protocol, but network managers also need a more practical,
operations-minded document to enumerate advantages and/or operations-minded document to enumerate advantages and/or
disadvantages of certain choices. disadvantages of certain choices.
This document analyzes the operational security issues associated This document analyzes the operational security issues associated
with several types of network and proposes technical and procedural with several types of network and proposes technical and procedural
mitigation techniques. This document is only applicable to managed mitigation techniques. This document is only applicable to managed
networks, such as enterprise networks. The recommendations in this networks, such as enterprise networks, service provider networks, or
document are not applicable to residential user cases, even in cases managed residential networks.
where a Service Provider may be managing the home gateway.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 11, 2021. This Internet-Draft will expire on November 7, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4
2. Generic Security Considerations . . . . . . . . . . . . . . . 4 2. Generic Security Considerations . . . . . . . . . . . . . . . 4
2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 2.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Point-to-Point Links . . . . . . . . . . . . . . . . 5 2.1.2. Point-to-Point Links . . . . . . . . . . . . . . . . 5
2.1.3. Loopback Addresses . . . . . . . . . . . . . . . . . 5 2.1.3. Loopback Addresses . . . . . . . . . . . . . . . . . 5
2.1.4. Stable Addresses . . . . . . . . . . . . . . . . . . 5 2.1.4. Stable Addresses . . . . . . . . . . . . . . . . . . 6
2.1.5. Temporary Addresses for SLAAC . . . . . . . . . . . . 6 2.1.5. Temporary Addresses for SLAAC . . . . . . . . . . . . 6
2.1.6. DHCP and DNS Considerations . . . . . . . . . . . . . 7 2.1.6. DHCP Considerations . . . . . . . . . . . . . . . . . 8
2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 8 2.1.7. DNS Considerations . . . . . . . . . . . . . . . . . 8
2.1.8. Privacy consideration of Addresses . . . . . . . . . 8 2.1.8. Using a /64 per host . . . . . . . . . . . . . . . . 8
2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 8 2.1.9. Privacy consideration of Addresses . . . . . . . . . 8
2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Order and Repetition of Extension Headers . . . . . . 9 2.2.1. Order and Repetition of Extension Headers . . . . . . 9
2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 9 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 10
2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 10 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 10
2.2.4. IP Security Extension Header . . . . . . . . . . . . 10 2.2.4. IP Security Extension Header . . . . . . . . . . . . 10
2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 10 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 11
2.3.1. Neighbor Solicitation Rate-Limiting . . . . . . . . . 11 2.3.1. Neighbor Solicitation Rate-Limiting . . . . . . . . . 11
2.3.2. Router and Neighbor Advertisements Filtering . . . . 11 2.3.2. Router and Neighbor Advertisements Filtering . . . . 12
2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 13 2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 13
2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 13 2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 14
2.3.5. Impact of Multicast Traffic . . . . . . . . . . . . . 14 2.3.5. Impact of Multicast Traffic . . . . . . . . . . . . . 15
2.3.6. SeND and CGA . . . . . . . . . . . . . . . . . . . . 15 2.3.6. SeND and CGA . . . . . . . . . . . . . . . . . . . . 15
2.4. Control Plane Security . . . . . . . . . . . . . . . . . 16 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 16
2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 17 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 17
2.4.2. Management Protocols . . . . . . . . . . . . . . . . 17 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 18
2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 18 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 18
2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 19 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 19
2.5.1. BGP Security . . . . . . . . . . . . . . . . . . . . 19 2.5.1. BGP Security . . . . . . . . . . . . . . . . . . . . 20
2.5.2. Authenticating OSPFv3 Neighbors . . . . . . . . . . . 19 2.5.2. Authenticating OSPFv3 Neighbors . . . . . . . . . . . 20
2.5.3. Securing Routing Updates . . . . . . . . . . . . . . 20 2.5.3. Securing Routing Updates . . . . . . . . . . . . . . 21
2.5.4. Route Filtering . . . . . . . . . . . . . . . . . . . 20 2.5.4. Route Filtering . . . . . . . . . . . . . . . . . . . 21
2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 21 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 21
2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 22 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 23
2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 26 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 26
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 29
2.7. Transition/Coexistence Technologies . . . . . . . . . . . 29 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 29
2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 29 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 30
2.7.2. Encapsulation Mechanisms . . . . . . . . . . . . . . 30 2.7.2. Encapsulation Mechanisms . . . . . . . . . . . . . . 31
2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 34 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 35
2.8. General Device Hardening . . . . . . . . . . . . . . . . 36 2.8. General Device Hardening . . . . . . . . . . . . . . . . 37
3. Enterprises Specific Security Considerations . . . . . . . . 37 3. Enterprises Specific Security Considerations . . . . . . . . 37
3.1. External Security Considerations . . . . . . . . . . . . 37 3.1. External Security Considerations . . . . . . . . . . . . 38
3.2. Internal Security Considerations . . . . . . . . . . . . 38 3.2. Internal Security Considerations . . . . . . . . . . . . 39
4. Service Providers Security Considerations . . . . . . . . . . 39 4. Service Providers Security Considerations . . . . . . . . . . 40
4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.1. Remote Triggered Black Hole Filtering (RTBH) . . . . 39 4.1.1. Remote Triggered Black Hole Filtering (RTBH) . . . . 40
4.2. Transition/Coexistence Mechanism . . . . . . . . . . . . 39 4.2. Transition/Coexistence Mechanism . . . . . . . . . . . . 40
4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 39 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 40
5. Residential Users Security Considerations . . . . . . . . . . 40 5. Residential Users Security Considerations . . . . . . . . . . 41
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 41 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 41
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Normative References . . . . . . . . . . . . . . . . . . 41 9.1. Normative References . . . . . . . . . . . . . . . . . . 42
9.2. Informative References . . . . . . . . . . . . . . . . . 42 9.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
Running an IPv6 network is new for most operators not only because Running an IPv6 network is new for most operators not only because
they are not yet used to large-scale IPv6 networks but also because they are not yet used to large-scale IPv6 networks but also because
there are subtle but critical and important differences between IPv4 there are subtle but critical and important differences between IPv4
and IPv6, especially with respect to security. For example, all and IPv6, especially with respect to security. For example, all
layer-2 interactions are now done using Neighbor Discovery Protocol layer-2 interactions are now done using Neighbor Discovery Protocol
[RFC4861] rather than using Address Resolution Protocol [RFC0826]. [RFC4861] rather than using Address Resolution Protocol [RFC0826].
Also, there is no Network Address Port Translation (NAPT) defined in Also, there is no Network Address Port Translation (NAPT) defined in
[RFC2663] for IPv6 even if [RFC6296] specifies a Network Prefix [RFC2663] for IPv6 even if [RFC6296] specifies a Network Prefix
Translation for IPv6 (NPTv6) which is a 1-to-1 mapping of IPv6 Translation for IPv6 (NPTv6) which is a 1-to-1 mapping of IPv6
addresses. addresses. Another important difference is that IPv6 is extensible
with the use of extension headers.
IPv6 networks are deployed using a variety of techniques, each of IPv6 networks are deployed using a variety of techniques, each of
which have their own specific security concerns. which have their own specific security concerns.
This document complements [RFC4942] by listing all security issues This document complements [RFC4942] by listing security issues when
when operating a network (including various transition technologies). operating a network (including various transition technologies). It
It also provides more recent operational deployment experiences where also provides more recent operational deployment experiences where
warranted. warranted.
1.1. Applicability Statement 1.1. Applicability Statement
This document is applicable to managed networks, i.e., when the This document is applicable to managed networks, i.e., when the
network is operated by the user organization itself. Indeed, many of network is operated by the user organization itself. Indeed, many of
the recommended mitigation techniques must be configured with the recommended mitigation techniques must be configured with
detailed knowledge of the network (which are the default routers, the detailed knowledge of the network (which are the default routers, the
switch trunk ports, etc.). This covers Service Provider (SP), switch trunk ports, etc.). This covers Service Provider (SP),
enterprise networks and some knowledgeable-home-user-managed enterprise networks and some knowledgeable-home-user-managed
residential network. This applicability statement especially applies residential networks. This applicability statement especially
to Section 2.3 and Section 2.5.4. applies to Section 2.3 and Section 2.5.4.
2. Generic Security Considerations 2. Generic Security Considerations
2.1. Addressing Architecture 2.1. Addressing
IPv6 address allocations and overall architecture are an important IPv6 address allocations and overall architecture are an important
part of securing IPv6. Initial designs, even if intended to be part of securing IPv6. Initial designs, even if intended to be
temporary, tend to last much longer than expected. Although temporary, tend to last much longer than expected. Although
initially IPv6 was thought to make renumbering easy, in practice it initially IPv6 was thought to make renumbering easy, in practice it
may be extremely difficult to renumber without a proper IP Address may be extremely difficult to renumber without a proper IP Address
Management (IPAM) system. [RFC7010] introduces the mechanisms that Management (IPAM) system. [RFC7010] introduces the mechanisms that
could be utilized for IPv6 site renumbering and tries to cover most could be utilized for IPv6 site renumbering and tries to cover most
of the explicit issues and requirements associated with IPv6 of the explicit issues and requirements associated with IPv6
renumbering. renumbering.
A key task for a successful IPv6 deployment is to prepare an A key task for a successful IPv6 deployment is to prepare an
addressing plan. Because an abundance of address space is available, addressing plan. Because an abundance of address space is available,
structuring an address plan around both services and geographic structuring an address plan around both services and geographic
locations allow address space to become a basis for more structured locations allows address space to become a basis for more structured
security policies to permit or deny services between geographic security policies to permit or deny services between geographic
regions. [RFC6177] documents some operational considerations of regions. [RFC6177] documents some operational considerations of
using different prefix sizes for address assignments at end sites. using different prefix sizes for address assignments at end sites.
A common question is whether companies should use Provider A common question is whether companies should use Provider
Independent (PI) vs. Provider Allocated (PA) space [RFC7381], but Independent (PI) vs. Provider Allocated (PA) space [RFC7381], but
from a security perspective there is little difference. However, one from a security perspective there is little difference. However, one
aspect to keep in mind is who has administrative ownership of the aspect to keep in mind is who has administrative ownership of the
address space and who is technically responsible if/when there is a address space and who is technically responsible if/when there is a
need to enforce restrictions on routability of the space, e.g., due need to enforce restrictions on routability of the space, e.g., due
to malicious criminal activity originating from it. Relying on PA to malicious criminal activity originating from it. Relying on PA
address may also increase the perceived need for NPTv6 and therefore address space may also increase the perceived need for address
augmenting the complexity of the operations including the security translation techniques such as NPTv6 and thereby augmenting the
operations. complexity of the operations including the security operations.
In [RFC7934], it is recommended that IPv6 network deployments provide In [RFC7934], it is recommended that IPv6 network deployments provide
multiple IPv6 addresses from each prefix to general-purpose hosts and multiple IPv6 addresses from each prefix to general-purpose hosts and
it specifically does not recommend limiting a host to only one IPv6 it specifically does not recommend limiting a host to only one IPv6
address per prefix. It also recommends that the network give the address per prefix. It also recommends that the network give the
host the ability to use new addresses without requiring explicit host the ability to use new addresses without requiring explicit
requests (for example by using SLAAC). Having by default multiple requests (for example by using SLAAC). Privacy Extensions as of
IPv6 addresses per interface is a major change compared to the unique [RFC8981] constitute one of the main scenarios where hosts are
IPv4 address per interface for hosts (secondary IPv4 addresses are expected to generate multiple addresses from the same prefix and
not common); especially for audits (see section Section 2.6.2.3). having multiple IPv6 addresses per interface is a major change
compared to the unique IPv4 address per interface for hosts
(secondary IPv4 addresses are not common); especially for audits (see
section Section 2.6.2.3).
2.1.1. Use of ULAs 2.1.1. Use of ULAs
Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
where interfaces are not globally reachable, despite being routed where interfaces are not globally reachable, despite being routed
within a domain. They formally have global scope, but [RFC4193] within a domain. They formally have global scope, but [RFC4193]
specifies that they must be filtered at domain boundaries. ULAs are specifies that they must be filtered at domain boundaries. ULAs are
different from [RFC1918] addresses and have different use cases. One different from [RFC1918] addresses and have different use cases. One
use of ULA is described in [RFC4864], another one is for internal use of ULA is described in [RFC4864], another one is for internal
communication stability in networks where external connectivity may communication stability in networks where external connectivity may
come and go (e.g., some ISPs provide ULAs in home networks connected come and go (e.g., some ISPs provide ULAs in home networks connected
via a cable modem). It should further be kept in mind that ULA /48s via a cable modem). It should further be kept in mind that ULA /48s
from the fd00::/8 space (L=1) MUST be generated with a pseudo-random from the fd00::/8 space (L=1) MUST be generated with a pseudo-random
algorithm, per [RFC4193] section 3.2.1. algorithm, per [RFC4193] section 3.2.1.
2.1.2. Point-to-Point Links 2.1.2. Point-to-Point Links
[RFC6164] in section 5.1 specifies the rationale of using /127 for [RFC6164] in section 5.1 specifies the rationale of using /127 for
inter-router point-to-point links; a /127 prevents the ping-pong inter-router point-to-point links to prevent the ping-pong issue
attack between routers not correctly implementing [RFC4443] and also between routers not correctly implementing [RFC4443] and also
prevents a DoS attack on the neighbor cache. The previous prevents a DoS attack on the neighbor cache. The previous
recommendation of [RFC3627] has been obsoleted and marked Historic by recommendation of [RFC3627] has been obsoleted and marked Historic by
[RFC6547]). [RFC6547]).
Some environments are also using link-local addressing for point-to- Some environments are also using link-local addressing for point-to-
point links. While this practice could further reduce the attack point links. While this practice could further reduce the attack
surface of infrastructure devices, the operational disadvantages also surface of infrastructure devices, the operational disadvantages also
need to be carefully considered; see also [RFC7404]. need to be carefully considered; see also [RFC7404].
2.1.3. Loopback Addresses 2.1.3. Loopback Addresses
skipping to change at page 6, line 13 skipping to change at page 6, line 20
effectiveness of perimeter security in a given environment. effectiveness of perimeter security in a given environment.
There is a trade-off between ease of operation (where some portions There is a trade-off between ease of operation (where some portions
of the IPv6 address could be easily recognizable for operational of the IPv6 address could be easily recognizable for operational
debugging and troubleshooting) versus the risk of trivial scanning debugging and troubleshooting) versus the risk of trivial scanning
used for reconnaissance. [SCANNING] shows that there are used for reconnaissance. [SCANNING] shows that there are
scientifically based mechanisms that make scanning for IPv6 reachable scientifically based mechanisms that make scanning for IPv6 reachable
nodes more feasible than expected; see also [RFC7707]. nodes more feasible than expected; see also [RFC7707].
Stable addresses also allow easy enforcement of a security policy at Stable addresses also allow easy enforcement of a security policy at
the perimeter based on IPv6 addresses. [RFC8520] is a mechanism the perimeter based on IPv6 addresses. E.g., Manufacturer Usage
where the perimeter defense can retrieve security policy template Description (MUD) [RFC8520] is a mechanism where the perimeter
based on the type of internal device. defense can retrieve security policy template based on the type of
internal device and apply the right security policy based on the
device IPv6 address.
The use of well-known IPv6 addresses (such as ff02::1 for all link- The use of well-known IPv6 addresses (such as ff02::1 for all link-
local nodes) or the use of commonly repeated addresses could make it local nodes) or the use of commonly repeated addresses could make it
easy to figure out which devices are name servers, routers, or other easy to figure out which devices are name servers, routers, or other
critical devices; even a simple traceroute will expose most of the critical devices; even a simple traceroute will expose most of the
routers on a path. There are many scanning techniques possible and routers on a path. There are many scanning techniques possible and
operators should not rely on the 'impossible to find because my operators should not rely on the 'impossible to find because my
address is random' paradigm (a.k.a. "security by obscurity"), even if address is random' paradigm (a.k.a. "security by obscurity"), even if
it is common practice to have the stable addresses randomly it is common practice to have the stable addresses randomly
distributed across /64 subnets and to always use DNS (as IPv6 distributed across /64 subnets and to always use DNS (as IPv6
addresses are hard for human brains to remember). addresses are hard for human brains to remember).
While in some environments obfuscating addresses could be considered While in some environments obfuscating addresses could be considered
an added benefit, it does not preclude enforcement of perimeter rules an added benefit, it should not preclude enforcement of perimeter
and that stable addresses follow some logical allocation scheme for rules. Stable addresses following some logical allocation scheme may
ease of operation (as simplicity always helps security). ease the operation (as simplicity always helps security).
Typical deployments will have a mix of stable and non-stable Typical deployments will have a mix of stable and non-stable
addresses; the stable addresses being either predictable (e.g., ::25 addresses; the stable addresses being either predictable (e.g., ::25
for a mail server) or obfuscated (i.e., appearing as a random 64-bit for a mail server) or obfuscated (i.e., appearing as a random 64-bit
number). number).
2.1.5. Temporary Addresses for SLAAC 2.1.5. Temporary Addresses for SLAAC
Historically, stateless address autoconfiguration (SLAAC) makes up Historically, stateless address autoconfiguration (SLAAC) makes up
the globally unique IPv6 address based on an automatically generated the globally unique IPv6 address based on an automatically generated
skipping to change at page 7, line 29 skipping to change at page 7, line 37
same IID for each network prefix; this allows SLAAC nodes to always same IID for each network prefix; this allows SLAAC nodes to always
have the same stable IPv6 address on a specific network while having have the same stable IPv6 address on a specific network while having
different IPv6 addresses on different networks. different IPv6 addresses on different networks.
In some specific use cases where user accountability is more In some specific use cases where user accountability is more
important than user privacy, network operators may consider disabling important than user privacy, network operators may consider disabling
SLAAC and relying only on DHCPv6; but not all operating systems SLAAC and relying only on DHCPv6; but not all operating systems
support DHCPv6 so some hosts will not get any IPv6 connectivity. support DHCPv6 so some hosts will not get any IPv6 connectivity.
Disabling SLAAC and privacy extension addresses can be done for most Disabling SLAAC and privacy extension addresses can be done for most
operating systems by sending RA messages with a hint to get addresses 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 via DHCPv6 by setting the M-bit and disabling SLAAC by resetting all
all A-bits in all prefix information options. However, attackers A-bits in all prefix information options. However, attackers could
could still find ways to bypass this mechanism if not enforced at the still find ways to bypass this mechanism if not enforced at the
switch/router level. switch/router level.
However, in scenarios where anonymity is a strong desire (protecting However, in scenarios where anonymity is a strong desire (protecting
user privacy is more important than user attribution), privacy user privacy is more important than user attribution), privacy
extension addresses should be used. When [RFC8064] is available, the extension addresses should be used. When mechanisms recommended by
stable privacy address is probably a good balance between privacy [RFC8064] are available, the stable privacy address is probably a
(among different networks) and security/user attribution (within a good balance between privacy (among different networks) and security/
network). user attribution (within a network).
2.1.6. DHCP and DNS Considerations 2.1.6. DHCP Considerations
Some environments use DHCPv6 to provision addresses and other Some environments use DHCPv6 to provision addresses and other
parameters in order to ensure auditability and traceability (see parameters in order to ensure auditability and traceability (see
Section 2.6.1.5 for the limitations of DHCPv6 for auditability). Section 2.6.1.5 for the limitations of DHCPv6 for auditability).
A main security concern is the ability to detect and counteract rogue A main security concern is the ability to detect and counteract rogue
DHCP servers (Section 2.3.3). It must be noted that as opposed to DHCP servers (Section 2.3.3). It must be noted that as opposed to
DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For
DHCPv4, the lease is bound to the 'client identifier', which may DHCPv4, the lease is bound to the 'client identifier', which may
contain a hardware address, or it may contain another type of contain a hardware address, or it may contain another type of
identifier, such as a DNS name. For DHCPv6, the lease is bound to identifier, such as a DNS name. For DHCPv6, the lease is bound to
the client DHCP Unique ID (DUID), which may, or may not, be bound to the client DHCP Unique ID (DUID), which may, or may not, be bound to
the client link-layer address. [RFC7824] describes the privacy the client link-layer address. [RFC7824] describes the privacy
issues associated with the use of DHCPv6 by Internet users. The issues associated with the use of DHCPv6 by Internet users. The
anonymity profiles [RFC7844] are designed for clients that wish to anonymity profiles [RFC7844] are designed for clients that wish to
remain anonymous to the visited network. [RFC7707] recommends that remain anonymous to the visited network. [RFC7707] recommends that
DHCPv6 servers issue addresses randomly from a large pool. DHCPv6 servers issue addresses randomly from a large pool.
While there are no fundamental differences with IPv4 and IPv6 DNS 2.1.7. DNS Considerations
security concerns, there are specific considerations in DNS64
While the security concerns of DNS are not fundamentally different
between IPv4 and IPv6, there are specific considerations in DNS64
[RFC6147] environments that need to be understood. Specifically, the [RFC6147] environments that need to be understood. Specifically, the
interactions and the potential of interference with DNSSEC interactions and the potential of interference with DNSSEC
([RFC4033]) implementation need to be understood - these are pointed ([RFC4033]) implementation need to be understood - these are pointed
out in more detail in Section 2.7.3.2. out in more detail in Section 2.7.3.2.
2.1.7. Using a /64 per host 2.1.8. Using a /64 per host
An interesting approach is using a /64 per host as proposed in An interesting approach is using a /64 per host as proposed in
[RFC8273] especially in a shared environment. This allows for easier [RFC8273] especially in a shared environment. This allows for easier
user attribution (typically based on the host MAC address) as its /64 user attribution (typically based on the host MAC address) as its /64
prefix is stable even if applications within the host can change prefix is stable even if applications within the host can change
their IPv6 address within this /64 prefix. their IPv6 address within this /64 prefix.
This can also be useful for the generation of ACLs once individual This can also be useful for the generation of ACLs once individual
systems (e.g. admin workstations) have their own prefixes. systems (e.g. admin workstations) have their own prefixes.
2.1.8. Privacy consideration of Addresses 2.1.9. Privacy consideration of Addresses
Beside the security aspects of IPv6 addresses, there are also privacy Beside the security aspects of IPv6 addresses, there are also privacy
considerations: mainly because they are of global scope and visible considerations: mainly because they are of global scope and visible
globally. [RFC7721] goes into more detail on the privacy globally. [RFC7721] goes into more detail on the privacy
considerations for IPv6 addresses by comparing the manually considerations for IPv6 addresses by comparing the manually
configured IPv6 address, DHCPv6, and SLAAC. configured IPv6 address, DHCPv6, and SLAAC.
2.2. Extension Headers 2.2. Extension Headers
Extension headers are an important difference between IPv4 and IPv6. Extension headers are an important difference between IPv4 and IPv6.
skipping to change at page 9, line 37 skipping to change at page 10, line 6
While [RFC8200] recommends the order and the maximum repetition of While [RFC8200] recommends the order and the maximum repetition of
extension headers, there are still IPv6 implementations, at the time extension headers, there are still IPv6 implementations, at the time
of writing, which support a non-recommended order of headers (such as of writing, which support a non-recommended order of headers (such as
ESP before routing) or an illegal repetition of headers (such as ESP before routing) or an illegal repetition of headers (such as
multiple routing headers). The same applies for options contained in multiple routing headers). The same applies for options contained in
the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]). the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]).
In some cases, it has led to nodes crashing when receiving or In some cases, it has led to nodes crashing when receiving or
forwarding wrongly formatted packets. forwarding wrongly formatted packets.
A firewall or edge device should be used to enforce the recommended A firewall or edge device should be used to enforce the recommended
order and the maximum occurrences of extension headers. order and the maximum occurrences of extension headers by dropping
non-conforming packets.
2.2.2. Hop-by-Hop Options Header 2.2.2. Hop-by-Hop Options Header
In the previous IPv6 specification [RFC2460], the hop-by-hop options In the previous IPv6 specification [RFC2460], the hop-by-hop options
header, when present in an IPv6 packet, forced all nodes to inspect header, when present in an IPv6 packet, forced all nodes to inspect
and possibly process this header. This enabled denial-of-service and possibly process this header. This enabled denial-of-service
attacks as most, if not all, routers cannot process this type of attacks as most, if not all, routers cannot process this type of
packet in hardware but have to process these packets in software and packet in hardware but have to process these packets in software and
hence compete with other software tasks, such as handling the control hence compete with other software tasks, such as handling the control
and management plane processing. and management plane processing.
skipping to change at page 10, line 24 skipping to change at page 10, line 41
not contain the entire IPv6 header chain (including the transport- not contain the entire IPv6 header chain (including the transport-
layer header). layer header).
Destination nodes should discard first fragments that do not Destination nodes should discard first fragments that do not
contain the entire IPv6 header chain (including the transport- contain the entire IPv6 header chain (including the transport-
layer header). layer header).
If those requirements are not met, stateless filtering could be If those requirements are not met, stateless filtering could be
bypassed by a hostile party. [RFC6980] applies a stricter rule to bypassed by a hostile party. [RFC6980] applies a stricter rule to
Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented
NDP packets. [RFC7113] describes how the RA-guard function described NDP packets (except for "Certification Path Advertisement" messages
in [RFC6105] should behave in the presence of fragmented RA packets. as noted in section Section 2.3.2.1). [RFC7113] describes how the
RA-guard function described in [RFC6105] should behave in the
presence of fragmented RA packets.
2.2.4. IP Security Extension Header 2.2.4. IP Security Extension Header
The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP The IPsec [RFC4301] extension headers (AH [RFC4302] and ESP
[RFC4303]) are required if IPsec is to be utilized for network level [RFC4303]) are required if IPsec is to be utilized for network level
security. But IPsec is no longer required for normal IPv6 nodes: in security. Previously, IPv6 mandated implementation of IPsec but
the updated IPv6 Nodes Requirement standard [RFC8504], IPsec is a [RFC6434] updated that recommendation by making support of the IPsec
'SHOULD' and not a 'MUST' implement. architecture [RFC4301] a SHOULD for all IPv6 nodes which is also
retained in the latest IPv6 Nodes Requirement standard [RFC8504].
2.3. Link-Layer Security 2.3. Link-Layer Security
IPv6 relies heavily on NDP [RFC4861] to perform a variety of link IPv6 relies heavily on NDP [RFC4861] to perform a variety of link
operations such as discovering other nodes on the link, resolving operations such as discovering other nodes on the link, resolving
their link-layer addresses, and finding routers on the link. If not their link-layer addresses, and finding routers on the link. If not
secured, NDP is vulnerable to various attacks, such as router/ secured, NDP is vulnerable to various attacks, such as router/
neighbor message spoofing, redirect attacks, Duplicate Address neighbor message spoofing, redirect attacks, Duplicate Address
Detection (DAD) DoS attacks, etc. Many of these security threats to Detection (DAD) DoS attacks, etc. Many of these security threats to
NDP have been documented in IPv6 ND Trust Models and Threats NDP have been documented in IPv6 ND Trust Models and Threats
[RFC3756] and in [RFC6583]. [RFC3756] and in [RFC6583].
Most of the issues are only applicable when the attacker is on the Most of the issues are only applicable when the attacker is on the
same link but NDP also has security issues when the attacker is off- same link but NDP also has security issues when the attacker is off-
link, see the section below Section 2.3.1. link, see the section below Section 2.3.1.
2.3.1. Neighbor Solicitation Rate-Limiting 2.3.1. Neighbor Solicitation Rate-Limiting
NDP can be vulnerable to remote denial of service (DoS) attacks; for NDP can be vulnerable to remote denial of service (DoS) attacks; for
example, when a router is forced to perform address resolution for a example, when a router is forced to perform address resolution for a
large number of unassigned addresses, i.e., a neighbor cache large number of unassigned addresses, i.e., when a prefix is scanned
exhaustion attack. This can keep new devices from joining the by an attacker in a fast manner. This can keep new devices from
network or render the last-hop router ineffective due to high CPU joining the network or render the last-hop router ineffective due to
usage. Easy mitigative steps include rate-limiting Neighbor high CPU usage. Easy mitigative steps include rate-limiting Neighbor
Solicitations, restricting the amount of state reserved for Solicitations, restricting the amount of state reserved for
unresolved solicitations, and clever cache/timer management. unresolved solicitations, and clever cache/timer management.
[RFC6583] discusses the potential for off-link DoS in detail and [RFC6583] discusses the potential for off-link DoS in detail and
suggests implementation improvements and operational mitigation suggests implementation improvements and operational mitigation
techniques that may be used to mitigate or alleviate the impact of techniques that may be used to mitigate or alleviate the impact of
such attacks. Here are some feasible mitigation options that can be such attacks. Here are some feasible mitigation options that can be
employed by network operators today: employed by network operators today:
o Ingress filtering of unused addresses by ACL. These require o Ingress filtering of unused addresses by ACL. These require
stable configuration of the addresses; for example, allocating the stable configuration of the addresses; for example, allocating the
addresses out of a /120 and using a specific ACL to only allow addresses out of a /120 and using a specific ACL to only allow
traffic to this /120 (of course, the actual hosts are configured traffic to this /120 (of course, the actual hosts are configured
with a /64 prefix for the link). with a /64 prefix for the link).
o Tuning of NDP process (where supported), e.g., enforcing limits on o Tuning of NDP process (where supported), e.g., enforcing limits on
data structures such as the number of neighbor cache entries in data structures such as the number of neighbor cache entries in
'incomplete' state. 'incomplete' state (e.g., 256 incomplete entries per interface) or
the rate of NA per interface (e.g., 100 NA per second).
o Using a /127 on point-to-point link per [RFC6164]. o Using a /127 on a point-to-point link, per [RFC6164].
o Using link-local addresses only on links where there are only o Using only link-local addresses on links where there are only
routers, see [RFC7404] routers, see [RFC7404]
2.3.2. Router and Neighbor Advertisements Filtering 2.3.2. Router and Neighbor Advertisements Filtering
2.3.2.1. Router Advertisement Filtering 2.3.2.1. Router Advertisement Filtering
Router Advertisement spoofing is a well-known on-link attack vector Router Advertisement spoofing is a well-known on-link attack vector
and has been extensively documented. The presence of rogue RAs, and has been extensively documented. The presence of rogue RAs,
either unintentional or malicious, can cause partial or complete either unintentional or malicious, can cause partial or complete
failure of operation of hosts on an IPv6 link. For example, a node failure of operation of hosts on an IPv6 link. For example, a node
skipping to change at page 12, line 36 skipping to change at page 13, line 8
[RFC7513] helps in creating bindings between a DHCPv4 [RFC2131] [RFC7513] helps in creating bindings between a DHCPv4 [RFC2131]
/DHCPv6 [RFC8415] assigned source IP address and a binding anchor /DHCPv6 [RFC8415] assigned source IP address and a binding anchor
[RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean
similar bindings when DHCP is not used. The bindings can be used to similar bindings when DHCP is not used. The bindings can be used to
filter packets generated on the local link with forged source IP filter packets generated on the local link with forged source IP
addresses. addresses.
2.3.2.3. Host Isolation 2.3.2.3. Host Isolation
Isolating hosts for the NDP traffic can be done by using a /64 per 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 host, refer to Section 2.1.8, as NDP is only relevant within a /64
on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism. on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism.
A more drastic technique to prevent all NDP attacks is based on A more drastic technique to prevent all NDP attacks is based on
isolation of all hosts with specific configurations. Hosts (i.e., isolation of all hosts with specific configurations. In such a
all nodes that are not routers) are unable to send data-link layer scenario, hosts (i.e., all nodes that are not routers) are unable to
frames to other hosts, therefore, no host-to-host attacks can happen. send data-link layer frames to other hosts, therefore, no host-to-
This specific setup can be established on some switches or Wi-Fi host attacks can happen. This specific setup can be established on
access points. This is not always feasible when hosts need to some switches or Wi-Fi access points. This is not always feasible
communicate with other hosts in the same subnet, e.g., for access to when hosts need to communicate with other hosts in the same subnet,
file shares. e.g., for access to file shares.
2.3.2.4. NDP Recommendations 2.3.2.4. NDP Recommendations
It is still recommended that RA-Guard and SAVI be employed as a first It is still recommended that RA-Guard and SAVI be employed as a first
line of defense against common attack vectors including misconfigured line of defense against common attack vectors including misconfigured
hosts. This recommendation also applies when DHCPv6 is used as RA hosts. This recommendation also applies when DHCPv6 is used, as RA
messages are used to discover the default router(s) and for on-link messages are used to discover the default router(s) and for on-link
prefix determination. This line of defense is most effective when prefix determination. This line of defense is most effective when
incomplete fragments are dropped by routers and switches as described incomplete fragments are dropped by routers and switches as described
in Section 2.2.3. The generated log should also be analyzed to in Section 2.2.3. The generated log should also be analyzed to
identify and act on violations. Network operators should be aware identify and act on violations.
that RA-Guard and SAVI do not work or could even be harmful in
specific network configurations (notably when there could be multiple
routers).
Enabling RA-Guard by default in Wi-Fi networks or enterprise campus Network operators should be aware that RA-Guard and SAVI do not work
networks should be strongly considered unless specific use cases such as expected or could even be harmful in specific network
as the presence of devices Homenet devices emitting router configurations (notably when there could be multiple routers).
advertisements preclude this.
Enabling RA-Guard by default in managed networks (e.g., Wi-Fi
networks, enterprise campus networks, etc.) should be strongly
considered except for specific use cases such as the presence of
homenet devices emitting router advertisements.
2.3.3. Securing DHCP 2.3.3. Securing DHCP
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as
in [RFC8415], enables DHCP servers to pass configuration parameters described in [RFC8415], enables DHCP servers to pass configuration
such as IPv6 network addresses and other configuration information to parameters, such as IPv6 network addresses and other configuration
IPv6 nodes such as a recursive DNS server. DHCP plays an important information, to IPv6 nodes. DHCP plays an important role in most
role in most large networks by providing robust stateful large networks by providing robust stateful configuration in the
configuration in the context of automated system provisioning. context of automated system provisioning.
The two most common threats to DHCP clients come from malicious The two most common threats to DHCP clients come from malicious
(a.k.a., rogue) or unintentionally misconfigured DHCP servers. A (a.k.a., rogue) or unintentionally misconfigured DHCP servers. in
malicious DHCP server is established with the intent of providing these scenarios, a malicious DHCP server is established with the
incorrect configuration information to the clients to cause a denial- intent of providing incorrect configuration information to the
of-service attack or to mount on path attack. While unintentional, a clients to cause a denial-of-service attack or to mount on-path
misconfigured DHCP server can have the same impact. Additional attack. While unintentional, a misconfigured DHCP server can have
threats against DHCP are discussed in the security considerations the same impact. Additional threats against DHCP are discussed in
section of [RFC8415]. the security considerations section of [RFC8415].
DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting
connected DHCPv6 clients against rogue DHCPv6 servers. This connected DHCPv6 clients against rogue DHCPv6 servers. This
mechanism is based on DHCPv6 packet-filtering at the layer-2 device, mechanism is based on DHCPv6 packet-filtering at the layer-2 device,
i.e., the administrator specifies the interfaces connected to DHCPv6 i.e., the administrator specifies the interfaces connected to DHCPv6
servers. However, extension headers could be leveraged to bypass servers. However, extension headers could be leveraged to bypass
DHCPv6-Shield unless [RFC7112] is enforced. DHCPv6-Shield unless [RFC7112] is enforced.
It is recommended to use DHCPv6-Shield and to analyze the It is recommended to use DHCPv6-Shield and to analyze the
corresponding log messages. corresponding log messages.
2.3.4. 3GPP Link-Layer Security 2.3.4. 3GPP Link-Layer Security
The 3GPP link is a point-to-point like link that has no link-layer The 3GPP link is a point-to-point like link that has no link-layer
address. This implies there can only be an end host (the mobile address. This implies there can only be one end host (the mobile
hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node
(GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never
configures a non link-local address on the link using the advertised configures a non link-local address on the link using the advertised
/64 prefix on it; see Section 2.1.7. The advertised prefix must not /64 prefix on it; see Section 2.1.8. The advertised prefix must not
be used for on-link determination. There is no need for address be used for on-link determination. There is no need for address
resolution on the 3GPP link, since there are no link-layer addresses. resolution on the 3GPP link, since there are no link-layer addresses.
Furthermore, the GGSN/PGW assigns a prefix that is unique within each Furthermore, the GGSN/PGW assigns a prefix that is unique within each
3GPP link that uses IPv6 stateless address autoconfiguration. This 3GPP link that uses IPv6 stateless address autoconfiguration. This
avoids the necessity to perform DAD at the network level for every avoids the necessity to perform DAD at the network level for every
address generated by the mobile host. The GGSN/PGW always provides address generated by the mobile host. The GGSN/PGW always provides
an IID to the cellular host for the purpose of configuring the link- an IID to the cellular host for the purpose of configuring the link-
local address and ensures the uniqueness of the IID on the link local address and ensures the uniqueness of the IID on the link
(i.e., no collisions between its own link-local address and the (i.e., no collisions between its own link-local address and the
mobile host's address). mobile host's address).
The 3GPP link model itself mitigates most of the known NDP-related The 3GPP link model itself mitigates most of the known NDP-related
Denial-of-Service attacks. In practice, the GGSN/PGW only needs to Denial-of-Service attacks. In practice, the GGSN/PGW only needs to
route all traffic to the mobile host that falls under the prefix route all traffic to the mobile host that falls under the prefix
assigned to it. As there is also a single host on the 3GPP link, assigned to it. As there is also a single host on the 3GPP link,
there is no need to defend that IPv6 address. there is no need to defend that IPv6 address.
See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP
link model, NDP on it and the address configuration details. In some link model, NDP, and the address configuration details. In some
mobile networks, DHCPv6 and DHCP-PD are also used. mobile networks, DHCPv6 and DHCP-PD are also used.
2.3.5. Impact of Multicast Traffic 2.3.5. Impact of Multicast Traffic
IPv6 uses multicast extensively for signaling messages on the local IPv6 uses multicast extensively for signaling messages on the local
link to avoid broadcast messages for on-the-wire efficiency. link to avoid broadcast messages for on-the-wire efficiency.
The use of multicast has some side effects on wireless networks, such The use of multicast has some side effects on wireless networks, such
as a negative impact on battery life of smartphones and other as a negative impact on battery life of smartphones and other
battery-operated devices that are connected to such networks. battery-operated devices that are connected to such networks.
[RFC7772], [RFC6775] (for specific wireless networks) discuss methods [RFC7772] and [RFC6775] (for specific wireless networks) discuss
to rate-limit RAs and other ND messages on wireless networks in order methods to rate-limit RAs and other ND messages on wireless networks
to address this issue. in order to address this issue.
The use of link-layer multicast addresses (e.g., ff02::1 for the all The use of link-layer multicast addresses (e.g., ff02::1 for the all
nodes link-local multicast address) could also be misused for an nodes link-local multicast address) could also be misused for an
amplification attack. Imagine, a hostile node sending an ICMPv6 amplification attack. Imagine, a hostile node sending an ICMPv6
ECHO_REQUEST to ff02::1 with a spoofed source address, then, all ECHO_REQUEST to ff02::1 with a spoofed source address, then, all
link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the
source address. This could be a DoS attack for the address owner. source address. This could be a DoS attack for the address owner.
This attack is purely local to the layer-2 network as packets with a This attack is purely local to the layer-2 network as packets with a
link-local destination are never forwarded by an IPv6 router. link-local destination are never forwarded by an IPv6 router.
This is the reason why large Wi-Fi network deployments limit the use This is the reason why large Wi-Fi network deployments often limit
of link-layer multicast either from or to the uplink of the Wi-Fi the use of link-layer multicast either from or to the uplink of the
access point, i.e., Wi-Fi stations cannot send link-local multicast Wi-Fi access point, i.e., Wi-Fi stations are prevented to send link-
to their direct neighboring Wi-Fi stations. local multicast to their direct neighboring Wi-Fi stations; this
policy also blocks service discovery via mDNS ([RFC6762]) and LLMNR
([RFC4795]).
2.3.6. SeND and CGA 2.3.6. SeND and CGA
SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a
mechanism that was designed to secure ND messages. This approach mechanism that was designed to secure ND messages. This approach
involves the use of new NDP options to carry public key-based involves the use of new NDP options to carry public key-based
signatures. Cryptographically Generated Addresses (CGA), as signatures. Cryptographically Generated Addresses (CGA), as
described in [RFC3972], are used to ensure that the sender of a described in [RFC3972], are used to ensure that the sender of a
Neighbor Discovery message is the actual "owner" of the claimed IPv6 Neighbor Discovery message is the actual "owner" of the claimed IPv6
address. A new NDP option, the CGA option, was introduced and is address. A new NDP option, the CGA option, was introduced and is
skipping to change at page 16, line 37 skipping to change at page 17, line 11
identify the packet's IP next hop and best outgoing interface towards identify the packet's IP next hop and best outgoing interface towards
the destination, and forwarding the packet through the appropriate the destination, and forwarding the packet through the appropriate
outgoing interface. outgoing interface.
While the forwarding plane is usually implemented in high-speed While the forwarding plane is usually implemented in high-speed
hardware, the control plane is implemented by a generic processor hardware, the control plane is implemented by a generic processor
(referred to as the route processor (RP)) and cannot process packets (referred to as the route processor (RP)) and cannot process packets
at a high rate. Hence, this processor can be attacked by flooding at a high rate. Hence, this processor can be attacked by flooding
its input queue with more packets than it can process. The control its input queue with more packets than it can process. The control
plane processor is then unable to process valid control packets and plane processor is then unable to process valid control packets and
the router can lose OSPF or BGP adjacencies which can cause a severe the router can lose IGP or BGP adjacencies which can cause a severe
network disruption. network disruption.
[RFC6192] provides detailed guidance to protect the router control [RFC6192] provides detailed guidance to protect the router control
plane in IPv6 networks. The rest of this section contains simplified plane in IPv6 networks. The rest of this section contains simplified
guidance. guidance.
The mitigation techniques are: The mitigation techniques are:
o To drop non-legit or potentially harmful control packets before o To drop non-legit or potentially harmful control packets before
they are queued to the RP (this can be done by a forwarding plane they are queued to the RP (this can be done by a forwarding plane
skipping to change at page 17, line 14 skipping to change at page 17, line 37
the Dijkstra algorithm, therefore, the frequency of Dijsktra the Dijkstra algorithm, therefore, the frequency of Dijsktra
calculations should be also rate-limited). calculations should be also rate-limited).
This section will consider several classes of control packets: This section will consider several classes of control packets:
o Control protocols: routing protocols: such as OSPFv3, BGP, RIPng, o Control protocols: routing protocols: such as OSPFv3, BGP, RIPng,
and by extension NDP and ICMP and by extension NDP and ICMP
o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc. o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc.
o Packet exceptions: normal data packets which requires a specific o Packet exceptions: normal data packets that require a specific
processing such as generating a packet-too-big ICMP message or processing such as generating a packet-too-big ICMP message or
processing the hop-by-hop options header. processing the hop-by-hop options header.
2.4.1. Control Protocols 2.4.1. Control Protocols
This class includes OSPFv3, BGP, NDP, ICMP. This class includes OSPFv3, BGP, NDP, ICMP.
An ingress ACL to be applied on all the router interfaces for packets An ingress ACL to be applied on all the router interfaces for packets
to be processed by the RP should be configured to: to be processed by the RP should be configured to:
skipping to change at page 19, line 29 skipping to change at page 20, line 4
Preamble: IPv6 routing security is congruent with IPv4 routing Preamble: IPv6 routing security is congruent with IPv4 routing
security with the exception of OSPv3 neighbor authentication (see security with the exception of OSPv3 neighbor authentication (see
Section 2.5.2). Section 2.5.2).
Routing security in general can be broadly divided into three Routing security in general can be broadly divided into three
sections: sections:
1. Authenticating neighbors/peers 1. Authenticating neighbors/peers
2. Securing routing updates between peers 2. Securing routing updates between peers
3. Route filtering 3. Route filtering
[RFC5082] is also applicable to IPv6 and can ensure that routing [RFC5082] is also applicable to IPv6 and can ensure that routing
protocol packets are coming from the local network; it must also be protocol packets are coming from the local network; it must also be
noted that in IPv6 all interior gateway protocols use link-local noted that in IPv6 all interior gateway protocols use link-local
addresses. addresses.
As for IPv4, it is recommended to enable a routing protocol only on As for IPv4, it is recommended to enable a routing protocol only on
interfaces where it is required. interfaces where it is required.
2.5.1. BGP Security 2.5.1. BGP Security
As BGP is identical for IPv4 and IPv6 and as [RFC7454] covers all the As BGP is identical for IPv4 and IPv6 and as [RFC7454] covers all the
security aspects for BGP in detail, [RFC7454] is also applicable to security aspects for BGP in detail, [RFC7454] is also applicable to
IPv6. IPv6.
2.5.2. Authenticating OSPFv3 Neighbors 2.5.2. Authenticating OSPFv3 Neighbors
OSPFv3 can rely on IPsec to fulfill the authentication function. OSPFv3 can rely on IPsec to fulfill the authentication function.
However, it should be noted that IPsec support is not standard on all Operators should note that IPsec support is not standard on all
routing platforms. In some cases, this requires specialized hardware routing platforms. In some cases, this requires specialized hardware
that offloads crypto over to dedicated ASICs or enhanced software that offloads crypto over to dedicated ASICs or enhanced software
images (both of which often come with added financial cost) to images (both of which often come with added financial cost) to
provide such functionality. An added detail is to determine whether provide such functionality. An added detail is to determine whether
OSPFv3 IPsec implementations use AH or ESP-Null for integrity OSPFv3 IPsec implementations use AH or ESP-Null for integrity
protection. In early implementations, all OSPFv3 IPsec protection. In early implementations, all OSPFv3 IPsec
configurations relied on AH since the details weren't specified in configurations relied on AH since the details weren't specified in
[RFC5340]. However, the document which specifically describes how [RFC5340]. However, the document which specifically describes how
IPsec should be implemented for OSPFv3 [RFC4552] specifically states IPsec should be implemented for OSPFv3 [RFC4552] specifically states
that "ESP-Null MUST and AH MAY be implemented" since it follows the that "ESP-Null MUST and AH MAY be implemented" since it follows the
skipping to change at page 20, line 28 skipping to change at page 20, line 50
specifically authenticate the specific originator of an OSPFv3 specifically authenticate the specific originator of an OSPFv3
packet; rather, it allows a router to confirm that the packet has packet; rather, it allows a router to confirm that the packet has
been issued by a router that had access to the shared authentication been issued by a router that had access to the shared authentication
key. key.
With all authentication mechanisms, operators should confirm that With all authentication mechanisms, operators should confirm that
implementations can support re-keying mechanisms that do not cause implementations can support re-keying mechanisms that do not cause
outages. There have been instances where any re-keying causes outages. There have been instances where any re-keying causes
outages and therefore, the tradeoff between utilizing this outages and therefore, the tradeoff between utilizing this
functionality needs to be weighed against the protection it provides. functionality needs to be weighed against the protection it provides.
[RFC4107] documents some guidelines for crypto keys management.
2.5.3. Securing Routing Updates 2.5.3. Securing Routing Updates
IPv6 initially mandated the provisioning of IPsec capability in all IPv6 initially mandated the provisioning of IPsec capability in all
nodes. However, in the updated IPv6 Nodes Requirement standard nodes. However, in the updated IPv6 Nodes Requirement standard
[RFC8504], IPsec is a 'SHOULD' and not a 'MUST' implement. [RFC8504], IPsec is a 'SHOULD' and not a 'MUST' implement.
Theoretically, it is possible that all communication between two IPv6 Theoretically, it is possible that all communication between two IPv6
nodes, especially routers exchanging routing information, is nodes, especially routers exchanging routing information, is
encrypted using IPsec. In practice however, deploying IPsec is not encrypted using IPsec. In practice however, deploying IPsec is not
always feasible given hardware and software limitations of the always feasible given hardware and software limitations of the
various platforms deployed. various platforms deployed.
Many routing protocols support the use of cryptography to protect the Many routing protocols support the use of cryptography to protect the
routing updates, the use of this protection is recommended; [RFC8177] routing updates, the use of this protection is recommended; [RFC8177]
is a YANG data model key chains including the renewal. is a YANG data model for key chains that includes re-keying
functionality.
2.5.4. Route Filtering 2.5.4. Route Filtering
Route filtering policies will be different depending on whether they Route filtering policies will be different depending on whether they
pertain to edge route filtering vs. internal route filtering. At a pertain to edge route filtering vs. internal route filtering. At a
minimum, IPv6 routing policy as it pertains to routing between minimum, IPv6 routing policy as it pertains to routing between
different administrative domains should aim to maintain parity with different administrative domains should aim to maintain parity with
IPv4 from a policy perspective, e.g., IPv4 from a policy perspective, e.g.,
o Filter internal-use, non-globally routable IPv6 addresses at the o Filter internal-use, non-globally routable IPv6 addresses at the
perimeter; perimeter;
o Discard routes for bogon [CYMRU] and reserved space (see o Discard routes for bogon [CYMRU] and reserved space (see
[RFC8190]); [RFC8190]);
o Configure ingress route filters that validate route origin, prefix o Configure ingress route filters that validate route origin, prefix
ownership, etc. through the use of various routing databases, ownership, etc. through the use of various routing databases,
e.g., [RADB]. There is additional work being done in this area to e.g., [RADB]. [RFC8210] formally validates the origin ASs of BGP
formally validate the origin ASs of BGP announcements in announcements.
[RFC8210].
Some good guidance can be found at [RFC7454]. Some good guidance can be found at [RFC7454].
A valid routing table can also be used to apply network ingress A valid routing table can also be used to apply network ingress
filtering (see [RFC2827]). filtering (see [RFC2827]).
2.6. Logging/Monitoring 2.6. Logging/Monitoring
In order to perform forensic research in the cases of a security In order to perform forensic research in the cases of a security
incident or detecting abnormal behavior, network operators should log incident or detecting abnormal behavior, network operators should log
multiple pieces of information. In some cases, this requires a multiple pieces of information. In some cases, this requires a
frequent poll of devices via a Network Management Station. frequent poll of devices via a Network Management Station.
This logging should include: This logging should include, but not limited to:
o logs of all applications using the network (including user space o logs of all applications using the network (including user space
and kernel space) when available (for example web servers); and kernel space) when available (for example web servers that the
network operator manages);
o data from IP Flow Information Export [RFC7011] also known as o data from IP Flow Information Export [RFC7011] also known as
IPFIX; IPFIX;
o data from various SNMP MIBs [RFC4293] or YANG data via RESTCONF o data from various SNMP MIBs [RFC4293] or YANG data via RESTCONF
[RFC8040] or NETCONF [RFC6241]; [RFC8040] or NETCONF [RFC6241];
o historical data of Neighbor Cache entries; o historical data of Neighbor Cache entries;
o stateful DHCPv6 [RFC8415] lease cache, especially when a relay o stateful DHCPv6 [RFC8415] lease cache, especially when a relay
agent [RFC6221] is used; agent [RFC6221] is used;
o Source Address Validation Improvement (SAVI) [RFC7039] events, o Source Address Validation Improvement (SAVI) [RFC7039] events,
especially the binding of an IPv6 address to a MAC address and a especially the binding of an IPv6 address to a MAC address and a
specific switch or router interface; specific switch or router interface;
o firewall ACL log;
o authentication server log;
o RADIUS [RFC2866] accounting records. o RADIUS [RFC2866] accounting records.
Please note that there are privacy issues or regulations related to Please note that there are privacy issues or regulations related to
how these logs are collected, stored, and safely discarded. how these logs are collected, stored, used, and safely discarded.
Operators are urged to check their country legislation (e.g., General Operators are urged to check their country legislation (e.g., General
Data Protection Regulation GDPR [GDPR] in the European Union). Data Protection Regulation GDPR [GDPR] in the European Union).
All those pieces of information can be used for: All those pieces of information can be used for:
o forensic (Section 2.6.2.1) investigations such as who did what and o forensic (Section 2.6.2.1) investigations such as who did what and
when? when?
o correlation (Section 2.6.2.3): which IP addresses were used by a o correlation (Section 2.6.2.3): which IP addresses were used by a
specific node (assuming the use of privacy extensions addresses specific node (assuming the use of privacy extensions addresses
skipping to change at page 22, line 50 skipping to change at page 23, line 31
o and many other ways including the reverse DNS mapping into a FQDN o and many other ways including the reverse DNS mapping into a FQDN
(which should not be trusted). (which should not be trusted).
[RFC5952] explains this problem in detail and recommends the use of a [RFC5952] explains this problem in detail and recommends the use of a
single canonical format. This document recommends the use of single canonical format. This document recommends the use of
canonical format [RFC5952] for IPv6 addresses in all possible cases. canonical format [RFC5952] for IPv6 addresses in all possible cases.
If the existing application cannot log using the canonical format, If the existing application cannot log using the canonical format,
then it is recommended to use an external post-processing program in then it is recommended to use an external post-processing program in
order to canonicalize all IPv6 addresses. order to canonicalize all IPv6 addresses.
For example, this perl script can be used:
<CODE BEGINS>
#!/usr/bin/perl -w
use strict ;
use warnings ;
use Socket ;
use Socket6 ;
my (@words, $word, $binary_address) ;
## go through the file one line at a time
while (my $line = <STDIN>) {
chomp $line;
foreach my $word (split /[\s+]/, $line) {
$binary_address = inet_pton AF_INET6, $word ;
if ($binary_address) {
print inet_ntop AF_INET6, $binary_address ;
} else {
print $word ;
}
print " " ;
}
print "\n" ;
}
<CODE ENDS>
2.6.1.2. IP Flow Information Export by IPv6 Routers 2.6.1.2. IP Flow Information Export by IPv6 Routers
IPFIX [RFC7012] defines some data elements that are useful for IPFIX [RFC7012] defines some data elements that are useful for
security: security:
o in section 5.4 (IP Header fields): nextHeaderIPv6 and o nextHeaderIPv6, sourceIPv6Address, and destinationIPv6Address;
sourceIPv6Address;
o in section 5.6 (Sub-IP fields): sourceMacAddress. o sourceMacAddress and destinationMacAddress.
The IP version is the ipVersion element defined in [IANA-IPFIX]. The IP version is the ipVersion element defined in [IANA-IPFIX].
Moreover, IPFIX is very efficient in terms of data handling and Moreover, IPFIX is very efficient in terms of data handling and
transport. It can also aggregate flows by a key such as transport. It can also aggregate flows by a key such as
sourceMacAddress in order to have aggregated data associated with a sourceMacAddress in order to have aggregated data associated with a
specific sourceMacAddress. This memo recommends the use of IPFIX and specific sourceMacAddress. This memo recommends the use of IPFIX and
aggregation on nextHeaderIPv6, sourceIPv6Address, and aggregation on nextHeaderIPv6, sourceIPv6Address, and
sourceMacAddress. sourceMacAddress.
skipping to change at page 24, line 24 skipping to change at page 24, line 24
o ipNetToPhysicalTable table which is the content of the Neighbor o ipNetToPhysicalTable table which is the content of the Neighbor
cache, i.e., the mapping between IPv6 and data-link layer cache, i.e., the mapping between IPv6 and data-link layer
addresses. addresses.
There are also YANG modules relating to the two IP addresses families There are also YANG modules relating to the two IP addresses families
and can be used with [RFC6241] and [RFC8040]. This memo recommends and can be used with [RFC6241] and [RFC8040]. This memo recommends
the use of: the use of:
o interfaces-state/interface/statistics from ietf- o interfaces-state/interface/statistics from ietf-
interfaces@2018-02-20.yang [RFC8343] which contains counters for interfaces@2018-02-20.yang [RFC8343] which contains counters for
interface . interfaces.
o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the
content of the Neighbor cache, i.e., the mapping between IPv6 and content of the Neighbor cache, i.e., the mapping between IPv6 and
data-link layer addresses. data-link layer addresses.
2.6.1.4. Neighbor Cache of IPv6 Routers 2.6.1.4. Neighbor Cache of IPv6 Routers
The neighbor cache of routers contains all mappings between IPv6 The neighbor cache of routers contains all mappings between IPv6
addresses and data-link layer addresses. There are multiple ways to addresses and data-link layer addresses. There are multiple ways to
collect the current entries in the Neighbor Cache, notably but not collect the current entries in the Neighbor Cache, notably but not
limited to: limited to:
o the SNMP MIB (Section 2.6.1.3) as explained above; o the SNMP MIB (Section 2.6.1.3) as explained above;
o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to o using streaming telemetry or NETCONF [RFC6241] and RESTCONF
collect the operational state of the neighbor cache; [RFC8040] to collect the operational state of the neighbor cache;
o also, by connecting over a secure management channel (such as SSH) o also, by connecting over a secure management channel (such as SSH)
and explicitly requesting a neighbor cache dump via the Command and explicitly requesting a neighbor cache dump via the Command
Line Interface (CLI) or another monitoring mechanism. Line Interface (CLI) or another monitoring mechanism.
The neighbor cache is highly dynamic as mappings are added when a new The neighbor cache is highly dynamic as mappings are added when a new
IPv6 address appears on the network. This could be quite frequently IPv6 address appears on the network. This could be quite frequently
with privacy extension addresses [RFC8981] or when they are removed with privacy extension addresses [RFC8981] or when they are removed
when the state goes from UNREACH to removed (the default time for a when the state goes from UNREACH to removed (the default time for a
removal per Neighbor Unreachability Detection [RFC4861] algorithm is removal per Neighbor Unreachability Detection [RFC4861] algorithm is
skipping to change at page 25, line 13 skipping to change at page 25, line 13
of the neighbor cache must periodically be fetched at an interval of the neighbor cache must periodically be fetched at an interval
which does not exhaust the router resources and still provides which does not exhaust the router resources and still provides
valuable information (suggested value is 30 seconds but this should valuable information (suggested value is 30 seconds but this should
be verified in the actual deployment) and stored for later use. be verified in the actual deployment) and stored for later use.
This is an important source of information because it is trivial (on This is an important source of information because it is trivial (on
a switch not using the SAVI [RFC7039] algorithm) to defeat the a switch not using the SAVI [RFC7039] algorithm) to defeat the
mapping between data-link layer address and IPv6 address. Let us mapping between data-link layer address and IPv6 address. Let us
rephrase the previous statement: having access to the current and rephrase the previous statement: having access to the current and
past content of the neighbor cache has a paramount value for the past content of the neighbor cache has a paramount value for the
forensic and audit trail. forensic and audit trail. It should also be noted that in certain
threat models this information is also deemed valuable and could
itself be a target.
When using one /64 per host (Section 2.1.7) or DHCP-PD, it is When using one /64 per host (Section 2.1.8) or DHCP-PD, it is
sufficient to keep the history of the allocated prefixes when sufficient to keep the history of the allocated prefixes when
combined with strict source address prefix enforcement on the routers combined with strict source address prefix enforcement on the routers
and layer-2 switches to prevent IPv6 spoofing. and layer-2 switches to prevent IPv6 spoofing.
2.6.1.5. Stateful DHCPv6 Lease 2.6.1.5. Stateful DHCPv6 Lease
In some networks, IPv6 addresses/prefixes are managed by a stateful In some networks, IPv6 addresses/prefixes are managed by a stateful
DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to
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
tempting to use this DHCP lease file to discover the mapping between tempting to use this DHCP lease file to discover the mapping between
IPv6 addresses/prefixes and data-link layer addresses as is commonly IPv6 addresses/prefixes and data-link layer addresses as is commonly
used in IPv4 networking. used in IPv4 networking.
It is not so easy in the IPv6 networks because not all nodes will use It is not so easy in the IPv6 networks, because not all nodes will
DHCPv6 (there are nodes which can only do stateless use DHCPv6 (there are nodes which can only do stateless
autoconfiguration) but also because DHCPv6 clients are identified not autoconfiguration) but also because DHCPv6 clients are identified not
by their hardware-client address as in IPv4 but by a DHCP Unique ID by their hardware-client address as in IPv4 but by a DHCP Unique ID
(DUID) which can have several formats: some being the data-link layer (DUID), which can have several formats: some being the data-link
address, some being data-link layer address prepended with time layer address, some being data-link layer address prepended with time
information, or even an opaque number which is useless for information, or even an opaque number that requires correlation with
operational security. Moreover, when the DUID is based on the data- another data source to be usable for operational security. Moreover,
link address, this address can be of any client interface (such as when the DUID is based on the data-link address, this address can be
the wireless interface while the client actually uses its wired of any client interface (such as the wireless interface while the
interface to connect to the network). client actually uses its wired interface to connect to the network).
If a lightweight DHCP relay agent [RFC6221] is used in a layer-2 If a lightweight DHCP relay agent [RFC6221] is used in a layer-2
switch, then the DHCP servers also receive the Interface-ID switch, then the DHCP servers also receive the Interface-ID
information which could be saved in order to identify the interface information which could be saved in order to identify the interface
on which the switch received a specific leased IPv6 address. Also, on which the switch received a specific leased IPv6 address. Also,
if a 'normal' (not lightweight) relay agent adds the data-link layer if a 'normal' (not lightweight) relay agent adds the data-link layer
address in the option for Relay Agent Remote-ID [RFC4649] or address in the option for Relay Agent Remote-ID [RFC4649] or
[RFC6939], then the DHCPv6 server can keep track of the data-link and [RFC6939], then the DHCPv6 server can keep track of the data-link and
leased IPv6 addresses. leased IPv6 addresses.
skipping to change at page 26, line 21 skipping to change at page 26, line 24
address is protected by using a layer-2 mechanism such as address is protected by using a layer-2 mechanism such as
[IEEE-802.1X]. [IEEE-802.1X].
2.6.1.6. RADIUS Accounting Log 2.6.1.6. RADIUS Accounting Log
For interfaces where the user is authenticated via a RADIUS [RFC2866] For interfaces where the user is authenticated via a RADIUS [RFC2866]
server, and if RADIUS accounting is enabled, then the RADIUS server server, and if RADIUS accounting is enabled, then the RADIUS server
receives accounting Acct-Status-Type records at the start and at the receives accounting Acct-Status-Type records at the start and at the
end of the connection which include all IPv6 (and IPv4) addresses end of the connection which include all IPv6 (and IPv4) addresses
used by the user. This technique can be used notably for Wi-Fi 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 networks with Wi-Fi Protected Address (WPA) or other IEEE 802.1X
[IEEE-802.1X] wired interface on an Ethernet switch. [IEEE-802.1X] wired interface on an Ethernet switch.
2.6.1.7. Other Data Sources 2.6.1.7. Other Data Sources
There are other data sources for log information that must be There are other data sources for log information that must be
collected (as currently collected in IPv4 networks): collected (as currently collected in IPv4 networks):
o historical mapping of IPv6 addresses to users of remote access o historical mapping of IPv6 addresses to users of remote access
VPN; VPN;
skipping to change at page 26, line 44 skipping to change at page 26, line 47
2.6.2. Use of Collected Data 2.6.2. Use of Collected Data
This section leverages the data collected as described before This section leverages the data collected as described before
(Section 2.6.1) in order to achieve several security benefits. (Section 2.6.1) in order to achieve several security benefits.
Section 9.1 of [RFC7934] contains more details about host tracking. Section 9.1 of [RFC7934] contains more details about host tracking.
2.6.2.1. Forensic and User Accountability 2.6.2.1. Forensic and User Accountability
The forensic use case is when the network operator must locate an 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 IPv6 address (and the assocated port, access point/switch, or VPN
tunnel) that was present in the network at a certain time or is
currently in the network. currently in the network.
To locate an IPv6 address in an enterprise network where the operator To locate an IPv6 address in an enterprise network where the operator
has control over all resources, the source of information can be the has control over all resources, the source of information can be the
neighbor cache, or, if not found, the DHCP lease file. Then, the neighbor cache, or, if not found, the DHCP lease file. Then, the
procedure is: procedure is:
1. Based on the IPv6 prefix of the IPv6 address, find the router(s) 1. Based on the IPv6 prefix of the IPv6 address, find the router(s)
which is(are) used to reach this prefix (assuming that anti- which is(are) used to reach this prefix (assuming that anti-
spoofing mechanisms are used). spoofing mechanisms are used) perhaps based on an IPAM.
2. Based on this limited set of routers, on the incident time and on 2. Based on this limited set of routers, on the incident time and on
the IPv6 address, retrieve the data-link address from the live the IPv6 address, retrieve the data-link address from the live
neighbor cache, from the historical neighbor cache data, or from neighbor cache, from the historical neighbor cache data, or from
SAVI events, or retrieve the data-link address from the DHCP SAVI events, or retrieve the data-link address from the DHCP
lease file (Section 2.6.1.5). lease file (Section 2.6.1.5).
3. Based on the data-link layer address, look-up the switch 3. Based on the data-link layer address, look-up the switch
interface associated with the data-link layer address. In the interface associated with the data-link layer address. In the
case of wireless LAN with RADIUS accounting (see case of wireless LAN with RADIUS accounting (see
skipping to change at page 27, line 31 skipping to change at page 27, line 33
the data-link layer address to a switch port. the data-link layer address to a switch port.
At the end of the process, the interface of the host originating, or At the end of the process, the interface of the host originating, or
the subscriber identity associated with, the activity in question has the subscriber identity associated with, the activity in question has
been determined. been determined.
To identify the subscriber of an IPv6 address in a residential To identify the subscriber of an IPv6 address in a residential
Internet Service Provider, the starting point is the DHCP-PD leased Internet Service Provider, the starting point is the DHCP-PD leased
prefix covering the IPv6 address; this prefix can often be linked to prefix covering the IPv6 address; this prefix can often be linked to
a subscriber via the RADIUS log. Alternatively, the Forwarding a subscriber via the RADIUS log. Alternatively, the Forwarding
Information Base of the CMTS or BNG indicates the CPE of the Information Base (FIB) of the Cable Modem Termination System (CMTS)
or Broadband Network Gateway (BNG) indicates the CPE of the
subscriber and the RADIUS log can be used to retrieve the actual subscriber and the RADIUS log can be used to retrieve the actual
subscriber. subscriber.
More generally, a mix of the above techniques can be used in most, if More generally, a mix of the above techniques can be used in most, if
not all, networks. not all, networks.
2.6.2.2. Inventory 2.6.2.2. Inventory
RFC 7707 [RFC7707] describes the difficulties for an attacker to scan RFC 7707 [RFC7707] describes the difficulties for an attacker to scan
an IPv6 network due to the vast number of IPv6 addresses per link an IPv6 network due to the vast number of IPv6 addresses per link
(and why in some cases it can still be done). While the huge (and why in some cases it can still be done). While the huge
addressing space can sometimes be perceived as a 'protection', it addressing space can sometimes be perceived as a 'protection', it
also makes the inventory task difficult in an IPv6 network while it also makes the inventory task difficult in an IPv6 network while it
was trivial to do in an IPv4 network (a simple enumeration of all was trivial to do in an IPv4 network (a simple enumeration of all
IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting
an inventory of all connected devices is of prime importance for a an inventory of all connected devices is of prime importance for a
secure network operation. secure network operation.
There are many ways to do an inventory of an IPv6 network. There are many ways to do an inventory of an IPv6 network.
The first technique is to use the IPFIX information and extract the The first technique is to use passive inspection such as IPFIX.
list of all IPv6 source addresses to find all IPv6 nodes that sent Using exported IPFIX information and extracting the list of all IPv6
packets through a router. This is very efficient but, alas, will not source addresses allows finding all IPv6 nodes that sent packets
through a router. This is very efficient but, alas, will not
discover silent nodes that never transmitted packets traversing the discover silent nodes that never transmitted packets traversing the
IPFIX target router. Also, it must be noted that link-local IPFIX target router. Also, it must be noted that link-local
addresses will never be discovered by this means. addresses will never be discovered by this means.
The second way is again to use the collected neighbor cache content The second way is again to use the collected neighbor cache content
to find all IPv6 addresses in the cache. This process will also to find all IPv6 addresses in the cache. This process will also
discover all link-local addresses. See Section 2.6.1.4. discover all link-local addresses. See Section 2.6.1.4.
Another way that works only for a local network, consists of sending Another way that works only for a local network, consists of sending
a ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which a ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which
skipping to change at page 28, line 29 skipping to change at page 28, line 32
this ECHO_REQUEST per [RFC4443]. this ECHO_REQUEST per [RFC4443].
Other techniques involve obtaining data from DNS, parsing log files, Other techniques involve obtaining data from DNS, parsing log files,
leveraging service discovery such as mDNS [RFC6762] and [RFC6763]. leveraging service discovery such as mDNS [RFC6762] and [RFC6763].
Enumerating DNS zones, especially looking at reverse DNS records and Enumerating DNS zones, especially looking at reverse DNS records and
CNAMES, is another common method employed by various tools. As CNAMES, is another common method employed by various tools. As
already mentioned in [RFC7707], this allows an attacker to prune the already mentioned in [RFC7707], this allows an attacker to prune the
IPv6 reverse DNS tree, and hence enumerate it in a feasible time. IPv6 reverse DNS tree, and hence enumerate it in a feasible time.
Furthermore, authoritative servers that allow zone transfers (AXFR) Furthermore, authoritative servers that allow zone transfers (AXFR)
may be a further information source. may be a further information source. An interesting research paper
has analysed the entropy in various IPv6 addresses: see [ENTROPYIP].
2.6.2.3. Correlation 2.6.2.3. Correlation
In an IPv4 network, it is easy to correlate multiple logs, for In an IPv4 network, it is easy to correlate multiple logs, for
example to find events related to a specific IPv4 address. A simple example to find events related to a specific IPv4 address. A simple
Unix grep command is enough to scan through multiple text-based files Unix grep command is enough to scan through multiple text-based files
and extract all lines relevant to a specific IPv4 address. and extract all lines relevant to a specific IPv4 address.
In an IPv6 network, this is slightly more difficult because different In an IPv6 network, this is slightly more difficult because different
character strings can express the same IPv6 address. Therefore, the character strings can express the same IPv6 address. Therefore, the
simple Unix grep command cannot be used. Moreover, an IPv6 node can simple Unix grep command cannot be used. Moreover, an IPv6 node can
have multiple IPv6 addresses. have multiple IPv6 addresses.
In order to do correlation in IPv6-related logs, it is advised to In order to do correlation in IPv6-related logs, it is advised to
have all logs in a format with only canonical IPv6 addresses have all logs in a format with only canonical IPv6 addresses
[RFC5952]. Then, the neighbor cache current (or historical) data set [RFC5952]. Then, the neighbor cache current (or historical) data set
must be searched to find the data-link layer address of the IPv6 must be searched to find the data-link layer address of the IPv6
address. Then, the current and historical neighbor cache data sets address. Then, the current and historical neighbor cache data sets
must be searched for all IPv6 addresses associated to this data-link must be searched for all IPv6 addresses associated with this data-
layer address to derive the search set. The last step is to search link layer address to derive the search set. The last step is to
in all log files (containing only IPv6 address in canonical format) search in all log files (containing only IPv6 addresses in canonical
for any IPv6 addresses in the search set. format) for any IPv6 addresses in the search set.
Moreover, [RFC7934] recommends using multiple IPv6 addresses per Moreover, [RFC7934] recommends using multiple IPv6 addresses per
prefix, so, the correlation must also be done among those multiple prefix, so, the correlation must also be done among those multiple
IPv6 addresses, for example by discovering in the NDP cache IPv6 addresses, for example by discovering in the NDP cache
(Section 2.6.1.4) all IPv6 addresses associated with the same MAC (Section 2.6.1.4) all IPv6 addresses associated with the same MAC
address and interface. address and interface.
2.6.2.4. Abnormal Behavior Detection 2.6.2.4. Abnormal Behavior Detection
Abnormal behavior (such as network scanning, spamming, denial-of- Abnormal behavior (such as network scanning, spamming, denial-of-
service) can be detected in the same way as in an IPv4 network. service) can be detected in the same way as in an IPv4 network.
o Sudden increase of traffic detected by interface counter (SNMP) or o Sudden increase of traffic detected by interface counter (SNMP) or
by aggregated traffic from IPFIX records [RFC7012]. by aggregated traffic from IPFIX records [RFC7012].
o Rapid growth of ND cache size.
o Change in traffic pattern (number of connections per second, o Change in traffic pattern (number of connections per second,
number of connections per host...) observed with the use of IPFIX number of connections per host...) observed with the use of IPFIX
[RFC7012]. [RFC7012].
2.6.3. Summary 2.6.3. Summary
While some data sources (IPFIX, MIB, switch CAM tables, logs, ...) While some data sources (IPFIX, MIB, switch CAM tables, logs, ...)
used in IPv4 are also used in the secure operation of an IPv6 used in IPv4 are also used in the secure operation of an IPv6
network, the DHCPv6 lease file is less reliable and the neighbor network, the DHCPv6 lease file is less reliable and the neighbor
cache is of prime importance. cache is of prime importance.
skipping to change at page 29, line 40 skipping to change at page 29, line 45
The fact that there are multiple ways to express the same IPv6 The fact that there are multiple ways to express the same IPv6
address in a character string renders the use of filters mandatory address in a character string renders the use of filters mandatory
when correlation must be done. when correlation must be done.
2.7. Transition/Coexistence Technologies 2.7. Transition/Coexistence Technologies
As it is expected that some networks will not run in a pure IPv6-only As it is expected that some networks will not run in a pure IPv6-only
mode, the different transition mechanisms must be deployed and mode, the different transition mechanisms must be deployed and
operated in a secure way. This section proposes operational operated in a secure way. This section proposes operational
guidelines for the most known and deployed transition techniques. guidelines for the most known and deployed transition techniques.
[RFC4942] also contains security considerations for transition or
coexistence scenarios.
2.7.1. Dual Stack 2.7.1. Dual Stack
Dual stack is often the first deployment choice for network Dual stack is often the first deployment choice for network
operators. Dual stacking the network offers some advantages over operators. Dual stacking the network offers some advantages over
other transition mechanisms. Firstly, the impact on existing IPv4 other transition mechanisms. Firstly, the impact on existing IPv4
operations is reduced. Secondly, in the absence of tunnels or operations is reduced. Secondly, in the absence of tunnels or
address translation, the IPv4 and IPv6 traffic are native (easier to address translation, the IPv4 and IPv6 traffic are native (easier to
observe and secure) and should have the same network processing observe and secure) and should have the same network processing
(network path, quality of service, ...). Dual stack enables a (network path, quality of service, ...). Dual stack enables a
skipping to change at page 30, line 14 skipping to change at page 30, line 27
From an operational security perspective, this now means that the From an operational security perspective, this now means that the
network operator has twice the exposure. One needs to think about network operator has twice the exposure. One needs to think about
protecting both protocols now. At a minimum, the IPv6 portion of a protecting both protocols now. At a minimum, the IPv6 portion of a
dual-stacked network should be consistent with IPv4 from a security dual-stacked network should be consistent with IPv4 from a security
policy point of view. Typically, the following methods are employed policy point of view. Typically, the following methods are employed
to protect IPv4 networks at the edge or security perimeter: to protect IPv4 networks at the edge or security perimeter:
o ACLs to permit or deny traffic; o ACLs to permit or deny traffic;
o Firewalls with stateful packet inspection. o Firewalls with stateful packet inspection;
o Application firewalls inspecting the application flows.
It is recommended that these ACLs and/or firewalls be additionally It is recommended that these ACLs and/or firewalls be additionally
configured to protect IPv6 communications. The enforced IPv6 configured to protect IPv6 communications. The enforced IPv6
security must be congruent with the IPv4 security policy, otherwise security must be congruent with the IPv4 security policy, otherwise
the attacker will use the protocol version having the more relaxed the attacker will use the protocol version having the more relaxed
security policy. Maintaining the congruence between security security policy. Maintaining the congruence between security
policies can be challenging (especially over time); it is recommended policies can be challenging (especially over time); it is recommended
to use a firewall or an ACL manager that is dual-stack, i.e., a to use a firewall or an ACL manager that is dual-stack, i.e., a
system that can apply a single ACL entry to a mixed group of IPv4 and system that can apply a single ACL entry to a mixed group of IPv4 and
IPv6 addresses. IPv6 addresses.
Application firewalls work at the application layer and are oblivious
to the IP version, i.e., they work as well for IPv6 as for IPv4 and
the same application security policy will work for both protocol
versions.
Also, given the end-to-end connectivity that IPv6 provides, it is Also, given the end-to-end connectivity that IPv6 provides, it is
recommended that hosts be fortified against threats. General device recommended that hosts be fortified against threats. General device
hardening guidelines are provided in Section 2.8. hardening guidelines are provided in Section 2.8.
For many years, all host operating systems have IPv6 enabled by For many years, all host operating systems have IPv6 enabled by
default, so, it is possible even in an 'IPv4-only' network to attack default, so, it is possible even in an 'IPv4-only' network to attack
layer-2 adjacent victims via their IPv6 link-local address or via a layer-2 adjacent victims via their IPv6 link-local address or via a
global IPv6 address when the attacker provides rogue RAs or a rogue global IPv6 address when the attacker provides rogue RAs or a rogue
DHCPv6 service. DHCPv6 service.
[RFC7123] discusses the security implications of native IPv6 support [RFC7123] discusses the security implications of native IPv6 support
and IPv6 transition/coexistence technologies on "IPv4-only" networks and IPv6 transition/coexistence technologies on "IPv4-only" networks
and describes possible mitigations for the aforementioned issues. and describes possible mitigations for the aforementioned issues.
2.7.2. Encapsulation Mechanisms 2.7.2. Encapsulation Mechanisms
There are many tunnels used for specific use cases. Except when There are many tunnels used for specific use cases. Except when
protected by IPsec [RFC4301], all those tunnels have a couple of protected by IPsec [RFC4301] or alternative tunnel encryption
security issues as described in RFC 6169 [RFC6169]; methods, all those tunnels have a number of security issues as
described in RFC 6169 [RFC6169];
o tunnel injection: a malevolent actor knowing a few pieces of o tunnel injection: a malevolent actor knowing a few pieces of
information (for example the tunnel endpoints and the information (for example the tunnel endpoints and the
encapsulation protocol) can forge a packet which looks like a encapsulation protocol) can forge a packet which looks like a
legitimate and valid encapsulated packet that will gladly be legitimate and valid encapsulated packet that will gladly be
accepted by the destination tunnel endpoint. This is a specific accepted by the destination tunnel endpoint. This is a specific
case of spoofing; case of spoofing;
o traffic interception: no confidentiality is provided by the tunnel o traffic interception: no confidentiality is provided by the tunnel
protocols (without the use of IPsec or alternative encryption protocols (without the use of IPsec or alternative encryption
skipping to change at page 31, line 23 skipping to change at page 31, line 43
user can use a tunnel relay for free (this is a specific case of user can use a tunnel relay for free (this is a specific case of
tunnel injection); tunnel injection);
o reflection attack: another specific use case of tunnel injection o reflection attack: another specific use case of tunnel injection
where the attacker injects packets with an IPv4 destination where the attacker injects packets with an IPv4 destination
address not matching the IPv6 address causing the first tunnel address not matching the IPv6 address causing the first tunnel
endpoint to re-encapsulate the packet to the destination... Hence, endpoint to re-encapsulate the packet to the destination... Hence,
the final IPv4 destination will not see the original IPv4 address the final IPv4 destination will not see the original IPv4 address
but only the IPv4 address of the relay router. but only the IPv4 address of the relay router.
o bypassing security policy: if a firewall or an IPS is on the path o bypassing security policy: if a firewall or an Intrusion
of the tunnel, then it may neither inspect nor detect malevolent Prevention System (IPS) is on the path of the tunnel, then it may
IPv6 traffic transmitted over the tunnel. neither inspect nor detect malevolent IPv6 traffic transmitted
over the tunnel.
To mitigate the bypassing of security policies, it is recommended to To mitigate the bypassing of security policies, it is often
block all default configuration tunnels by denying IPv4 packets recommended to block all automatic tunnels in default OS
configuration (if they are not required) by denying IPv4 packets
matching: matching:
o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4
(Section 2.7.2.7), 6rd (Section 2.7.2.3), as well as, 6in4 (Section 2.7.2.7), 6rd (Section 2.7.2.3), as well as, 6in4
(Section 2.7.2.1) tunnels; (Section 2.7.2.1) tunnels;
o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels;
o UDP protocol 3544: this will block the default encapsulation of o UDP port 3544: this will block the default encapsulation of Teredo
Teredo (Section 2.7.2.8) tunnels. (Section 2.7.2.8) tunnels.
Ingress filtering [RFC2827] should also be applied on all tunnel Ingress filtering [RFC2827] should also be applied on all tunnel
endpoints if applicable to prevent IPv6 address spoofing. endpoints if applicable to prevent IPv6 address spoofing.
The reflection attack cited above should also be prevented by using
an IPv6 ACL preventing the hair pinning of the traffic.
As several of the tunnel techniques share the same encapsulation As several of the tunnel techniques share the same encapsulation
(i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6 (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6
address, there are a set of well-known looping attacks described in address, there are a set of well-known looping attacks described in
RFC 6324 [RFC6324]. This RFC also proposes mitigation techniques. RFC 6324 [RFC6324]. This RFC also proposes mitigation techniques.
2.7.2.1. Site-to-Site Static Tunnels 2.7.2.1. Site-to-Site Static Tunnels
Site-to-site static tunnels are described in RFC 2529 [RFC2529] and Site-to-site static tunnels are described in RFC 2529 [RFC2529] and
in GRE [RFC2784]. As the IPv4 endpoints are statically configured in GRE [RFC2784]. As the IPv4 endpoints are statically configured
and are not dynamic, they are slightly more secure (bi-directional and are not dynamic, they are slightly more secure (bi-directional
service theft is mostly impossible) but traffic interception and service theft is mostly impossible) but traffic interception and
tunnel injection are still possible. Therefore, the use of IPsec tunnel injection are still possible. Therefore, the use of IPsec
[RFC4301] in transport mode and protecting the encapsulated IPv4 [RFC4301] in transport mode to protect the encapsulated IPv4 packets
packets is recommended for those tunnels. Alternatively, IPsec in is recommended for those tunnels. Alternatively, IPsec in tunnel
tunnel mode can be used to transport IPv6 traffic over a non-trusted mode can be used to transport IPv6 traffic over a non-trusted IPv4
IPv4 network. network.
2.7.2.2. ISATAP 2.7.2.2. ISATAP
ISATAP tunnels [RFC5214] are mainly used within a single ISATAP tunnels [RFC5214] are mainly used within a single
administrative domain and to connect a single IPv6 host to the IPv6 administrative domain and to connect a single IPv6 host to the IPv6
network. This often implies that those systems are usually managed network. This often implies that those systems are usually managed
by a single entity; therefore, audit trail and strict anti-spoofing by a single entity; therefore, audit trail and strict anti-spoofing
are usually possible and this raises the overall security. are usually possible and this raises the overall security. Even if
ISATAP is no more often used, its security issues are relevant per
[KRISTOFF].
Special care must be taken to avoid a looping attack by implementing Special care must be taken to avoid a looping attack by implementing
the measures of [RFC6324] and [RFC6964]. the measures of [RFC6324] and [RFC6964] (especially the section 3.6).
IPsec [RFC4301] in transport or tunnel mode can be used to secure the IPsec [RFC4301] in transport or tunnel mode can be used to secure the
IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and
prevent service theft. prevent service theft.
2.7.2.3. 6rd 2.7.2.3. 6rd
While 6rd tunnels share the same encapsulation as 6to4 tunnels 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 (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 domain, in other words, they are deployed in a more constrained
environment than 6to4 tunnels and have few security issues other than environment (e.g., anti-spoofing, protocol 41 filtering at the edge)
lack of confidentiality. The security considerations (Section 12) of than 6to4 tunnels and have few security issues other than lack of
confidentiality. The security considerations (Section 12) of
[RFC5969] describes how to secure 6rd tunnels. [RFC5969] describes how to secure 6rd tunnels.
IPsec [RFC4301] for the transported IPv6 traffic can be used if IPsec [RFC4301] for the transported IPv6 traffic can be used if
confidentiality is important. confidentiality is important.
2.7.2.4. 6PE, 6VPE, and LDPv6 2.7.2.4. 6PE, 6VPE, and LDPv6
Organizations using MPLS in their core can also use 6PE [RFC4798] and 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 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are
really similar to BGP/MPLS IP VPNs described in [RFC4364], the really similar to BGP/MPLS IP VPNs described in [RFC4364], the
security properties of these networks are also similar to those security properties of these networks are also similar to those
described in [RFC4381]. They rely on: described in [RFC4381] (please note that this RFC may resemble a
published IETF work but it is not based on an IETF review and the
IETF disclaims any knowledge of the fitness of this RFC for any
purpose). They rely on:
o Address space, routing, and traffic separation with the help of o Address space, routing, and traffic separation with the help of
VRFs (only applicable to 6VPE); VRFs (only applicable to 6VPE);
o Hiding the IPv4 core, hence removing all attacks against o Hiding the IPv4 core, hence removing all attacks against
P-routers; P-routers;
o Securing the routing protocol between CE and PE; in the case of o Securing the routing protocol between CE and PE; in the case of
6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and
as these addresses cannot be reached from outside of the link, the as these addresses cannot be reached from outside of the link, the
skipping to change at page 33, line 26 skipping to change at page 34, line 7
further (Section 2.7.3.3) in this document as it includes IPv4 NAPT. further (Section 2.7.3.3) in this document as it includes IPv4 NAPT.
2.7.2.6. Mapping of Address and Port 2.7.2.6. Mapping of Address and Port
With the encapsulation and translation versions of mapping of Address With the encapsulation and translation versions of mapping of Address
and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access
network is purely an IPv6 network and MAP protocols are used to network is purely an IPv6 network and MAP protocols are used to
provide IPv4 hosts on the subscriber network access to IPv4 hosts on provide IPv4 hosts on the subscriber network access to IPv4 hosts on
the Internet. The subscriber router does stateful operations in the Internet. The subscriber router does stateful operations in
order to map all internal IPv4 addresses and layer-4 ports to the order to map all internal IPv4 addresses and layer-4 ports to the
IPv4 address and the set of layer-4 ports received through MAP IPv4 address and the set of layer-4 ports received through the MAP
configuration process. The SP equipment always does stateless configuration process. The SP equipment always does stateless
operations (either decapsulation or stateless translation). operations (either decapsulation or stateless translation).
Therefore, as opposed to Section 2.7.3.3, there is no state- Therefore, as opposed to Section 2.7.3.3, there is no state-
exhaustion DoS attack against the SP equipment because there is no exhaustion DoS attack against the SP equipment because there is no
state and there is no operation caused by a new layer-4 connection state and there is no operation caused by a new layer-4 connection
(no logging operation). (no logging operation).
The SP MAP equipment should implement all the security considerations The SP MAP equipment should implement all the security considerations
of [RFC7597]; notably, ensuring that the mapping of the IPv4 address of [RFC7597]; notably, ensuring that the mapping of the IPv4 address
and port are consistent with the configuration. As MAP has a and port are consistent with the configuration. As MAP has a
predictable IPv4 address and port mapping, the audit logs are easier predictable IPv4 address and port mapping, the audit logs are easier
to manage. to use as there is a clear mapping between the IPv6 address and the
IPv4 address and ports.
2.7.2.7. 6to4 2.7.2.7. 6to4
6to4 tunnels [RFC3056] require a public routable IPv4 address in In [RFC3056]; 6to4 tunnels require a public routable IPv4 address in
order to work correctly. They can be used to provide either single order to work correctly. They can be used to provide either single
IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks
connectivity to the IPv6 Internet. The 6to4 relay was historically connectivity to the IPv6 Internet. The 6to4 relay was historically
the anycast address defined in [RFC3068] which has been deprecated by the anycast address defined in [RFC3068] which has been deprecated by
[RFC7526] and is no longer used by recent Operating Systems. Some [RFC7526] and is no longer used by recent Operating Systems. Some
security considerations are explained in [RFC3964]. security considerations are explained in [RFC3964].
[RFC6343] points out that if an operator provides well-managed [RFC6343] points out that if an operator provides well-managed
servers and relays for 6to4, non-encapsulated IPv6 packets will pass servers and relays for 6to4, non-encapsulated IPv6 packets will pass
through well-defined points (the native IPv6 interfaces of those through well-defined points (the native IPv6 interfaces of those
skipping to change at page 34, line 25 skipping to change at page 35, line 8
attacks. attacks.
IPsec [RFC4301] for the transported IPv6 traffic is recommended. IPsec [RFC4301] for the transported IPv6 traffic is recommended.
The biggest threat to Teredo is probably for an IPv4-only network as The biggest threat to Teredo is probably for an IPv4-only network as
Teredo has been designed to easily traverse IPv4 NAT-PT devices which Teredo has been designed to easily traverse IPv4 NAT-PT devices which
are quite often co-located with a stateful firewall. Therefore, if are quite often co-located with a stateful firewall. Therefore, if
the stateful IPv4 firewall allows unrestricted UDP outbound and the stateful IPv4 firewall allows unrestricted UDP outbound and
accepts the return UDP traffic, then Teredo actually punches a hole accepts the return UDP traffic, then Teredo actually punches a hole
in this firewall for all IPv6 traffic to the Internet and from the in this firewall for all IPv6 traffic to the Internet and from the
Internet. While host policies can be deployed to block Teredo in an Internet. Host policies can be deployed to block Teredo in an
IPv4-only network in order to avoid this firewall bypass, it would be IPv4-only network in order to avoid this firewall bypass. On the
enough to block all UDP outbound traffic at the IPv4 firewall if IPv4 firewall all outbound UDP should be blocked except for the
deemed possible (of course, at least port 53 should be left open for commonly used services (e.g., port 53 for DNS, port 123 for NTP, port
DNS traffic, port 123 for NTP, port 443 for QUIC, port 500 for IKE, 443 for QUIC, port 500 for IKE, port 3478 for STUN, etc.).
port 3478 for STUN, i.e., filter judiciously).
Teredo is now hardly never used and no longer enabled by default in Teredo is now hardly ever used and no longer enabled by default in
most environments, so, it is less of a threat, however, special most environments, so it is less of a threat, however, special
consideration must be taken in case of devices with older or non- consideration must be taken in cases when devices with older or non-
updated operating systems may be present and by default were running updated operating systems may be present and by default were running
Teredo. Teredo.
2.7.3. Translation Mechanisms 2.7.3. Translation Mechanisms
Translation mechanisms between IPv4 and IPv6 networks are alternate Translation mechanisms between IPv4 and IPv6 networks are alternate
coexistence strategies while networks transition to IPv6. While a coexistence strategies while networks transition to IPv6. While a
framework is described in [RFC6144], the specific security framework is described in [RFC6144], the specific security
considerations are documented with each individual mechanism. For considerations are documented with each individual mechanism. For
the most part, they specifically mention interference with IPsec or the most part, they specifically mention interference with IPsec or
skipping to change at page 35, line 50 skipping to change at page 36, line 32
Stateful NAT64 translation [RFC6146] allows IPv6-only clients to Stateful NAT64 translation [RFC6146] allows IPv6-only clients to
contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used
in conjunction with DNS64 [RFC6147], a mechanism which synthesizes in conjunction with DNS64 [RFC6147], a mechanism which synthesizes
AAAA records from existing A records. There is also a stateless AAAA records from existing A records. There is also a stateless
NAT64 [RFC7915], which has similar security aspects but with the NAT64 [RFC7915], which has similar security aspects but with the
added benefit of being stateless, so, less prone to a state added benefit of being stateless, so, less prone to a state
exhaustion attack. exhaustion attack.
The Security Consideration sections of [RFC6146] and [RFC6147] list The Security Consideration sections of [RFC6146] and [RFC6147] list
the comprehensive issues. A specific issue with the use of NAT64 is the comprehensive issues; in section 8 of [RFC6147] there are some
that it will interfere with most IPsec deployments unless UDP considerations on the interaction between NAT64 and DNSSEC. A
encapsulation is used. DNSSEC and DNS64 negatively interact, see specific issue with the use of NAT64 is that it will interfere with
section 3.1 of [RFC7050]. most IPsec deployments unless UDP encapsulation is used.
Another translation mechanism relying on a combination of stateful Another translation mechanism relying on a combination of stateful
and stateless translation, 464XLAT [RFC6877], can be used to do host and stateless translation, 464XLAT [RFC6877], can be used to do host
local translation from IPv4 to IPv6 and a network provider local translation from IPv4 to IPv6 and a network provider
translation from IPv6 to IPv4, i.e., giving IPv4-only application translation from IPv6 to IPv4, i.e., giving IPv4-only application
access to an IPv4-only server over an IPv6-only network. 464XLAT access to an IPv4-only server over an IPv6-only network. 464XLAT
shares the same security considerations as NAT64 and DNS64, however shares the same security considerations as NAT64 and DNS64, however
it can be used without DNS64, avoiding the DNSSEC implications. it can be used without DNS64, avoiding the DNSSEC implications.
2.7.3.3. DS-Lite 2.7.3.3. DS-Lite
skipping to change at page 36, line 37 skipping to change at page 37, line 20
Section 11 of [RFC6333] and section 2 of [RFC7785] describe important Section 11 of [RFC6333] and section 2 of [RFC7785] describe important
security issues associated with this technology. security issues associated with this technology.
2.8. General Device Hardening 2.8. General Device Hardening
With almost all devices being IPv6 enabled by default and with many With almost all devices being IPv6 enabled by default and with many
end points having IPv6 connectivity to the Internet, it is critical end points having IPv6 connectivity to the Internet, it is critical
to also harden those devices against attacks over IPv6. to also harden those devices against attacks over IPv6.
The following guidelines should be used to ensure appropriate The ame techniques used to protect devices against attack over IPv4
hardening of the device, be it an individual host, router, firewall, should be used for IPv6 and should include, but not limited to:
load-balancer, server, etc. device.
o Restrict device access to authorized individuals o Restrict device access to authorized individuals
o Monitor and audit access to the device o Monitor and audit access to the device
o Turn off any unused services on the end node o Turn off any unused services on the end node
o Understand which IPv6 addresses are being used to source traffic o Understand which IPv6 addresses are being used to source traffic
and change defaults if necessary and change defaults if necessary
o Use cryptographically protected protocols for device management if o Use cryptographically protected protocols for device management
possible (SCP, SNMPv3, SSH, TLS, etc.) (SCP, SNMPv3, SSH, TLS, etc.)
o Use host firewall capabilities to control traffic that gets o Use host firewall capabilities to control traffic that gets
processed by upper-layer protocols processed by upper-layer protocols
o apply firmware, OS and application patches/upgrades to the devices
in a timely manner
o use multi-factor credentials to authenticate to devices
o Use virus scanners to detect malicious programs o Use virus scanners to detect malicious programs
3. Enterprises Specific Security Considerations 3. Enterprises Specific Security Considerations
Enterprises [RFC7381] generally have robust network security policies Enterprises [RFC7381] generally have robust network security policies
in place to protect existing IPv4 networks. These policies have been in place to protect existing IPv4 networks. These policies have been
distilled from years of experiential knowledge of securing IPv4 distilled from years of experiential knowledge of securing IPv4
networks. At the very least, it is recommended that enterprise networks. At the very least, it is recommended that enterprise
networks have parity between their security policies for both networks have parity between their security policies for both
protocol versions. This section also applies to the enterprise part protocol versions. This section also applies to the enterprise part
skipping to change at page 37, line 38 skipping to change at page 38, line 24
provider's network. This is commonly achieved by enforcing a provider's network. This is commonly achieved by enforcing a
security policy either by implementing dedicated firewalls with security policy either by implementing dedicated firewalls with
stateful packet inspection or a router with ACLs. A common default stateful packet inspection or a router with ACLs. A common default
IPv4 policy on firewalls that could easily be ported to IPv6 is to IPv4 policy on firewalls that could easily be ported to IPv6 is to
allow all traffic outbound while only allowing specific traffic, such allow all traffic outbound while only allowing specific traffic, such
as established sessions, inbound (see also [RFC6092]). Section 3.2 as established sessions, inbound (see also [RFC6092]). Section 3.2
of [RFC7381] also provides similar recommendations. of [RFC7381] also provides similar recommendations.
Here are a few more things that could enhance the default policy: Here are a few more things that could enhance the default policy:
o Filter internal-use IPv6 addresses at the perimeter this will also o Filter internal-use IPv6 addresses at the perimeter, this will
mitigate the vulnerabilities listed in [RFC7359] also mitigate the vulnerabilities listed in [RFC7359]
o Discard packets from and to bogon and reserved space, see also o Discard packets from and to bogon and reserved space, see also
[CYMRU] and [RFC8190] [CYMRU] and [RFC8190]
o Accept certain ICMPv6 messages to allow proper operation of ND and o Accept certain ICMPv6 messages to allow proper operation of ND and
PMTUD, see also [RFC4890] or [REY_PF] for hosts PMTUD, see also [RFC4890] or [REY_PF] for hosts
o Filter specific extension headers by accepting only the required o Based on the use of the network, filter specific extension headers
ones (permit list approach) such as ESP, AH (not forgetting the by accepting only the required ones (permit list approach) such as
required transport layers: ICMP, TCP, UDP, ...), where possible at ESP, AH, and not forgetting the required transport layers: ICMP,
TCP, UDP, ... This filtering should be done where applicable at
the edge and possibly inside the perimeter; see also the edge and possibly inside the perimeter; see also
[I-D.ietf-opsec-ipv6-eh-filtering] [I-D.ietf-opsec-ipv6-eh-filtering]
o Filter packets having an illegal IPv6 headers chain at the o Filter packets having an illegal IPv6 headers chain at the
perimeter (and if possible, inside the network as well), see perimeter (and if possible, inside the network as well), see
Section 2.2 Section 2.2
o Filter unneeded services at the perimeter o Filter unneeded services at the perimeter
o Implement ingress and egress anti-spoofing in the forwarding and o Implement ingress and egress anti-spoofing in the forwarding and
control planes, see [RFC2827] and [RFC3704] control planes, see [RFC2827] and [RFC3704]
o Implement appropriate rate-limiters and control-plane policers o Implement appropriate rate-limiters and control-plane policers
based on traffic baselines
Having global IPv6 address on all the enterprises sites is different Having global IPv6 addresses on all the enterprise sites is different
than in IPv4 where [RFC1918] addresses are often used internally and than in IPv4 where [RFC1918] addresses are often used internally and
not routed over the Internet. [RFC7359] and [WEBER_VPN] explain that not routed over the Internet. [RFC7359] and [WEBER_VPN] explain that
without careful design, there could be IPv6 leakages from layer-3 without careful design, there could be IPv6 leakages from layer-3
VPNs. VPNs.
3.2. Internal Security Considerations 3.2. Internal Security Considerations
The internal aspect deals with providing security inside the The internal aspect deals with providing security inside the
perimeter of the network, including end hosts. Internal networks of perimeter of the network, including end hosts. Internal networks of
enterprises are often different: University campus, wireless guest enterprises are often different: University campus, wireless guest
skipping to change at page 39, line 35 skipping to change at page 40, line 28
o Prefix filtering. o Prefix filtering.
These are explained in more detail in Section 2.5. Also, the These are explained in more detail in Section 2.5. Also, the
recommendations of [RFC7454] should be considered. recommendations of [RFC7454] should be considered.
4.1.1. Remote Triggered Black Hole Filtering (RTBH) 4.1.1. Remote Triggered Black Hole Filtering (RTBH)
RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has
allocated the 100::/64 prefix to be used as the discard prefix allocated the 100::/64 prefix to be used as the discard prefix
[RFC6666]. [RFC6666]
4.2. Transition/Coexistence Mechanism 4.2. Transition/Coexistence Mechanism
SPs will typically use transition mechanisms such as 6rd, 6PE, MAP, SPs will typically use transition mechanisms such as 6rd, 6PE, MAP,
and NAT64 which have been analyzed in the transition and coexistence and NAT64 which have been analyzed in the transition and coexistence
Section 2.7 section. Section 2.7 section.
4.3. Lawful Intercept 4.3. Lawful Intercept
The Lawful Intercept requirements are similar for IPv6 and IPv4 The Lawful Intercept requirements are similar for IPv6 and IPv4
architectures and will be subject to the laws enforced in different architectures and will be subject to the laws enforced in different
geographic regions. The local issues with each jurisdiction can make geographic regions. The local issues with each jurisdiction can make
this challenging and both corporate legal and privacy personnel this challenging and both corporate legal and privacy personnel
should be involved in discussions pertaining to what information gets should be involved in discussions pertaining to what information gets
logged and with regard to the respective log retention policies for logged and with regard to the respective log retention policies for
this information. this information.
The target of interception will usually be a residential subscriber The target of interception will usually be a residential subscriber
(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
the absence of IPv6 NAT on the CPE, IPv6 has the possibility to allow the absence of IPv6 NAT on the CPE, IPv6 has the possibility to allow
for intercepting the traffic from a single host (i.e., a /128 target) for intercepting the traffic from a single host (i.e., a /128 target)
rather than the whole set of hosts of a subscriber (which could be a rather than the whole set of hosts of a subscriber (which could be a
/48, /60, or /64). /48, /60, or /64).
In contrast, in mobile environments, since the 3GPP specifications In contrast, in mobile environments, since the 3GPP specifications
allocate a /64 per device, it may be sufficient to intercept traffic allocate a /64 per device, it may be sufficient to intercept traffic
from the /64 rather than specific /128's (since each time the device from the /64 rather than specific /128's (since each time the device
establishes a data connection it gets a new IID). establishes a data connection it gets a new IID).
A sample architecture which was written for informational purposes is
found in [RFC3924].
5. Residential Users Security Considerations 5. Residential Users Security Considerations
The IETF Homenet working group is working on standards and guidelines The IETF Homenet working group is working on standards and guidelines
for IPv6 residential networks; this obviously includes operational for IPv6 residential networks; this obviously includes operational
security considerations; but this is still work in progress. security considerations; but this is still work in progress.
[RFC8520] is an interesting approach on how firewalls could retrieve [RFC8520] is an interesting approach on how firewalls could retrieve
and apply specific security policies to some residential devices. and apply specific security policies to some residential devices.
Some residential users have less experience and knowledge about Some residential users have less experience and knowledge about
security or networking. As most of the recent hosts (e.g., security or networking than experimented operators. As most of the
smartphones, tablets) have IPv6 enabled by default, IPv6 security is recent hosts (e.g., smartphones, tablets) have IPv6 enabled by
important for those users. Even with an IPv4-only ISP, those users default, IPv6 security is important for those users. Even with an
can get IPv6 Internet access with the help of Teredo IPv4-only ISP, those users can get IPv6 Internet access with the help
(Section 2.7.2.8) tunnels. Several peer-to-peer programs support of Teredo (Section 2.7.2.8) tunnels. Several peer-to-peer programs
IPv6 and those programs can initiate a Teredo tunnel through an IPv4 support IPv6 and those programs can initiate a Teredo tunnel through
residential gateway, with the consequence of making the internal host an IPv4 residential gateway, with the consequence of making the
reachable from any IPv6 host on the Internet. It is therefore internal host reachable from any IPv6 host on the Internet. It is
recommended that all host security products (including personal therefore recommended that all host security products (including
firewalls) are configured with a dual-stack security policy. personal firewalls) are configured with a dual-stack security policy.
If the residential CPE has IPv6 connectivity, [RFC7084] defines the If the residential CPE has IPv6 connectivity, [RFC7084] defines the
requirements of an IPv6 CPE and does not take a position on the requirements of an IPv6 CPE and does not take a position on the
debate of default IPv6 security policy as defined in [RFC6092]: debate of default IPv6 security policy as defined in [RFC6092]:
o outbound only: allowing all internally initiated connections and o outbound only: allowing all internally initiated connections and
block all externally initiated ones, which is a common default block all externally initiated ones, which is a common default
security policy enforced by IPv4 Residential Gateway doing NAPT security policy enforced by IPv4 Residential Gateway doing NAPT
but it also breaks the end-to-end reachability promise of IPv6. but it also breaks the end-to-end reachability promise of IPv6.
[RFC6092] lists several recommendations to design such a CPE; [RFC6092] lists several recommendations to design such a CPE;
skipping to change at page 41, line 28 skipping to change at page 42, line 18
2. North American IPv6 Task Force Technology Report - IPv6 Security 2. North American IPv6 Task Force Technology Report - IPv6 Security
Technology Paper [NAv6TF_Security] Technology Paper [NAv6TF_Security]
3. IPv6 Security [IPv6_Security_Book] 3. IPv6 Security [IPv6_Security_Book]
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the following people for their useful The authors would like to thank the following people for their useful
comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali,
Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, Roman
Markus de Bruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee Danyliw (IESG review), Markus de Bruen, Lars Eggert (IESG review),
Howard, Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee Howard, Benjamin
Ted Lemon, Mark Lentczner, Acee Lindem (and his detailed nits), Jen Kaduk (IESG review), Panos Kampanakis, Erik Kline, Jouni Korhonen,
Linkova (and her detailed review), Gyan S. Mishra, Jordi Palet, Bob Warren Kumari (IESG review), Ted Lemon, Mark Lentczner, Acee Lindem
Sleigh, Donald Smith, Tarko Tikan, Ole Troan, Bernie Volz (by (and his detailed nits), Jen Linkova (and her detailed review), Gyan
alphabetical order). S. Mishra (the document shepherd), Jordi Palet, Alvaro Retana (IESG
review), Zaheduzzaman Sarker (IESG review), Bob Sleigh, Donald Smith,
Tarko Tikan, Ole Troan, Bernie Volz (by alphabetical order).
8. Security Considerations 8. Security Considerations
This memo attempts to give an overview of security considerations of This memo attempts to give an overview of security considerations of
operating an IPv6 network both for an IPv6-only network and for operating an IPv6 network both for an IPv6-only network and for
networks utilizing the most widely deployed IPv4/IPv6 coexistence networks utilizing the most widely deployed IPv4/IPv6 coexistence
strategies. strategies.
9. References 9. References
skipping to change at page 42, line 11 skipping to change at page 43, line 5
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
9.2. Informative References 9.2. Informative References
[CYMRU] Team, C., "The Bogon Reference", Existing in 2021, [CYMRU] Team, C., "The Bogon Reference", Existing in 2021,
<https://team-cymru.com/community-services/bogon- <https://team-cymru.com/community-services/bogon-
reference/>. reference/>.
[ENTROPYIP]
Foremski, P., Plonka, D., and A. Berger, "Entropy/IP:
Uncovering Structure in IPv6 Addresses",
<http://www.entropy-ip.com/>.
[europol-cgn] [europol-cgn]
Europol, "ARE YOU SHARING THE SAME IP ADDRESS AS A Europol, "ARE YOU SHARING THE SAME IP ADDRESS AS A
CRIMINAL? LAW ENFORCEMENT CALL FOR THE END OF CARRIER CRIMINAL? LAW ENFORCEMENT CALL FOR THE END OF CARRIER
GRADE NAT (CGN) TO INCREASE ACCOUNTABILITY ONLINE", GRADE NAT (CGN) TO INCREASE ACCOUNTABILITY ONLINE",
October 2017, October 2017,
<https://www.europol.europa.eu/newsroom/news/are-you- <https://www.europol.europa.eu/newsroom/news/are-you-
sharing-same-ip-address-criminal-law-enforcement-call-for- sharing-same-ip-address-criminal-law-enforcement-call-for-
end-of-carrier-grade-nat-cgn-to-increase-accountability- end-of-carrier-grade-nat-cgn-to-increase-accountability-
online>. online>.
[GDPR] Union, O. J. O. T. E., "Regulation (EU) 2016/679 of the [GDPR] Union, O. J. O. T. E., "Regulation (EU) 2016/679 of the
European Parliament and of the Council of 27 April 2016 on European Parliament and of the Council of 27 April 2016 on
the protection of natural persons with regard to the the protection of natural persons with regard to the
processing of personal data and on the free movement of processing of personal data and on the free movement of
such data, and repealing Directive 95/46/EC (General Data such data, and repealing Directive 95/46/EC (General Data
Protection Regulation)", April 2016, Protection Regulation)", April 2016,
<https://eur-lex.europa.eu/eli/reg/2016/679/oj>. <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
[I-D.ietf-opsec-ipv6-eh-filtering] [I-D.ietf-opsec-ipv6-eh-filtering]
Gont, F. and W. LIU, "Recommendations on the Filtering of Gont, F. and W. Liu, "Recommendations on the Filtering of
IPv6 Packets Containing IPv6 Extension Headers at Transit IPv6 Packets Containing IPv6 Extension Headers at Transit
Routers", draft-ietf-opsec-ipv6-eh-filtering-07 (work in Routers", draft-ietf-opsec-ipv6-eh-filtering-07 (work in
progress), January 2021. progress), January 2021.
[I-D.kampanakis-6man-ipv6-eh-parsing] [I-D.kampanakis-6man-ipv6-eh-parsing]
Kampanakis, P., "Implementation Guidelines for parsing Kampanakis, P., "Implementation Guidelines for parsing
IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh-
parsing-01 (work in progress), August 2014. parsing-01 (work in progress), August 2014.
[IANA-IPFIX] [IANA-IPFIX]
skipping to change at page 43, line 5 skipping to change at page 44, line 5
[IEEE-802.1X] [IEEE-802.1X]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Port-Based Network Access Control", IEEE Std networks - Port-Based Network Access Control", IEEE Std
802.1X-2010, February 2010. 802.1X-2010, February 2010.
[IPv6_Security_Book] [IPv6_Security_Book]
Hogg, S. and E. Vyncke, "IPv6 Security", Hogg, S. and E. Vyncke, "IPv6 Security",
ISBN 1-58705-594-5, Publisher CiscoPress, December 2008. ISBN 1-58705-594-5, Publisher CiscoPress, December 2008.
[KRISTOFF]
Kristoff, J., Ghasemisharif, M., Kanich, C., and J.
Polakis, "Plight at the End of the Tunnel: Legacy IPv6
Transition Mechanisms in the Wild", March 2021,
<https://dataplane.org/jtk/publications/kgkp-pam-21.pdf>.
[NAv6TF_Security] [NAv6TF_Security]
Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North
American IPv6 Task Force Technology Report - IPv6 Security American IPv6 Task Force Technology Report - IPv6 Security
Technology Paper", 2006, Technology Paper", 2006,
<http://www.ipv6forum.com/dl/white/ <http://www.ipv6forum.com/dl/white/
NAv6TF_Security_Report.pdf>. NAv6TF_Security_Report.pdf>.
[NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks,
"Guidelines for the Secure Deployment of IPv6", 2010, "Guidelines for the Secure Deployment of IPv6", 2010,
<http://csrc.nist.gov/publications/nistpubs/800-119/ <http://csrc.nist.gov/publications/nistpubs/800-119/
skipping to change at page 45, line 14 skipping to change at page 46, line 19
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4293] Routhier, S., Ed., "Management Information Base for the [RFC4293] Routhier, S., Ed., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293,
April 2006, <https://www.rfc-editor.org/info/rfc4293>. April 2006, <https://www.rfc-editor.org/info/rfc4293>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
skipping to change at page 46, line 19 skipping to change at page 47, line 30
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
DOI 10.17487/RFC4649, August 2006, DOI 10.17487/RFC4649, August 2006,
<https://www.rfc-editor.org/info/rfc4649>. <https://www.rfc-editor.org/info/rfc4649>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<https://www.rfc-editor.org/info/rfc4659>. <https://www.rfc-editor.org/info/rfc4659>.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795,
DOI 10.17487/RFC4795, January 2007,
<https://www.rfc-editor.org/info/rfc4795>.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798, Provider Edge Routers (6PE)", RFC 4798,
DOI 10.17487/RFC4798, February 2007, DOI 10.17487/RFC4798, February 2007,
<https://www.rfc-editor.org/info/rfc4798>. <https://www.rfc-editor.org/info/rfc4798>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
skipping to change at page 49, line 24 skipping to change at page 50, line 38
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<https://www.rfc-editor.org/info/rfc6333>. <https://www.rfc-editor.org/info/rfc6333>.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, DOI 10.17487/RFC6343, August 2011, RFC 6343, DOI 10.17487/RFC6343, August 2011,
<https://www.rfc-editor.org/info/rfc6343>. <https://www.rfc-editor.org/info/rfc6343>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, DOI 10.17487/RFC6434, December
2011, <https://www.rfc-editor.org/info/rfc6434>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, DOI 10.17487/RFC6459, January 2012, RFC 6459, DOI 10.17487/RFC6459, January 2012,
<https://www.rfc-editor.org/info/rfc6459>. <https://www.rfc-editor.org/info/rfc6459>.
[RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547,
DOI 10.17487/RFC6547, February 2012, DOI 10.17487/RFC6547, February 2012,
<https://www.rfc-editor.org/info/rfc6547>. <https://www.rfc-editor.org/info/rfc6547>.
skipping to change at page 56, line 33 skipping to change at page 58, line 4
Authors' Addresses Authors' Addresses
Eric Vyncke Eric Vyncke
Cisco Cisco
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2 778 4677 Phone: +32 2 778 4677
Email: evyncke@cisco.com Email: evyncke@cisco.com
Kiran Kumar Kiran Kumar
WeWork Square
415 Mission St. 1455 Market Street, Suite 600
San Francisco 94105 San Francisco 94103
United States of America United States of America
Email: kk.chittimaneni@gmail.com Email: kk.chittimaneni@gmail.com
Merike Kaeo Merike Kaeo
Double Shot Security Double Shot Security
3518 Fremont Ave N 363 3518 Fremont Ave N 363
Seattle 98103 Seattle 98103
United States of America United States of America
 End of changes. 124 change blocks. 
272 lines changed or deleted 322 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/