< draft-ietf-opsec-v6-16.txt   draft-ietf-opsec-v6-17.txt >
OPSEC E. Vyncke, Ed. OPSEC E. Vyncke, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational K. Chittimaneni Intended status: Informational K. Chittimaneni
Expires: September 12, 2019 WeWork Expires: January 7, 2020 WeWork
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
E. Rey E. Rey
ERNW ERNW
March 11, 2019 July 6, 2019
Operational Security Considerations for IPv6 Networks Operational Security Considerations for IPv6 Networks
draft-ietf-opsec-v6-16 draft-ietf-opsec-v6-17
Abstract Abstract
Knowledge and experience on how to operate IPv4 securely is Knowledge and experience on how to operate IPv4 securely is
available: whether it is the Internet or an enterprise internal available: whether it is the Internet or an enterprise internal
network. However, IPv6 presents some new security challenges. RFC network. However, IPv6 presents some new security challenges. RFC
4942 describes the security issues in the protocol but network 4942 describes the security issues in the protocol but network
managers also need a more practical, operations-minded document to managers also need a more practical, operations-minded document to
enumerate advantages and/or disadvantages of certain choices. enumerate advantages and/or disadvantages of certain choices.
This document analyzes the operational security issues in several This document analyzes the operational security issues in several
places of a network (enterprises, service providers and residential places of a network (enterprises, service providers and residential
users) and proposes technical and procedural mitigations techniques. users) and proposes technical and procedural mitigations techniques.
Some very specific place of a network such as Internet of Things are Some very specific place of a network such as the Internet of Things
not discussed in this document. are not discussed in this document.
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 September 12, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 26 skipping to change at page 2, line 26
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. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Generic Security Considerations . . . . . . . . . . . . . . . 4 2. Generic Security Considerations . . . . . . . . . . . . . . . 4
2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4
2.1.1. Statically Configured Addresses . . . . . . . . . . . 5 2.1.1. Statically Configured Addresses . . . . . . . . . . . 4
2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 5 2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 5
2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 6 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 5
2.1.5. Privacy consideration of Addresses . . . . . . . . . 7 2.1.5. Privacy consideration of Addresses . . . . . . . . . 7
2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7 2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7
2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 7 2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 7
2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 7 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Order and Repetition of Extension Headers . . . . . . 8 2.2.1. Order and Repetition of Extension Headers . . . . . . 8
2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 8 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 8
2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 8 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 8
2.2.4. IP Security Extension Header . . . . . . . . . . . . 9 2.2.4. IP Security Extension Header . . . . . . . . . . . . 9
2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9
2.3.1. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9 2.3.1. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 9 skipping to change at page 3, line 9
2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 16 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 16
2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 16 2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 16
2.5.2. Securing Routing Updates Between Peers . . . . . . . 17 2.5.2. Securing Routing Updates Between Peers . . . . . . . 17
2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 17 2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 17
2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 18 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 18
2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 19 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 19
2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 23 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 23
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 25 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 25
2.7. Transition/Coexistence Technologies . . . . . . . . . . . 25 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 25
2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 26 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 26
2.7.2. Transition Mechanisms . . . . . . . . . . . . . . . . 26 2.7.2. Encapsulation Mechanisms . . . . . . . . . . . . . . 26
2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 30 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 30
2.8. General Device Hardening . . . . . . . . . . . . . . . . 32 2.8. General Device Hardening . . . . . . . . . . . . . . . . 32
3. Enterprises Specific Security Considerations . . . . . . . . 32 3. Enterprises Specific Security Considerations . . . . . . . . 33
3.1. External Security Considerations: . . . . . . . . . . . . 33 3.1. External Security Considerations: . . . . . . . . . . . . 33
3.2. Internal Security Considerations: . . . . . . . . . . . . 33 3.2. Internal Security Considerations: . . . . . . . . . . . . 34
4. Service Providers Security Considerations . . . . . . . . . . 34 4. Service Providers Security Considerations . . . . . . . . . . 34
4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 34 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 35
4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . 34 4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . 35
4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 34 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 35
5. Residential Users Security Considerations . . . . . . . . . . 35 5. Residential Users Security Considerations . . . . . . . . . . 35
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 36 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 36
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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 differences between IPv4 and IPv6 especially with there are subtle differences between IPv4 and IPv6 especially with
respect to security. For example, all layer-2 interactions are now respect to security. For example, all layer-2 interactions are now
done using Neighbor Discovery Protocol [RFC4861] rather than using done using Neighbor Discovery Protocol [RFC4861] rather than using
Address Resolution Protocol [RFC0826]. Also, there are subtle Address Resolution Protocol [RFC0826]. Also, there are subtle
differences between NAT44 [RFC2993] and NPTv6 [RFC6296] which are differences between NAT44 [RFC2993] and NPTv6 [RFC6296] which are
skipping to change at page 4, line 21 skipping to change at page 4, line 21
capitals, as shown here. capitals, as shown here.
2. Generic Security Considerations 2. Generic Security Considerations
2.1. Addressing Architecture 2.1. Addressing Architecture
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 good IP Addresses may be extremely difficult to renumber without a proper IP Addresses
Management (IPAM) system. Management (IPAM) system.
Once an address allocation has been assigned, there should be some A key task before starting an IPv6 deployment, once the sufficient
thought given to an overall address allocation plan. With the knowledge has been acquired, is to prepare an addressing plan. With
abundance of address space available, an address allocation may be the abundance of address space available, an addressing plan may be
structured around services along with geographic locations, which structured around services along with geographic locations, which
then can be a basis for more structured security policies to permit then can be a basis for more structured security policies to permit
or deny services between geographic regions. or deny services between geographic regions.
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 from Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from
a security perspective there is little difference. However, one 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 due to need to enforce restrictions on routability of the space e.g. due to
malicious criminal activity. Using PA space exposes the organization malicious criminal activity originating from it.
to a renumbering of the complete network including security policies
(based on ACL), audit system, ... in short a complex task which
could lead to some temporary security risk if done for a large
network and without automation; hence, for large networks, PI space
should be preferred even if it comes with additional complexities
(for example BGP routing) and duties (adding a route6 object in the
Regional Internet Registry database).
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 to limit a host to only one IPv6 it specifically does not recommend to limit 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). requests (for example by using SLAAC).
2.1.1. Statically Configured Addresses 2.1.1. Statically Configured Addresses
When considering how to assign statically configured addresses it is When considering how to assign statically configured addresses it is
necessary to take into consideration the effectiveness of perimeter necessary to take into consideration the effectiveness of perimeter
security in a given environment. There is a trade-off between ease security in a given environment. There is a trade-off between ease
of operation (where some portions of the IPv6 address could be easily of operation (where some portions of the IPv6 address could be easily
recognizable for operational debugging and troubleshooting) versus recognizable for operational debugging and troubleshooting) versus
the risk of trivial scanning used for reconnaissance. [SCANNING] the risk of trivial scanning used for reconnaissance. [SCANNING]
shows that there are scientifically based mechanisms that make shows that there are scientifically based mechanisms that make
scanning for IPv6 reachable nodes more realizable than expected; see scanning for IPv6 reachable nodes more feasable than expected; see
also [RFC7707]. The use of well-known(such as ff02::1 for all link- also [RFC7707]. The use of well-known (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 and more to routers on a path. There are many scanning techniques and more to
come possible, hence, operators should never relly on the 'impossible come possible, hence, operators should not rely on the 'impossible to
to find because my address is random' paradigm. find because my address is random' paradigm, even if it is common
practice to have the statically configured addresses randomly
distributed across /64 subnets and to always use DNS.
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 that perimeter rules are an added benefit; it does not preclude that perimeter rules are
actively enforced and that statically configured addresses follow actively enforced and that statically configured addresses follow
some logical allocation scheme for ease of operation (as simplicity some logical allocation scheme for ease of operation (as simplicity
always helps security). Typical deployments will have a mix of always helps security). Typical deployments will have a mix of
static and non static addresses. static and non static addresses.
2.1.2. Use of ULAs 2.1.2. Use of ULAs
Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
where systems are not globally reachable, despite formally having where systems are not globally reachable, despite formally having
global scope. ULA looks similar to [RFC1918] addresses but have global scope. ULA looks similar to [RFC1918] addresses but have
different use cases. One use of ULA is described in [RFC4864] and different use cases. One use of ULA is described in [RFC4864] and
some considerations on using ULA is described in the draft document some considerations on using ULA is described in the draft document
[I-D.ietf-v6ops-ula-usage-considerations]. [I-D.ietf-v6ops-ula-usage-considerations].
2.1.3. Point-to-Point Links 2.1.3. Point-to-Point Links
[RFC6164] in section 5.1 documents the reasons why to use a /127 for [RFC6164] in section 5.1 documents the reasons why it can make sense
inter-router point-to-point links; notably, a /127 prevents the ping- to use a /127 for inter-router point-to-point links; notably, a /127
pong attack between routers not implementing correctly [RFC4443] and prevents the ping-pong attack between routers not implementing
also prevents a DoS attack on the neighbor cache. The previous correctly [RFC4443] and also prevents a DoS attack on the neighbor
recommendation of [RFC3627] has been obsoleted and marked Historic by cache. The previous recommendation of [RFC3627] has been obsoleted
[RFC6547]). and marked Historic by [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 against infrastructure devices, the operational disadvantages surface against infrastructure devices, the operational disadvantages
need also to be carefully considered; see also [RFC7404]. need also to be carefully considered; see also [RFC7404].
2.1.4. Temporary Addresses - Privacy Extensions for SLAAC 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC
Historically stateless address autoconfiguration (SLAAC) relied on an Historically stateless address autoconfiguration (SLAAC) relied on an
automatically generated64 bit interface identifier (IID) based on the automatically generated 64-bit interface identifier (IID) based on
EUI-64 MAC address, which together with the /64 prefix makes up the the EUI-64 MAC address, which together with the /64 prefix makes up
globally unique IPv6 address. The EUI-64 address is generated from the globally unique IPv6 address. The EUI-64 address is generated
the 48-bit stable MAC address. [RFC8064] recommends against the use from the 48-bit stable MAC address. [RFC8064] recommends against the
of EUI-64 addresses and it must be noted that most host operating use of EUI-64 addresses and it must be noted that most host operating
systems do not use EUI-64 addresses anymore and rely on either systems do not use EUI-64 addresses anymore and rely on either
[RFC4941] or [RFC8064]. [RFC4941] or [RFC8064].
Randomly generating an interface ID, as described in [RFC4941], is Randomly generating an interface ID, as described in [RFC4941], is
part of SLAAC with so-called privacy extension addresses and used to part of SLAAC with so-called privacy extension addresses and used to
address some privacy concerns. Privacy extension addresses a.k.a. address some privacy concerns. Privacy extension addresses a.k.a.
temporary addresses may help to mitigate the correlation of temporary addresses may help to mitigate the correlation of
activities of a node within the same network, and may also somehow activities of a node within the same network, and may also somehow
reduce the attack exposure window. reduce the attack exposure window.
Using [RFC4941] privacy extension addresses prevents the operator Using [RFC4941] privacy extension addresses might prevent the
from building host specific access control lists (ACLs). operator from building host specific access control lists (ACLs).
[RFC8064] specifies another way to generate while still keeping the [RFC8064] specifies another way to generate while still keeping the
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 address on different networks. different IPv6 address on different networks.
As [RFC4941] privacy extension addresses could also be used to As [RFC4941] privacy extension addresses could also be used to
obfuscate some malevolent activities (whether on purpose or not), obfuscate some malevolent activities (whether on purpose or not),
specific user attribution/accountability procedures should be put in specific user attribution/accountability procedures should be put in
place as described in section Section 2.6. place as described in section Section 2.6.
In some extreme use cases where user accountability is more important In some extreme use cases where user accountability is more important
than user privacy, network operators may consider to disable SLAAC than user privacy, network operators may consider to disable SLAAC
and rely only on DHCPv6; but, not all operating systems support and rely only on DHCPv6; but, not all operating systems support
DHCPv6 so some hosts will not get any IPv6 connectivity.Disabling DHCPv6 so some hosts will not get any IPv6 connectivity.Disabling
SLAAC and privacy extensions addresses can be done for most OS and SLAAC and privacy extensions addresses can be done for most OS and
for non-hacker users by sending RA messages with a hint to get for non-hacker users by sending RA messages with a hint to get
addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by
resetting all A-bits in all prefix information options. Hackers will resetting all A-bits in all prefix information options. However
find a way to bypass this mechanism if not enforced at the switch/ attackers could still find ways to bypass this mechanism if not
router level. enforced at the 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 [RFC8064] is available, the
stable privacy address is probably a good balance between privacy stable privacy address is probably a good balance between privacy
(among multiple networks) and security/user attribution (within a (among different networks) and security/user attribution (within a
network). network).
2.1.5. Privacy consideration of Addresses 2.1.5. Privacy consideration of Addresses
The reader can learn more about privacy considerations for IPv6 The reader can learn more about privacy considerations for IPv6
addresses in [RFC7721]. addresses in [RFC7721].
2.1.6. DHCP/DNS Considerations 2.1.6. DHCP/DNS Considerations
Many environments use DHCPv6 to allocate addresses to ensure audit- Many environments use DHCPv6 to provision addresses and other
ability and traceability (but see Section 2.6.1.5). A main security parameters in order to ensure audit-ability and traceability (but see
concern is the ability to detect and counteract against rogue DHCP Section 2.6.1.5). A main security concern is the ability to detect
servers (Section 2.3.3). and counteract against rogue DHCP servers (Section 2.3.3).
While there are no fundamental differences with IPv4 and IPv6 While there are no fundamental differences with IPv4 and IPv6
security concerns about DNS, there are specific consideration in security concerns about DNS, there are specific consideration in
DNS64 [RFC6147] environments that need to be understood. DNS64 [RFC6147] environments that need to be understood.
Specifically the interactions and potential to interference with Specifically the interactions and the potential of interference with
DNSSEC implementation need to be understood - these are pointed out DNSSEC implementation need to be understood - these are pointed out
in detail in Section 2.7.3.2. in more detail in Section 2.7.3.2.
2.1.7. Using a /64 per host 2.1.7. 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]. This allows an easier user attribution (typically based [RFC8273]. This allows an easier user attribution (typically based
on the host MAC address) as its /64 prefix is stable even if on the host MAC address) as its /64 prefix is stable even if
applications, containers within the host can change of IPv6 address applications, containers within the host can change of IPv6 address
within this /64. within this /64.
2.2. Extension Headers 2.2. Extension Headers
skipping to change at page 11, line 10 skipping to change at page 11, line 10
Given that the IPv6 Fragmentation Header can be leveraged to Given that the IPv6 Fragmentation Header can be leveraged to
circumvent current implementations of RA-Guard, [RFC6980] updates circumvent current implementations of RA-Guard, [RFC6980] updates
[RFC4861] such that use of the IPv6 Fragmentation Header is forbidden [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden
in all Neighbor Discovery messages except "Certification Path in all Neighbor Discovery messages except "Certification Path
Advertisement", thus allowing for simple and effective measures to Advertisement", thus allowing for simple and effective measures to
counter Neighbor Discovery attacks. counter Neighbor Discovery attacks.
The Source Address Validation Improvements (SAVI) working group has The Source Address Validation Improvements (SAVI) working group has
worked on other ways to mitigate the effects of such attacks. worked on other ways to mitigate the effects of such attacks.
[RFC7513] would help in creating bindings between a DHCPv4 [RFC2131] [RFC7513] would help in creating bindings between a DHCPv4 [RFC2131]
/DHCPv6 [RFC3315] 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
address. address.
It is still recommended that RA-Guard and SAVI be be employed as a It is still recommended that RA-Guard and SAVI be be employed as a
first line of defense against common attack vectors including first line of defense against common attack vectors including
misconfigured hosts. This line of defense is fully effective when misconfigured hosts. This line of defense is fully effective when
weird fragments are dropped by routers and switches as described in weird fragments are dropped by routers and switches as described in
Section 2.2.3. The generated log should also be analyzed to act on Section 2.2.3. The generated log should also be analyzed to act on
violations. violations.
2.3.3. Securing DHCP 2.3.3. Securing DHCP
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as originally Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in
detailed in [RFC3315] now obsoleted by [RFC8415], enables DHCP [RFC8415], enables DHCP servers to pass configuration parameters such
servers to pass configuration parameters such as IPv6 network as IPv6 network addresses and other configuration information to IPv6
addresses and other configuration information to IPv6 nodes. DHCP nodes. DHCP plays an important role in most large networks by
plays an important role in any large network by providing robust providing robust stateful configuration and in the context of
stateful configuration and autoregistration of DNS Host Names. 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. A
malicious DHCP server is established with the intent of providing malicious DHCP server is established with the intent of providing
incorrect configuration information to the client to cause a denial incorrect configuration information to the client to cause a denial
of service attack or mount a man in the middle attack. While of service attack or to mount a-man-in-the-middle attack. While
unintentionall, a misconfigured DHCP server can have the same impact. unintentional, a misconfigured DHCP server can have the same impact.
Additional threats against DHCP are discussed in the security Additional threats against DHCP are discussed in the security
considerations section of [RFC8415]. considerations section of [RFC8415].
[RFC7610], DHCPv6-Shield, specifies a mechanism for protecting [RFC7610], DHCPv6-Shield, 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;
the administrator specifies the interfaces connected to DHCPv6 the administrator specifies the interfaces connected to DHCPv6
servers. Of course, extension headers could be leveraged to bypass servers. Furthermore, extension headers could be leveraged to bypass
DHCPv6-Shield unless [RFC7112] is enforced. Another way to secure DHCPv6-Shield unless [RFC7112] is enforced.
DHCPv6 would be to use the secure DHCPv6 protocol which is currently
work in progress per [I-D.ietf-dhc-sedhcpv6] , but, with no real
deployment known by the authors of this document.
It is recommended to use DHCP-shield and to analyze the log generated It is recommended to use DHCPv6-Shield and to analyze the
by this security feature. 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 an 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. The advertised prefix must not be used for on-link /64 prefix on it. The advertised prefix must not be used for on-link
determination. There is no need for an address resolution on the determination. There is no need for an address resolution on the
skipping to change at page 17, line 5 skipping to change at page 16, line 50
routing relationship. routing relationship.
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 However, it should be noted 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 configurations protection. In early implementations all OSPFv3 IPsec configurations
relied on AH since the details weren't specified in [RFC5340] or relied on AH since the details weren't specified in [RFC5340].
[RFC2740] that was obsoleted by the former. However, the document However, the document which specifically describes how IPsec should
which specifically describes how IPsec should be implemented for be implemented for OSPFv3 [RFC4552] specifically states that ESP-Null
OSPFv3 [RFC4552] specifically states that ESP-Null MUST and AH MAY be MUST and AH MAY be implemented since it follows the overall IPsec
implemented since it follows the overall IPsec standards wordings. standards wordings. OSPFv3 can also use normal ESP to encrypt the
OSPFv3 can also use normal ESP to encrypt the OSPFv3 payload to hide OSPFv3 payload to hide the routing information.
the routing information.
[RFC7166] (which obsoletes [RFC6506] changes OSPFv3's reliance on [RFC7166] changes OSPFv3 reliance on IPsec by appending an
IPsec by appending an authentication trailer to the end of the OSPFv3 authentication trailer to the end of the OSPFv3 packets; it does not
packets; it does not specifically authenticate the specific specifically authenticate the specific originator of an OSPFv3
originator of an OSPFv3 packet; rather, it allows a router to confirm packet; rather, it allows a router to confirm that the packet has
that the packet has indeed been issued by a router that had access to indeed been issued by a router that had access to the shared
the shared authentication key. authentication 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 cause outages outages. There have been instances where any re-keying cause outages
and therefore the tradeoff between utilizing this functionality needs and therefore the tradeoff between utilizing this functionality needs
to be weighed against the protection it provides. to be weighed against the protection it provides.
2.5.2. Securing Routing Updates Between Peers 2.5.2. Securing Routing Updates Between Peers
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] (that obsoletes [RFC6434]) is a 'SHOULD' and no more a [RFC8504] is a 'SHOULD' and no more a 'MUST' implement.
'MUST' implement. Theoretically it is possible, and recommended, Theoretically it is possible, and recommended, that communication
that communication between two IPv6 nodes, including routers between two IPv6 nodes, including routers exchanging routing
exchanging routing information be encrypted using IPsec. In practice information be encrypted using IPsec. In practice however, deploying
however, deploying IPsec is not always feasible given hardware and IPsec is not always feasible given hardware and software limitations
software limitations of various platforms deployed, as described in of various platforms deployed, as described in the earlier section.
the earlier section.
2.5.3. Route Filtering 2.5.3. 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 packets from and to bogon and reserved space (see o Discard packets from and to bogon 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. There is additional work being done in this area to
formally validate the origin ASs of BGP announcements in [RFC6810] formally validate the origin ASs of BGP announcements in [RFC8210]
Some good recommendations for filtering can be found from Team CYMRU Some good recommendations for filtering can be found from Team CYMRU
at [CYMRU]. at [CYMRU]. [RFC7454] is another valuable resource of guidance in
this space.
2.6. Logging/Monitoring 2.6. Logging/Monitoring
In order to perform forensic research in case of any security In order to perform forensic research in case of any security
incident or to detect abnormal behaviors, network operators should incident or to detect abnormal behaviors, network operators should
log multiple pieces of information. log multiple pieces of information.
This includes: This includes:
o logs of all applications when available (for example web servers); o logs of all applications when available (for example web servers);
o use of IP Flow Information Export [RFC7011] also known as IPfix; o use of IP Flow Information Export [RFC7011] also known as IPfix;
o use of SNMP MIB [RFC4293]; o use of SNMP MIB [RFC4293];
o use of the Neighbor cache; o use of the Neighbor cache;
o use of stateful DHCPv6 [RFC3315] lease cache, especially when a o use of stateful DHCPv6 [RFC8415] lease cache, especially when a
relay agent [RFC6221] in layer-2 switches is used; relay agent [RFC6221] is used;
o use of Source Address Validation Improvement (SAVI) [RFC7039] o use of Source Address Validation Improvement (SAVI) [RFC7039]
events, especially the binding of an IPv6 address to a MAC address events, especially the binding of an IPv6 address to a MAC address
and a specific switch or router interface; and a specific switch or router interface;
o use of RADIUS [RFC2866] for accounting records. o use of RADIUS [RFC2866] for accounting records.
Please note that there are privacy issues related to how those logs Please note that there are privacy issues or regulations related to
are collected, kept and safely discarded. Operators are urged to how those logs are collected, kept and safely discarded. Operators
check their country legislation. are urged to check their country legislation (e.g. GDPR in the
European Union).
All those pieces of information will be used for: All those pieces of information will 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
[RFC4941]) [RFC4941])
skipping to change at page 19, line 18 skipping to change at page 19, line 16
2.6.1. Data Sources 2.6.1. Data Sources
This section lists the most important sources of data that are useful This section lists the most important sources of data that are useful
for operational security. for operational security.
2.6.1.1. Logs of Applications 2.6.1.1. Logs of Applications
Those logs are usually text files where the remote IPv6 address is Those logs are usually text files where the remote IPv6 address is
stored in all characters (not binary). This can complicate the stored in all characters (not binary). This can complicate the
processing since one IPv6 address, 2001:db8::1 can be written in processing since one IPv6 address, for example 2001:db8::1 can be
multiple ways such as: written in multiple ways such as:
o 2001:DB8::1 (in uppercase) o 2001:DB8::1 (in uppercase)
o 2001:0db8::0001 (with leading 0) o 2001:0db8::0001 (with leading 0)
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).
RFC 5952 [RFC5952] explains this problem in detail and recommends the RFC 5952 [RFC5952] explains this problem in detail and recommends the
use of a single canonical format (in short use lower case and use of a single canonical format. This document recommends the use
suppress leading 0). This memo recommends the use of canonical of canonical format [RFC5952] for IPv6 addresses in all possible
format [RFC5952] for IPv6 addresses in all possible cases. If the cases. If the existing application cannot log under the canonical
existing application cannot log under the canonical format, then this format, then it is recommended to use an external program in order to
memo recommends the use an external program in order to canonicalize canonicalize all IPv6 addresses.
all IPv6 addresses.
For example, this perl script can be used: For example, this perl script can be used:
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict ; use strict ;
use warnings ; use warnings ;
use Socket ; use Socket ;
use Socket6 ; use Socket6 ;
my (@words, $word, $binary_address) ; my (@words, $word, $binary_address) ;
skipping to change at page 21, line 48 skipping to change at page 21, line 48
and audit trail. and audit trail.
Using the approach of one /64 per host (Section 2.1.7) replaces the Using the approach of one /64 per host (Section 2.1.7) replaces the
neighbor cache dumps by a mere caching of the allocated /64 prefix neighbor cache dumps by a mere caching of the allocated /64 prefix
when combined with strict enforcement rule on the router and switches when combined with strict enforcement rule on the router and switches
to prevent IPv6 spoofing. to prevent IPv6 spoofing.
2.6.1.5. Stateful DHCPv6 Lease 2.6.1.5. Stateful DHCPv6 Lease
In some networks, IPv6 addresses are managed by stateful DHCPv6 In some networks, IPv6 addresses are managed by stateful DHCPv6
server [RFC3315] that leases IPv6 addresses to clients. It is indeed server [RFC8415] that leases IPv6 addresses to clients. It is indeed
quite similar to DHCP for IPv4 so it can be tempting to use this DHCP quite similar to DHCP for IPv4 so it can be tempting to use this DHCP
lease file to discover the mapping between IPv6 addresses and data- lease file to discover the mapping between IPv6 addresses and data-
link layer addresses as it was usually done in the IPv4 era. link layer addresses as it was usually done in the IPv4 era.
It is not so easy in the IPv6 era because not all nodes will use It is not so easy in the IPv6 era because not all nodes will use
DHCPv6 (there are nodes which can only do stateless 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 layer
address, some being data-link layer address prepended with time address, some being data-link layer address prepended with time
skipping to change at page 22, line 45 skipping to change at page 22, line 45
[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 any 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 that must be kept exactly as in the IPv4 There are other data sources that must be kept exactly as in the IPv4
network: network:
o historical mapping of IPv6 addresses to users of remote access o historical mapping of IPv6 addresses to users of remote access
VPN; VPN;
o historical mapping of MAC address to switch interface in a wired o historical mapping of MAC address to switch interface in a wired
skipping to change at page 24, line 7 skipping to change at page 24, line 7
identification and the MAC address. If a Configuration identification and the MAC address. If a Configuration
Management Data Base (CMDB) is used, the mapping between the Management Data Base (CMDB) is used, the mapping between the
data-link layer address and a switch port. data-link layer address and a switch port.
At the end of the process, the interface the host originating At the end of the process, the interface the host originating
malicious activity or the username which was abused for malicious malicious activity or the username which was abused for malicious
activity has been determined. activity has been determined.
2.6.2.2. Inventory 2.6.2.2. Inventory
RFC 7707 [RFC7707] (which obsoletes RFC 5157 [RFC5157]) is about the RFC 7707 [RFC7707] is about the difficulties for an attacker to scan
difficulties for an attacker to scan an IPv6 network due to the vast an IPv6 network due to the vast number of IPv6 addresses per link
number of IPv6 addresses per link (and why in some case it can stil (and why in some case it can still be done). While the huge
be done). While the huge addressing space can sometime be perceived addressing space can sometime be perceived as a 'protection', it also
as a 'protection', it also make the inventory task difficult in an make the inventory task difficult in an IPv6 network while it was
IPv6 network while it was trivial to do in an IPv4 network (a simple trivial to do in an IPv4 network (a simple enumeration of all IPv4
enumeration of all IPv4 addresses, followed by a ping and a TCP/UDP addresses, followed by a ping and a TCP/UDP port scan). Getting an
port scan). Getting an inventory of all connected devices is of inventory of all connected devices is of prime importance for a
prime importance for a secure operation of a network. secure operation of a network.
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 the IPfix information and extract the
list of all IPv6 source addresses to find all IPv6 nodes that sent list of all IPv6 source addresses to find all IPv6 nodes that sent
packets through a router. This is very efficient but alas will not packets through a router. This is very efficient but alas will not
discover silent node that never transmitted such packets... Also, it discover silent node that never transmitted such packets. Also, it
must be noted that link-local addresses will never be discovered by must be noted that link-local addresses will never be discovered by
this means. 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 works only for local network, it consists in sending a Another way works only for local network, it consists in sending a
ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which
is all IPv6 nodes on the network. All nodes should reply to this is all IPv6 nodes on the network. All nodes should reply to this
ECHO_REQUEST per [RFC4443]. 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 metioned 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.
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 was enough to scan through multiple text-based Unix grep command was enough to scan through multiple text-based
files and extract all lines relevant to a specific IPv4 address. files and extract all lines relevant to a specific IPv4 address.
skipping to change at page 26, line 15 skipping to change at page 26, line 15
guidelines for the most known and deployed transition techniques. guidelines for the most known and deployed transition techniques.
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 traffics are native (easier to address translation, the IPv4 and IPv6 traffics are native (easier to
observe and secure) and should have the same network processing observe and secure) and should have the same network processing
(path, quality of service, ...). Dual stack allows you to gradually (path, quality of service, ...). Dual stack allows to gradually turn
turn IPv4 operations down when your IPv6 network is ready for prime IPv4 operations off when your IPv6 network is ready for prime time.
time. On the other hand, the operators have to manage two networks On the other hand, the operators have to manage two network stacks
with the added complexities. with the added complexities.
From an operational security perspective, this now means that you From an operational security perspective, this now means that you
have twice the exposure. One needs to think about protecting both have twice the exposure. One needs to think about protecting both
protocols now. At a minimum, the IPv6 portion of a dual stacked protocols now. At a minimum, the IPv6 portion of a dual stacked
network should maintain parity with IPv4 from a security policy point network should maintain parity with IPv4 from a security policy point
of view. Typically, the following methods are employed to protect of view. Typically, the following methods are employed to protect
IPv4 networks at the edge: IPv4 networks at the edge:
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
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. Also, given the end-to- configured to protect IPv6 communications. Also, given the end-to-
end connectivity that IPv6 provides, it is also recommended that end connectivity that IPv6 provides, it is also recommended that
hosts be fortified against threats. General device hardening hosts be fortified against threats. General device hardening
guidelines are provided in Section 2.8 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 over IPv6 link-local address or over a layer-2 adjacent victims over their IPv6 link-local address or over a
global IPv6 address is rogue RA or rogue DHCPv6 addresses are global IPv6 address once rogue RAs or rogue DHCPv6 addresses are
provided by an attacker. provided by an attacker.
2.7.2. Transition 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], all those tunnels have a couple of
security issues (most of them because they are tunnels and are security issues (most of them because they are tunnels and these
described in RFC 6169 [RFC6169]); issues are described in RFC 6169 [RFC6169]);
o tunnel injection: a malevolent person knowing a few pieces of o tunnel injection: a malevolent person knowing a few pieces of
information (for example the tunnel endpoints and the used information (for example the tunnel endpoints and the used
protocol) can forge a packet which looks like a legit and valid protocol) can forge a packet which looks like a legit and valid
encapsulated packet that will gladly be accepted by the encapsulated packet that will gladly be accepted by the
destination tunnel endpoint, this is a specific case of spoofing; destination tunnel endpoint, this is a specific 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), therefore anybody on the protocols (without the use of IPsec or alternative encryption
tunnel path can intercept the traffic and have access to the methods), therefore anybody on the tunnel path can intercept the
clear-text IPv6 packet; combined with the absence of traffic and have access to the clear-text IPv6 packet; combined
authentication, a man in the middle attack can also be mounted; with the absence of authentication, a man in the middle attack can
also be mounted;
o service theft: as there is no authorization, even a non authorized o service theft: as there is no authorization, even a non authorized
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 one IPv4 address of the relay router. but only one 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 IPS is on the path
of the tunnel, then it will probably neither inspect nor detect an of the tunnel, then it will probably neither inspect nor detect an
malevolent IPv6 traffic contained in the tunnel. malevolent IPv6 traffic contained in the tunnel.
To mitigate the bypassing of security policies, it is recomended to To mitigate the bypassing of security policies, it is recommended to
block all default configuration tunnels by denying all IPv4 traffic block all default configuration tunnels by denying all IPv4 traffic
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 protocol 3544: this will block the default encapsulation of
skipping to change at page 28, line 21 skipping to change at page 28, line 21
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 and protecting the encapsulated IPv4
packets is recommended for those tunnels. Alternatively, IPsec in packets is recommended for those tunnels. Alternatively, IPsec in
tunnel mode can be used to transport IPv6 traffic over a non-trusted tunnel mode can be used to transport IPv6 traffic over a non-trusted
IPv4 network. IPv4 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 means that endpoints and and the tunnel endpoint are network. This often implies that those systems are usually managed
usually managed by a single entity; therefore, audit trail and strict by a single entity; therefore, audit trail and strict anti-spoofing
anti-spoofing are usually possible and this raises the overall are usually possible and this raises the overall security.
security.
Special care must be taken to avoid looping attack by implementing Special care must be taken to avoid looping attack by implementing
the measures of RFC 6324 [RFC6324] and of [RFC6964]. the measures of RFC 6324 [RFC6324] and of [RFC6964].
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 little security issues except environment than 6to4 tunnels and have little security issues except
lack of confidentiality. The security considerations (Section 12) of lack of confidentiality. The security considerations (Section 12) of
[RFC5969] describes how to secure the 6rd tunnels. [RFC5969] describes how to secure the 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 and 6VPE 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 VPN described in [RFC4364], the really similar to BGP/MPLS IP VPN described in [RFC4364], the
security of these networks is also similar to the one described in security of these networks is also similar to the one described in
[RFC4381]. It relies on: [RFC4381]. It relies on:
o Address space, routing and traffic seperation with the help of VRF o Address space, routing and traffic seperation with the help of
(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
security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP
VPN. VPN.
LDPv6 itself does not induce new risks, see also [RFC7552].
2.7.2.5. DS-Lite 2.7.2.5. DS-Lite
DS-lite is more a translation mechanism and is therefore analyzed DS-lite is more a translation mechanism and is therefore analyzed
further (Section 2.7.3.3) in this document. further (Section 2.7.3.3) in this document.
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-E [RFC7597] and MAP-T [RFC7599]), the access network is and Port (MAP-E [RFC7597] and MAP-T [RFC7599]), the access network is
purely an IPv6 network and MAP protocols are used to give IPv4 hosts purely an IPv6 network and MAP protocols are used to give IPv4 hosts
skipping to change at page 30, line 36 skipping to change at page 30, line 39
the stateful IPv4 firewall allows unrestricted UDP outbound and the stateful IPv4 firewall allows unrestricted UDP outbound and
accept the return UDP traffic, then Teredo actually punches a hole in accept the return UDP traffic, then Teredo actually punches a hole in
this firewall for all IPv6 traffic to the Internet and from the 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. While 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, it would be
more efficient to block all UDP outbound traffic at the IPv4 firewall more efficient to block all UDP outbound traffic at the IPv4 firewall
if deemed possible (of course, at least port 53 should be left open if deemed possible (of course, at least port 53 should be left open
for DNS traffic). for DNS traffic).
Teredo is now mostly never used and it is no more automated in most Teredo is now mostly never used and it is no more automated in most
environment, so, it is less of a threat. environment, so, it is less of a threat, however, special
consideration must be taken in case of devices with older or non-
updated operating systems may be present, which by default were
running Teredo.
2.7.3. Translation Mechanisms 2.7.3. Translation Mechanisms
Translation mechanisms between IPv4 and IPv6 networks are alternative Translation mechanisms between IPv4 and IPv6 networks are alternative
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 in each individual mechanism. For the considerations are documented in each individual mechanism. For the
most part they specifically mention interference with IPsec or DNSSEC most part they specifically mention interference with IPsec or DNSSEC
deployments, how to mitigate spoofed traffic and what some effective deployments, how to mitigate spoofed traffic and what some effective
filtering strategies may be. filtering strategies may be.
2.7.3.1. Carrier-Grade Nat (CGN) 2.7.3.1. Carrier-Grade NAT (CGN)
Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT
(LSN) or SP NAT is described in [RFC6264] and is utilized as an (LSN) or SP NAT is described in [RFC6264] and is utilized as an
interim measure to prolong the use of IPv4 in a large service interim measure to prolong the use of IPv4 in a large service
provider network until the provider can deploy and effective IPv6 provider network until the provider can deploy and effective IPv6
solution. [RFC6598] requested a specific IANA allocated /10 IPv4 solution. [RFC6598] requested a specific IANA allocated /10 IPv4
address block to be used as address space shared by all access address block to be used as address space shared by all access
networks using CGN. This has been allocated as 100.64.0.0/10. networks using CGN. This has been allocated as 100.64.0.0/10.
Section 13 of [RFC6269] lists some specific security-related issues Section 13 of [RFC6269] lists some specific security-related issues
skipping to change at page 31, line 28 skipping to change at page 31, line 34
[RFC6302] has recommendations for Internet-facing servers to also log [RFC6302] has recommendations for Internet-facing servers to also log
the source TCP or UDP ports of incoming connections in an attempt to the source TCP or UDP ports of incoming connections in an attempt to
help identify the users behind such a CGN. help identify the users behind such a CGN.
[RFC7422] suggests the use of deterministic address mapping in order [RFC7422] suggests the use of deterministic address mapping in order
to reduce logging requirements for CGN. The idea is to have an to reduce logging requirements for CGN. The idea is to have an
algorithm mapping back and forth the internal subscriber to public algorithm mapping back and forth the internal subscriber to public
ports. ports.
2.7.3.2. NAT64/DNS64 2.7.3.2. NAT64/DNS64 and 464XLAT
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] (that obsoletes [RFC6145]) which is similar for the NAT64 [RFC7915] which is similar for the security aspects with the
security aspects with the added benefit of being stateless, so, less added benefit of being stateless, so, less prone to a state
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. A specific issue with the use of NAT64 is
that it will interfere with most IPsec deployments unless UDP that it will interfere with most IPsec deployments unless UDP
encapsulation is used. DNS64 has an incidence on DNSSEC see section encapsulation is used. DNS64 has an impact on DNSSEC see section 3.1
3.1 of [RFC7050]. of [RFC7050].
464XLAT [RFC6877] shares the same security considerations as NAT64
and DNS64, however it can be used without DNS64, avoiding the DNSSEC
implications.
2.7.3.3. DS-Lite 2.7.3.3. DS-Lite
Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that
enables a service provider to share IPv4 addresses among customers by enables a service provider to share IPv4 addresses among customers by
combining two well-known technologies: IP in IP (IPv4-in-IPv6) and combining two well-known technologies: IP in IP (IPv4-in-IPv6) and
Network Address and Port Translation (NAPT). Network Address and Port Translation (NAPT).
Security considerations with respect to DS-Lite mainly revolve around Security considerations with respect to DS-Lite mainly revolve around
logging data, preventing DoS attacks from rogue devices (as the AFTR logging data, preventing DoS attacks from rogue devices (as the
function is stateful) and restricting service offered by the AFTR Address Family Translation Router, AFTR [RFC6333] function is
only to registered customers. stateful) and restricting service offered by the AFTR only to
registered customers.
Section 11 of [RFC6333] describes important security issues Section 11 of [RFC6333] describes important security issues
associated with this technology. associated with this technology.
2.8. General Device Hardening 2.8. General Device Hardening
There are many environments which rely too much on the network There are many environments which rely too much on the network
infrastructure to disallow malicious traffic to get access to infrastructure to disallow malicious traffic to get access to
critical hosts. In new IPv6 deployments it has been common to see critical hosts. In new IPv6 deployments it has been common to see
IPv6 traffic enabled but none of the typical access control IPv6 traffic enabled but none of the typical access control
skipping to change at page 33, line 26 skipping to change at page 33, line 35
all traffic outbound while only allowing specific traffic, such as all traffic outbound while only allowing specific traffic, such as
established sessions, inbound (see also [RFC6092]). Here are a few established sessions, inbound (see also [RFC6092]). Here are a few
more things that could enhance the default policy: more things that could enhance the default policy:
o Filter internal-use IPv6 addresses at the perimeter o Filter internal-use IPv6 addresses at the perimeter
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] [CYMRU]
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] PMTUD, see also [RFC4890] or [REY_PF] for hosts
o Filter specific extension headers by accepting only the required o Filter specific extension headers by accepting only the required
ones (white list approach) such as ESP, AH (not forgetting the ones (white list approach) such as ESP, AH (not forgetting the
required transport layers: ICMP, TCP, UDP, ...) , where possible required transport layers: ICMP, TCP, UDP, ...) , where possible
at the edge and possibly inside the perimeter; see also at the edge and possibly inside the perimeter; see also
[I-D.gont-opsec-ipv6-eh-filtering] [I-D.gont-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 possible inside as well), see Section 2.2 perimeter (and possible inside as well), see Section 2.2
skipping to change at page 34, line 8 skipping to change at page 34, line 17
The internal aspect deals with providing security inside the The internal aspect deals with providing security inside the
perimeter of the network, including the end host. The most perimeter of the network, including the end host. The most
significant concerns here are related to Neighbor Discovery. At the significant concerns here are related to Neighbor Discovery. At the
network level, it is recommended that all security considerations network level, it is recommended that all security considerations
discussed in Section 2.3 be reviewed carefully and the discussed in Section 2.3 be reviewed carefully and the
recommendations be considered in-depth as well. recommendations be considered in-depth as well.
As mentioned in Section 2.6.2, care must be taken when running As mentioned in Section 2.6.2, care must be taken when running
automated IPv6-in-IP4 tunnels. automated IPv6-in-IP4 tunnels.
When site-to-site VPNs are used it should be kept in mind that, given
the global scope of IPv6 global addresses as opposed to the common
use of IPv4 private address space [RFC1918], sites might be able to
communicate with each other over the Internet even when the VPN
mechanism is not available and hence no traffic encryption is
performed and traffic could be injected from the Internet in the
site, see [WEBER_VPN]. It is recommended to filter at the Internet
connection(s) packets having a source or destination address
belonging to the site internal prefix(es); this should be done for
ingress and egress traffic.
Hosts need to be hardened directly through security policy to protect Hosts need to be hardened directly through security policy to protect
against security threats. The host firewall default capabilities against security threats. The host firewall default capabilities
have to be clearly understood, especially 3rd party ones which can have to be clearly understood, especially 3rd party ones which can
have different settings for IPv4 or IPv6 default permit/deny have different settings for IPv4 or IPv6 default permit/deny
behavior. In some cases, 3rd party firewalls have no IPv6 support behavior. In some cases, 3rd party firewalls have no IPv6 support
whereas the native firewall installed by default has it. General whereas the native firewall installed by default has it. General
device hardening guidelines are provided in Section 2.8 device hardening guidelines are provided in Section 2.8
It should also be noted that many hosts still use IPv4 for transport It should also be noted that many hosts still use IPv4 for transport
for things like RADIUS, TACACS+, SYSLOG, etc. This will require some for things like RADIUS, TACACS+, SYSLOG, etc. This will require some
skipping to change at page 34, line 33 skipping to change at page 35, line 5
The threats and mitigation techniques are identical between IPv4 and The threats and mitigation techniques are identical between IPv4 and
IPv6. Broadly speaking they are: IPv6. Broadly speaking they are:
o Authenticating the TCP session; o Authenticating the TCP session;
o TTL security (which becomes hop-limit security in IPv6); o TTL security (which becomes hop-limit security in IPv6);
o Prefix Filtering. o Prefix Filtering.
These are explained in more detail in section Section 2.5. These are explained in more detail in section Section 2.5. Also, the
recommendations of [RFC7454] should be considered.
4.1.1. Remote Triggered Black Hole Filtering 4.1.1. Remote Triggered Black Hole Filtering
RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has
allocated 100::/64 as discard prefix [RFC6666]. allocated 100::/64 as discard prefix [RFC6666].
4.2. Transition Mechanism 4.2. Transition Mechanism
SP will typically use transition mechanisms such as 6rd, 6PE, MAP, SP will typically use transition mechanisms such as 6rd, 6PE, MAP,
DS-Lite which have been analyzed in the transition Section 2.7.2 DS-Lite which have been analyzed in the transition Section 2.7.2
skipping to change at page 35, line 40 skipping to change at page 36, line 12
tablets have all IPv6 enabled by default, IPv6 security is important tablets have all IPv6 enabled by default, IPv6 security is important
for those users. Even with an IPv4-only ISP, those users can get for those users. Even with an IPv4-only ISP, those users can get
IPv6 Internet access with the help of Teredo tunnels. Several peer- IPv6 Internet access with the help of Teredo tunnels. Several peer-
to-peer programs (notably Bittorrent) support IPv6 and those programs to-peer programs (notably Bittorrent) support IPv6 and those programs
can initiate a Teredo tunnel through the IPv4 residential gateway, can initiate a Teredo tunnel through the IPv4 residential gateway,
with the consequence of making the internal host reachable from any with the consequence of making the internal host reachable from any
IPv6 host on the Internet. It is therefore recommended that all host IPv6 host on the Internet. It is therefore recommended that all host
security products (personal firewall, ...) are configured with a security products (personal firewall, ...) are configured with a
dual-stack security policy. dual-stack security policy.
If the Residential Gateway has IPv6 connectivity, [RFC7084] (that If the Residential Gateway has IPv6 connectivity, [RFC7084] defines
obsoletes [RFC6204]) defines the requirements of an IPv6 CPE and does the requirements of an IPv6 CPE and does not take position on the
not take position on the debate of default IPv6 security policy as debate of default IPv6 security policy as defined in [RFC6092]:
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 NAT-PT security policy enforced by IPv4 Residential Gateway doing NAT-PT
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;
o open/transparent: allowing all internally and externally initiated o open/transparent: allowing all internally and externally initiated
connections, therefore restoring the end-to-end nature of the connections, therefore restoring the end-to-end nature of the
Internet for the IPv6 traffic but having a different security Internet for the IPv6 traffic but having a different security
skipping to change at page 36, line 34 skipping to change at page 36, line 51
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, Brian comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, Brian
Carpenter, Tim Chown, Lorenzo Colitti, Markus deBruen, Tobias Fiebig, Carpenter, Tim Chown, Lorenzo Colitti, Markus de Bruen, Tobias
Fernando Gont, Jeffry Handal, Lee Howard, Panos Kampanakis, Erik Fiebig, Fernando Gont, Jeffry Handal, Lee Howard, Panos Kampanakis,
Kline, Jouni Korhonen, Mark Lentczner, Bob Sleigh,Tarko Tikan, Ole Erik Kline, Jouni Korhonen, Mark Lentczner, Jordi Palet, Bob Sleigh,
Troan, Bernie Volz (by alphabetical order). Tarko Tikan, Ole Troan, Bernie Volz (by alphabetical order).
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. 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 in an IPv6-only network and in operating an IPv6 network both in an IPv6-only network and in
utilizing the most widely deployed IPv4/IPv6 coexistence strategies. utilizing the most widely deployed IPv4/IPv6 coexistence strategies.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(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>.
10.2. Informative References 10.2. Informative References
[CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at [CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at
xSP routers", <http://www.team- xSP routers", <http://www.team-
cymru.org/ReadingRoom/Templates/IPv6Routers/ cymru.org/ReadingRoom/Templates/IPv6Routers/
skipping to change at page 37, line 48 skipping to change at page 38, line 17
Wasserman, "IPv6 Neighbor Discovery Optimizations for Wasserman, "IPv6 Neighbor Discovery Optimizations for
Wired and Wireless Networks", draft-chakrabarti-nordmark- Wired and Wireless Networks", draft-chakrabarti-nordmark-
6man-efficient-nd-07 (work in progress), February 2015. 6man-efficient-nd-07 (work in progress), February 2015.
[I-D.gont-opsec-ipv6-eh-filtering] [I-D.gont-opsec-ipv6-eh-filtering]
Gont, F., Will, W., and R. Bonica, "Recommendations on Gont, F., Will, W., and R. Bonica, "Recommendations on
Filtering of IPv6 Packets Containing IPv6 Extension Filtering of IPv6 Packets Containing IPv6 Extension
Headers", draft-gont-opsec-ipv6-eh-filtering-02 (work in Headers", draft-gont-opsec-ipv6-eh-filtering-02 (work in
progress), August 2014. progress), August 2014.
[I-D.ietf-dhc-sedhcpv6]
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017.
[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", draft- IPv6 Packets Containing IPv6 Extension Headers", draft-
ietf-opsec-ipv6-eh-filtering-06 (work in progress), July ietf-opsec-ipv6-eh-filtering-06 (work in progress), July
2018. 2018.
[I-D.ietf-v6ops-ula-usage-considerations] [I-D.ietf-v6ops-ula-usage-considerations]
Liu, B. and S. Jiang, "Considerations For Using Unique Liu, B. and S. Jiang, "Considerations For Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage- Local Addresses", draft-ietf-v6ops-ula-usage-
considerations-02 (work in progress), March 2017. considerations-02 (work in progress), March 2017.
skipping to change at page 38, line 47 skipping to change at page 39, line 10
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/
sp800-119.pdf>. sp800-119.pdf>.
[REY_PF] Rey, E., "Local Packet Filtering with IPv6", July 2017,
<https://labs.ripe.net/Members/enno_rey/
local-packet-filtering-with-ipv6>.
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>. <https://www.rfc-editor.org/info/rfc826>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
skipping to change at page 39, line 23 skipping to change at page 39, line 38
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, Domains without Explicit Tunnels", RFC 2529,
DOI 10.17487/RFC2529, March 1999, DOI 10.17487/RFC2529, March 1999,
<https://www.rfc-editor.org/info/rfc2529>. <https://www.rfc-editor.org/info/rfc2529>.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, DOI 10.17487/RFC2740, December 1999,
<https://www.rfc-editor.org/info/rfc2740>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
skipping to change at page 40, line 5 skipping to change at page 40, line 17
<https://www.rfc-editor.org/info/rfc2993>. <https://www.rfc-editor.org/info/rfc2993>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, DOI 10.17487/RFC3068, June 2001, RFC 3068, DOI 10.17487/RFC3068, June 2001,
<https://www.rfc-editor.org/info/rfc3068>. <https://www.rfc-editor.org/info/rfc3068>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, Considered Harmful", RFC 3627, DOI 10.17487/RFC3627,
September 2003, <https://www.rfc-editor.org/info/rfc3627>. September 2003, <https://www.rfc-editor.org/info/rfc3627>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004, RFC 3756, DOI 10.17487/RFC3756, May 2004,
<https://www.rfc-editor.org/info/rfc3756>. <https://www.rfc-editor.org/info/rfc3756>.
[RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture
skipping to change at page 42, line 25 skipping to change at page 42, line 36
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942, Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007, DOI 10.17487/RFC4942, September 2007,
<https://www.rfc-editor.org/info/rfc4942>. <https://www.rfc-editor.org/info/rfc4942>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, DOI 10.17487/RFC5157, March 2008,
<https://www.rfc-editor.org/info/rfc5157>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
DOI 10.17487/RFC5214, March 2008, DOI 10.17487/RFC5214, March 2008,
<https://www.rfc-editor.org/info/rfc5214>. <https://www.rfc-editor.org/info/rfc5214>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
skipping to change at page 43, line 24 skipping to change at page 43, line 34
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011, DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>. <https://www.rfc-editor.org/info/rfc6105>.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
April 2011, <https://www.rfc-editor.org/info/rfc6144>. April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<https://www.rfc-editor.org/info/rfc6145>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
skipping to change at page 44, line 5 skipping to change at page 44, line 14
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011, DOI 10.17487/RFC6169, April 2011,
<https://www.rfc-editor.org/info/rfc6169>. <https://www.rfc-editor.org/info/rfc6169>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/info/rfc6192>. March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, Ed., "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011,
<https://www.rfc-editor.org/info/rfc6204>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
DOI 10.17487/RFC6221, May 2011, DOI 10.17487/RFC6221, May 2011,
<https://www.rfc-editor.org/info/rfc6221>. <https://www.rfc-editor.org/info/rfc6221>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 45, line 5 skipping to change at page 45, line 9
[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>.
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506,
DOI 10.17487/RFC6506, February 2012,
<https://www.rfc-editor.org/info/rfc6506>.
[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>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012, RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/info/rfc6564>. <https://www.rfc-editor.org/info/rfc6564>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
skipping to change at page 46, line 9 skipping to change at page 46, line 5
<https://www.rfc-editor.org/info/rfc6666>. <https://www.rfc-editor.org/info/rfc6666>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Infrastructure (RPKI) to Router Protocol", RFC 6810, Combination of Stateful and Stateless Translation",
DOI 10.17487/RFC6810, January 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6810>. <https://www.rfc-editor.org/info/rfc6877>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
May 2013, <https://www.rfc-editor.org/info/rfc6939>. May 2013, <https://www.rfc-editor.org/info/rfc6939>.
[RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites Using the Intra-Site Automatic Tunnel IPv4 Sites Using the Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)", RFC 6964, Addressing Protocol (ISATAP)", RFC 6964,
DOI 10.17487/RFC6964, May 2013, DOI 10.17487/RFC6964, May 2013,
<https://www.rfc-editor.org/info/rfc6964>. <https://www.rfc-editor.org/info/rfc6964>.
skipping to change at page 48, line 15 skipping to change at page 48, line 10
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP", Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015, RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>. <https://www.rfc-editor.org/info/rfc7513>.
[RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast
Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, Prefix for 6to4 Relay Routers", BCP 196, RFC 7526,
DOI 10.17487/RFC7526, May 2015, DOI 10.17487/RFC7526, May 2015,
<https://www.rfc-editor.org/info/rfc7526>. <https://www.rfc-editor.org/info/rfc7526>.
[RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R.
Papneja, "Updates to LDP for IPv6", RFC 7552,
DOI 10.17487/RFC7552, June 2015,
<https://www.rfc-editor.org/info/rfc7552>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597, Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015, DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>. <https://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <https://www.rfc-editor.org/info/rfc7599>. 2015, <https://www.rfc-editor.org/info/rfc7599>.
skipping to change at page 49, line 15 skipping to change at page 49, line 15
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>. <https://www.rfc-editor.org/info/rfc8064>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
"Updates to the Special-Purpose IP Address Registries", "Updates to the Special-Purpose IP Address Registries",
BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
<https://www.rfc-editor.org/info/rfc8190>. <https://www.rfc-editor.org/info/rfc8190>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/info/rfc8210>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>. <https://www.rfc-editor.org/info/rfc8273>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[SCANNING] [SCANNING]
"Mapping the Great Void - Smarter scanning for IPv6", Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great
Void - Smarter scanning for IPv6", February 2012,
<http://www.caida.org/workshops/isma/1202/slides/ <http://www.caida.org/workshops/isma/1202/slides/
aims1202_rbarnes.pdf>. aims1202_rbarnes.pdf>.
[WEBER_VPN]
Weber, J., "Dynamic IPv6 Prefix - Problems and VPNs",
March 2018, <https://blog.webernetz.net/wp-
content/uploads/2018/03/TR18-Johannes-Weber-Dynamic-IPv6-
Prefix-Problems-and-VPNs.pdf>.
Authors' Addresses Authors' Addresses
Eric Vyncke (editor) Eric Vyncke (editor)
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
 End of changes. 84 change blocks. 
209 lines changed or deleted 206 lines changed or added

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