idnits 2.17.1
draft-ietf-opsec-v6-23.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 889: '... that "ESP-Null MUST and AH MAY be im...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 9, 2021) is 1172 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-10) exists of
draft-ietf-opsec-ipv6-eh-filtering-07
-- Obsolete informational reference (is this intentional?): RFC 2460
(Obsoleted by RFC 8200)
-- Obsolete informational reference (is this intentional?): RFC 3068
(Obsoleted by RFC 7526)
-- Obsolete informational reference (is this intentional?): RFC 3627
(Obsoleted by RFC 6547)
-- Obsolete informational reference (is this intentional?): RFC 4941
(Obsoleted by RFC 8981)
Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 OPSEC E. Vyncke
3 Internet-Draft Cisco
4 Intended status: Informational K. Chittimaneni
5 Expires: August 13, 2021 WeWork
6 M. Kaeo
7 Double Shot Security
8 E. Rey
9 ERNW
10 February 9, 2021
12 Operational Security Considerations for IPv6 Networks
13 draft-ietf-opsec-v6-23
15 Abstract
17 Knowledge and experience on how to operate IPv4 securely is
18 available: whether it is the Internet or an enterprise internal
19 network. However, IPv6 presents some new security challenges. RFC
20 4942 describes the security issues in the protocol, but network
21 managers also need a more practical, operations-minded document to
22 enumerate advantages and/or disadvantages of certain choices.
24 This document analyzes the operational security issues associated
25 with several types of network (enterprises, service providers, and
26 residential users) and proposes technical and procedural mitigation
27 techniques. The residential users case assumes a managed ISP CPE
28 device. Some very specific types of networks such as the Internet of
29 Things (IoT) and unmanaged home networks are not discussed in this
30 document.
32 Status of This Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at https://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on August 13, 2021.
49 Copyright Notice
51 Copyright (c) 2021 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (https://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
67 2. Generic Security Considerations . . . . . . . . . . . . . . . 4
68 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4
69 2.1.1. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 4
70 2.1.2. Point-to-Point Links . . . . . . . . . . . . . . . . 5
71 2.1.3. Loopback Addresses . . . . . . . . . . . . . . . . . 5
72 2.1.4. Stable Addresses . . . . . . . . . . . . . . . . . . 5
73 2.1.5. Temporary Addresses for SLAAC . . . . . . . . . . . . 6
74 2.1.6. DHCP and DNS Considerations . . . . . . . . . . . . . 7
75 2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 8
76 2.1.8. Privacy consideration of Addresses . . . . . . . . . 8
77 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 8
78 2.2.1. Order and Repetition of Extension Headers . . . . . . 9
79 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 9
80 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 9
81 2.2.4. IP Security Extension Header . . . . . . . . . . . . 10
82 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 10
83 2.3.1. Neighbor Solicitation Rate Limiting . . . . . . . . . 10
84 2.3.2. Router and Neighbor Advertisements Filtering . . . . 11
85 2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 12
86 2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 13
87 2.3.5. Impact of Multicast Traffic . . . . . . . . . . . . . 14
88 2.3.6. SeND and CGA . . . . . . . . . . . . . . . . . . . . 14
89 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 15
90 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 16
91 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 17
92 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 17
93 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 18
94 2.5.1. BGP Security . . . . . . . . . . . . . . . . . . . . 19
95 2.5.2. Authenticating OSPFv3 Neighbors . . . . . . . . . . . 19
96 2.5.3. Securing Routing Updates . . . . . . . . . . . . . . 20
97 2.5.4. Route Filtering . . . . . . . . . . . . . . . . . . . 20
98 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 20
99 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 21
100 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 26
101 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 28
102 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 29
103 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 29
104 2.7.2. Encapsulation Mechanisms . . . . . . . . . . . . . . 30
105 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 34
106 2.8. General Device Hardening . . . . . . . . . . . . . . . . 36
107 3. Enterprises Specific Security Considerations . . . . . . . . 36
108 3.1. External Security Considerations . . . . . . . . . . . . 37
109 3.2. Internal Security Considerations . . . . . . . . . . . . 38
110 4. Service Providers Security Considerations . . . . . . . . . . 38
111 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
112 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 39
113 4.2. Transition/Coexistence Mechanism . . . . . . . . . . . . 39
114 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 39
115 5. Residential Users Security Considerations . . . . . . . . . . 40
116 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 40
117 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
119 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
120 9.1. Normative References . . . . . . . . . . . . . . . . . . 41
121 9.2. Informative References . . . . . . . . . . . . . . . . . 41
122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
124 1. Introduction
126 Running an IPv6 network is new for most operators not only because
127 they are not yet used to large-scale IPv6 networks but also because
128 there are subtle but critical and important differences between IPv4
129 and IPv6, especially with respect to security. For example, all
130 layer-2 interactions are now done using Neighbor Discovery Protocol
131 [RFC4861] rather than using Address Resolution Protocol [RFC0826].
132 Also, there is no Network Address Port Translation (NAPT) defined in
133 [RFC2663] for IPv6 even if [RFC6296] specifies a Network Prefix
134 Translation for IPv6 (NPTv6) which is a 1-to-1 mapping of IPv6
135 addresses.
137 IPv6 networks are deployed using a variety of techniques, each of
138 which have their own specific security concerns.
140 This document complements [RFC4942] by listing all security issues
141 when operating a network (including various transition technologies).
142 It also provides more recent operational deployment experiences where
143 warranted.
145 2. Generic Security Considerations
147 2.1. Addressing Architecture
149 IPv6 address allocations and overall architecture are an important
150 part of securing IPv6. Initial designs, even if intended to be
151 temporary, tend to last much longer than expected. Although
152 initially IPv6 was thought to make renumbering easy, in practice it
153 may be extremely difficult to renumber without a proper IP Address
154 Management (IPAM) system. [RFC7010] introduces the mechanisms that
155 could be utilized for IPv6 site renumbering and tries to cover most
156 of the explicit issues and requirements associated with IPv6
157 renumbering.
159 A key task for a successful IPv6 deployment is to prepare an
160 addressing plan. Because an abundance of address space is available,
161 structuring an address plan around both services and geographic
162 locations allow address space to become a basis for more structured
163 security policies to permit or deny services between geographic
164 regions. [RFC6177] documents some operational considerations of
165 using different prefix size for address assignments to end sites.
167 A common question is whether companies should use Provider
168 Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from
169 a security perspective there is little difference. However, one
170 aspect to keep in mind is who has administrative ownership of the
171 address space and who is technically responsible if/when there is a
172 need to enforce restrictions on routability of the space, e.g., due
173 to malicious criminal activity originating from it. Relying on PA
174 address may also force the use of NPTv6 and therefore augmenting the
175 complexity of the operations including the security operations.
177 In [RFC7934], it is recommended that IPv6 network deployments provide
178 multiple IPv6 addresses from each prefix to general-purpose hosts and
179 it specifically does not recommend limiting a host to only one IPv6
180 address per prefix. It also recommends that the network give the
181 host the ability to use new addresses without requiring explicit
182 requests (for example by using SLAAC). Having by default multiple
183 IPv6 addresses per interface is a major change compared to the unique
184 IPv4 address per interface for hosts (secondary IPv4 addresses are
185 not common); especially for audits (see section Section 2.6.2.3).
187 2.1.1. Use of ULAs
189 Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
190 where interfaces are not globally reachable, despite being routed
191 within a domain. They formally have global scope, but [RFC4193]
192 specifies that they must be filtered at domain boundaries. ULAs are
193 different from [RFC1918] addresses and have different use cases. One
194 use of ULA is described in [RFC4864], another one is for internal
195 communication stability in networks where external connectivity may
196 came and go (e.g., some ISPs provide ULAs in home networks connected
197 via a cable modem).
199 2.1.2. Point-to-Point Links
201 [RFC6164] in section 5.1 specifies the rationale of using /127 for
202 inter-router point-to-point links; a /127 prevents the ping-pong
203 attack between routers not correctly implementing [RFC4443] and also
204 prevents a DoS attack on the neighbor cache. The previous
205 recommendation of [RFC3627] has been obsoleted and marked Historic by
206 [RFC6547]).
208 Some environments are also using link-local addressing for point-to-
209 point links. While this practice could further reduce the attack
210 surface of infrastructure devices, the operational disadvantages also
211 need to be carefully considered; see also [RFC7404].
213 2.1.3. Loopback Addresses
215 Many operators reserve a /64 block for all loopback addresses in
216 their infrastructure and allocate a /128 out of this reserved /64
217 prefix for each loopback interface. This practice facilitates
218 configuration of Access Control List (ACL) rules to enforce a
219 security policy for those loopback addresses
221 2.1.4. Stable Addresses
223 When considering how to assign stable addresses (either by static
224 configuration or by pre-provisioned DHCPv6 lease Section 2.1.6), it
225 is necessary to take into consideration the effectiveness of
226 perimeter security in a given environment.
228 There is a trade-off between ease of operation (where some portions
229 of the IPv6 address could be easily recognizable for operational
230 debugging and troubleshooting) versus the risk of trivial scanning
231 used for reconnaissance. [SCANNING] shows that there are
232 scientifically based mechanisms that make scanning for IPv6 reachable
233 nodes more feasible than expected; see also [RFC7707].
235 Stable addresses also allow easy enforcement of a security policy at
236 the perimeter based on IPv6 addresses. [RFC8520] is a mechanism
237 where the perimeter defense can retrieve security policy template
238 based on the type of internal device.
240 The use of well-known IPv6 addresses (such as ff02::1 for all link-
241 local nodes) or the use of commonly repeated addresses could make it
242 easy to figure out which devices are name servers, routers, or other
243 critical devices; even a simple traceroute will expose most of the
244 routers on a path. There are many scanning techniques possible and
245 operators should not rely on the 'impossible to find because my
246 address is random' paradigm (a.k.a. "security by obscurity"), even if
247 it is common practice to have the stable addresses randomly
248 distributed across /64 subnets and to always use DNS (as IPv6
249 addresses are hard to remember for the human brains).
251 While in some environments obfuscating addresses could be considered
252 an added benefit, it does not preclude enforcement of perimeter rules
253 and that stable addresses follow some logical allocation scheme for
254 ease of operation (as simplicity always helps security).
256 Typical deployments will have a mix of stable and non-stable
257 addresses; the stable addresses being either predicatable (e.g., ::25
258 for a mail server) or obfuscated (i.e., appearing as a random 64-bit
259 number).
261 2.1.5. Temporary Addresses for SLAAC
263 Historically, stateless address autoconfiguration (SLAAC) makes up
264 the globally unique IPv6 address based on an automatically generated
265 64-bit interface identifier (IID) based on the EUI-64 MAC address
266 combined with the /64 prefix (received in the Prefix Information
267 Option (PIO) of the Router Advertisement (RA)). The EUI-64 address
268 is generated from the stable 48-bit MAC address and does not change
269 even if the host moves to another network; this is of course bad for
270 privacy as a host (and its associated user) can be traced from
271 network (home) to network (office or Wi-Fi in hotels)... [RFC8064]
272 recommends against the use of EUI-64 addresses and it must be noted
273 that most host operating systems do not use EUI-64 addresses anymore
274 and rely on either [RFC4941] or [RFC8064].
276 Randomly generating an interface ID, as described in [RFC4941], is
277 part of SLAAC with so-called privacy extension addresses and is used
278 to address some privacy concerns. Privacy extension addresses,
279 a.k.a., temporary addresses may help to mitigate the correlation of
280 activities of a node within the same network and may also reduce the
281 attack exposure window. But using [RFC4941] privacy extension
282 addresses might prevent the operator from building host specific
283 access control lists (ACLs). The [RFC4941] privacy extension
284 addresses could also be used to obfuscate some malevolent activities
285 and specific user attribution/accountability procedures should be put
286 in place as described in Section 2.6.
288 [RFC8064] combined with the address generation mechanism of [RFC7217]
289 specifies another way to generate an address while still keeping the
290 same IID for each network prefix; this allows SLAAC nodes to always
291 have the same stable IPv6 address on a specific network while having
292 different IPv6 addresses on different networks.
294 In some specific use cases where user accountability is more
295 important than user privacy, network operators may consider disabling
296 SLAAC and relying only on DHCPv6; but not all operating systems
297 support DHCPv6 so some hosts will not get any IPv6 connectivity.
298 Disabling SLAAC and privacy extension addresses can be done for most
299 operating systems by sending RA messages with a hint to get addresses
300 via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting
301 all A-bits in all prefix information options. However, attackers
302 could still find ways to bypass this mechanism if not enforced at the
303 switch/router level.
305 However, in scenarios where anonymity is a strong desire (protecting
306 user privacy is more important than user attribution), privacy
307 extension addresses should be used. When [RFC8064] is available, the
308 stable privacy address is probably a good balance between privacy
309 (among different networks) and security/user attribution (within a
310 network).
312 2.1.6. DHCP and DNS Considerations
314 Even if the use of DHCP is not mandated by [RFC8504], some
315 environments use DHCPv6 to provision addresses and other parameters
316 in order to ensure auditability and traceability (see
317 Section 2.6.1.5) for the limitations of DHCPv6 for auditability.
319 A main security concern is the ability to detect and counteract rogue
320 DHCP servers (Section 2.3.3). It must be noted that as opposed to
321 DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For
322 DHCPv4, the lease is bond to the 'client identifier', which may
323 contain a hardware address, or it may contain another type of
324 identifier, such as a DNS name. For DHCPv6, the lease is bound to
325 the client DHCP Unique ID (DUID) which is also not always bound to
326 the client link-layer address. [RFC7824] describes the privacy
327 issues associated with the use of DHCPv6 by Internet users. The
328 anonymity profiles [RFC7844] are designed for clients that wish to
329 remain anonymous to the visited network. [RFC7707] recommends that
330 DHCPv6 servers issue addresses randomly from a large pool.
332 While there are no fundamental differences with IPv4 and IPv6 DNS
333 security concerns, there are specific considerations in DNS64
334 [RFC6147] environments that need to be understood. Specifically, the
335 interactions and the potential of interference with DNSSEC
336 ([RFC4033]) implementation need to be understood - these are pointed
337 out in more detail in Section 2.7.3.2.
339 2.1.7. Using a /64 per host
341 An interesting approach is using a /64 per host as proposed in
342 [RFC8273] especially in a shared environment. This allows for easier
343 user attribution (typically based on the host MAC address) as its /64
344 prefix is stable even if applications within the host can change
345 their IPv6 address within this /64 prefix.
347 2.1.8. Privacy consideration of Addresses
349 Beside the security aspects of IPv6 addresses, there are also privacy
350 considerations: mainly because they are of global scope and visible
351 globally. [RFC7721] goes into more detail on the privacy
352 considerations for IPv6 addresses by comparing the manually
353 configured IPv6 address, DHCPv6 or SLAAC.
355 2.2. Extension Headers
357 Extension headers are an important difference between IPv4 and IPv6.
358 In IPv4-based packets, it's trivial to find the upper layer protocol
359 type and protocol header, while in IPv6 it is more complex since the
360 extension header chain must be parsed completely (even if not
361 processed) in order to find the upper layer protocol header. IANA
362 has closed the existing empty "Next Header Types" registry to new
363 entries and is redirecting its users to a new "IPv6 Extension Header
364 Types" registry per [RFC7045].
366 Extension headers have also become a very controversial topic since
367 forwarding nodes that discard packets containing extension headers
368 are known to cause connectivity failures and deployment problems
369 [RFC7872]. Understanding the role of varying extension headers is
370 important and this section enumerates the ones that need careful
371 consideration.
373 A clarification on how intermediate nodes should handle packets with
374 existing or future extension headers is found in [RFC7045]. The
375 uniform TLV format to be used for defining future extension headers
376 is described in [RFC6564]. Sections 5.2 and 5.3 of [RFC8504] provide
377 more information on the processing of extension headers by IPv6
378 nodes.
380 It must also be noted that there is no indication in the IPv6 packet
381 as to whether the Next Protocol field points to an extension header
382 or to a transport header. This may confuse some filtering rules.
384 There is IETF work in progress regarding filtering rules for those
385 extension headers: [I-D.ietf-opsec-ipv6-eh-filtering] for transit
386 routers.
388 2.2.1. Order and Repetition of Extension Headers
390 While [RFC8200] recommends the order and the maximum repetition of
391 extension headers, there are still IPv6 implementations, at the time
392 of writing, which support a non-recommended order of headers (such as
393 ESP before routing) or an illegal repetition of headers (such as
394 multiple routing headers). The same applies for options contained in
395 the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]).
396 In some cases, it has led to nodes crashing when receiving or
397 forwarding wrongly formatted packets.
399 A firewall or edge device should be used to enforce the recommended
400 order and the maximum of occurrences of extension headers.
402 2.2.2. Hop-by-Hop Options Header
404 In the previous IPv6 specification [RFC2460], the hop-by-hop options
405 header, when present in an IPv6 packet, forced all nodes to inspect
406 and possibly process this header. This enabled denial-of-service
407 attacks as most, if not all, routers can not process this kind of
408 packet in hardware but have to process this packet in software hence
409 competing with other software tasks such as handling the control and
410 management planes.
412 Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has
413 taken this attack vector into account and made the processing of hop-
414 by-hop options header by intermediate routers explicitly
415 configurable.
417 2.2.3. Fragment Header
419 The fragment header is used by the source (and only the source) when
420 it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200]
421 explain why it is important that:
423 Firewall and security devices should drop first fragments that do
424 not contain the entire ipv6 header chain (including the transport-
425 layer header);
427 Destination nodes should discard first fragments that do not
428 contain the entire ipv6 header chain (including the transport-
429 layer header).
431 If those requirements are not met, stateless filtering could be
432 bypassed by a hostile party. [RFC6980] applies a stricter rule to
433 Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented
434 NDP packets. [RFC7113] describes how the RA-guard function described
435 in [RFC6105] should behave in the presence of fragmented RA packets.
437 2.2.4. IP Security Extension Header
439 The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP
440 [RFC4303]) are required if IPsec is to be utilized for network level
441 security. But IPsec is no more required for normal IPv6 nodes: in
442 the updated IPv6 Nodes Requirement standard
443 IPsec is a 'SHOULD' and not a 'MUST' implement.
445 2.3. Link-Layer Security
447 IPv6 relies heavily on NDP [RFC4861] to perform a variety of link
448 operations such as discovering other nodes on the link, resolving
449 their link-layer addresses, and finding routers on the link. If not
450 secured, NDP is vulnerable to various attacks such as router/neighbor
451 message spoofing, redirect attacks, Duplicate Address Detection (DAD)
452 DoS attacks, etc. Many of these security threats to NDP have been
453 documented in IPv6 ND Trust Models and Threats [RFC3756] and in
454 [RFC6583].
456 NDP has even issues when the attacker is off-link see the section
457 below Section 2.3.1; but, most of the issues are only when the
458 attacker is on the same link.
460 2.3.1. Neighbor Solicitation Rate Limiting
462 Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial
463 of service (DoS) attacks; for example, when a router is forced to
464 perform address resolution for a large number of unassigned
465 addresses, i.e., a neighbor cache exhaustion attack. This can keep
466 new devices from joining the network or render the last hop router
467 ineffective due to high CPU usage. Easy mitigative steps include
468 rate limiting Neighbor Solicitations, restricting the amount of state
469 reserved for unresolved solicitations, and clever cache/timer
470 management.
472 [RFC6583] discusses the potential for off-link DoS in detail and
473 suggests implementation improvements and operational mitigation
474 techniques that may be used to mitigate or alleviate the impact of
475 such attacks. Here are some feasible mitigation options that can be
476 employed by network operators today:
478 o Ingress filtering of unused addresses by ACL. These require
479 stable configuration of the addresses; for example, allocating the
480 addresses out of a /120 and using a specific ACL to only allow
481 traffic to this /120 (of course, the actual hosts are configured
482 with a /64 prefix for the link).
484 o Tuning of NDP process (where supported).
486 o Using /127 on point-to-point link per [RFC6164].
488 o Using link-local addresses only on links where there are only
489 routers see [RFC7404]
491 2.3.2. Router and Neighbor Advertisements Filtering
493 2.3.2.1. Router Advertisement Filtering
495 Router Advertisement spoofing is a well-known on-link attack vector
496 and has been extensively documented. The presence of rogue RAs,
497 either unintentional or malicious, can cause partial or complete
498 failure of operation of hosts on an IPv6 link. For example, a host
499 can select an incorrect router address which can be used as on-path
500 attack or can assume wrong prefixes to be used for SLAAC. [RFC6104]
501 summarizes the scenarios in which rogue RAs may be observed and
502 presents a list of possible solutions to the problem. [RFC6105] (RA-
503 Guard) describes a solution framework for the rogue RA problem where
504 network segments are designed around switching devices that are
505 capable of identifying invalid RAs and blocking them before the
506 attack packets actually reach the target nodes.
508 However, several evasion techniques that circumvent the protection
509 provided by RA-Guard have surfaced. A key challenge to this
510 mitigation technique is introduced by IPv6 fragmentation. Attacker
511 can conceal their attack by fragmenting their packets into multiple
512 fragments such that the switching device that is responsible for
513 blocking invalid RAs cannot find all the necessary information to
514 perform packet filtering of the same packet. [RFC7113] describes
515 such evasion techniques and provides advice to RA-Guard implementers
516 such that the aforementioned evasion vectors can be eliminated.
518 Given that the IPv6 Fragmentation Header can be leveraged to
519 circumvent current implementations of RA-Guard, [RFC6980] updates
520 [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden
521 in all Neighbor Discovery messages except "Certification Path
522 Advertisement", thus allowing for simple and effective measures to
523 counter fragmented NDP attacks.
525 2.3.2.2. Neighbor Advertisement Filtering
527 The Source Address Validation Improvements (SAVI) working group has
528 worked on other ways to mitigate the effects of such attacks.
529 [RFC7513] helps in creating bindings between a DHCPv4 [RFC2131]
530 /DHCPv6 [RFC8415] assigned source IP address and a binding anchor
531 [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean
532 similar bindings when DHCP is not used. The bindings can be used to
533 filter packets generated on the local link with forged source IP
534 addresses.
536 2.3.2.3. Host Isolation
538 Isolating hosts for the NDP traffic canbe done by using a /64 per
539 host Section 2.1.7 as NDP is only relevant within a /64 on-link
540 prefix; 3GPP Section 2.3.4 uses a similar mechanism.
542 A more drastic technique to prevent all NDP attacks is based on
543 isolation of all hosts with specific configurations. Hosts (i.e.,
544 all nodes that are not routers) are unable to send data-link layer
545 frames to other hosts, therefore, no host-to-host attacks can happen.
546 This specific setup can be established on some switches or Wi-Fi
547 access points. Of course, this is not always feasible when hosts
548 need to communicate with other hosts.
550 2.3.2.4. NDP Recommendations
552 It is still recommended that RA-Guard and SAVI be employed as a first
553 line of defense against common attack vectors including misconfigured
554 hosts. This recommendation also applies when DHCPv6 is used as RA
555 are used to discover the default router(s) and for on-link prefix
556 determination. This line of defense is most effective when
557 incomplete fragments are dropped by routers and switches as described
558 in Section 2.2.3. The generated log should also be analyzed to
559 identify and act on violations. Network operators should be aware
560 that RA-Guard and SAVI do not work or could even be harmful in
561 specific network configurations (notably when there could be multiple
562 routers). Only trivial cases (e.g., a Wi-Fi network having the
563 routers on the uplink interfaces of the As) should have RA-guard and
564 SAVI enabled by default.
566 2.3.3. Securing DHCP
568 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
569 in [RFC8415], enables DHCP servers to pass configuration parameters
570 such as IPv6 network addresses and other configuration information to
571 IPv6 nodes such as an hostile recursive DNS server. DHCP plays an
572 important role in most large networks by providing robust stateful
573 configuration in the context of automated system provisioning.
575 The two most common threats to DHCP clients come from malicious
576 (a.k.a., rogue) or unintentionally misconfigured DHCP servers. A
577 malicious DHCP server is established with the intent of providing
578 incorrect configuration information to the clients to cause a denial
579 of service attack or to mount on path attack. While unintentional, a
580 misconfigured DHCP server can have the same impact. Additional
581 threats against DHCP are discussed in the security considerations
582 section of [RFC8415].
584 DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting
585 connected DHCPv6 clients against rogue DHCPv6 servers. This
586 mechanism is based on DHCPv6 packet-filtering at the layer-2 device;
587 i.e., the administrator specifies the interfaces connected to DHCPv6
588 servers. However, extension headers could be leveraged to bypass
589 DHCPv6-Shield unless [RFC7112] is enforced.
591 It is recommended to use DHCPv6-Shield and to analyze the
592 corresponding log messages.
594 2.3.4. 3GPP Link-Layer Security
596 The 3GPP link is a point-to-point like link that has no link-layer
597 address. This implies there can only be an end host (the mobile
598 hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node
599 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never
600 configures a non link-local address on the link using the advertised
601 /64 prefix on it; see Section 2.1.7. The advertised prefix must not
602 be used for on-link determination. There is no need for address
603 resolution on the 3GPP link, since there are no link-layer addresses.
604 Furthermore, the GGSN/PGW assigns a prefix that is unique within each
605 3GPP link that uses IPv6 stateless address autoconfiguration. This
606 avoids the necessity to perform DAD at the network level for every
607 address built by the mobile host. The GGSN/PGW always provides an
608 IID to the cellular host for the purpose of configuring the link-
609 local address and ensures the uniqueness of the IID on the link
610 (i.e., no collisions between its own link-local address and the
611 mobile host's address).
613 The 3GPP link model itself mitigates most of the known NDP-related
614 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to
615 route all traffic to the mobile host that falls under the prefix
616 assigned to it. As there is also a single host on the 3GPP link,
617 there is no need to defend that IPv6 address.
619 See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP
620 link model, NDP on it and the address configuration details. In some
621 mobile network, DHCPv6 and DHCP-PD are also used.
623 2.3.5. Impact of Multicast Traffic
625 IPv6 uses multicast extensively for signaling messages on the local
626 link to avoid broadcast messages for on-the-wire efficiency.
628 The use of multicast has some side effects on wireless networks, such
629 as a negative impact on battery life of smartphones and other
630 battery-operated devices that are connected to such networks.
631 [RFC7772], [RFC6775] (for specific wireless networks) are discussing
632 methods to rate limit RAs and other ND messages on wireless networks
633 in order to address this issue.
635 The use of link-layer multicast addresses (e.g., ff02::1 for the all
636 nodes link-local multicast address) could also be mis-used for an
637 amplification attack. Image, a hostile node sending an ICMPv6
638 ECHO_REQUEST to ff02::1 with a spoofed source address, then, all
639 link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the
640 source address. This could be a DoS for the victim. This attack is
641 purely local to the layer-2 network as packets with a link-local
642 destination are never forwarded by an IPv6 router.
644 This is the reason why large Wi-Fi network deployments limit the use
645 of link-layer multicast either from or to the uplink of the Wi-Fi
646 access point; i.e., Wi-Fi stations cannot send link-local multicast
647 to their direct neighboring Wi-Fi stations.
649 2.3.6. SeND and CGA
651 SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a
652 mechanism that was designed to secure ND messages. This approach
653 involves the use of new NDP options to carry public key-based
654 signatures. Cryptographically Generated Addresses (CGA), as
655 described in [RFC3972], are used to ensure that the sender of a
656 Neighbor Discovery message is the actual "owner" of the claimed IPv6
657 address. A new NDP option, the CGA option, was introduced and is
658 used to carry the public key and associated parameters. Another NDP
659 option, the RSA Signature option, is used to protect all messages
660 relating to neighbor and Router discovery.
662 SeND protects against:
664 o Neighbor Solicitation/Advertisement Spoofing
666 o Neighbor Unreachability Detection Failure
667 o Duplicate Address Detection DoS Attack
669 o Router Solicitation and Advertisement Attacks
671 o Replay Attacks
673 o Neighbor Discovery DoS Attacks
675 SeND does NOT:
677 o Protect statically configured addresses
679 o Protect addresses configured using fixed identifiers (i.e., EUI-
680 64)
682 o Provide confidentiality for NDP communications
684 o Compensate for an unsecured link - SEND does not require that the
685 addresses on the link and Neighbor Advertisements correspond.
687 However, at this time and over a decade since their original
688 specifications, CGA and SeND do not have wide support from widely
689 used end points; hence, their usefulness is limited and should not be
690 relied upon.
692 2.4. Control Plane Security
694 [RFC6192] defines the router control plane and provides detailed
695 guidance to secure it for IPv4 and IPv6 networks. This definition is
696 repeated here for the reader's convenience. Please note that the
697 definition is completely protocol-version agnostic (most of this
698 section applies to IPv6 in the same way as to IPv4).
700 Preamble: IPv6 control plane security is vastly congruent with its
701 IPv4 equivalent with the exception of OSPFv3 authentication
702 (Section 2.4.1) and some packet exceptions (see Section 2.4.3) that
703 are specific to IPv6.
705 Modern router architecture design maintains a strict separation of
706 forwarding and router control plane hardware and software. The
707 router control plane supports routing and management functions. It
708 is generally described as the router architecture hardware and
709 software components for handling packets destined to the device
710 itself, as well as, building and sending packets originated locally
711 on the device. The forwarding plane is typically described as the
712 router architecture hardware and software components responsible for
713 receiving a packet on an incoming interface, performing a lookup to
714 identify the packet's IP next hop and best outgoing interface towards
715 the destination, and forwarding the packet through the appropriate
716 outgoing interface.
718 While the forwarding plane is usually implemented in high-speed
719 hardware, the control plane is implemented by a generic processor
720 (referred to as the router processor (RP)) and cannot process packets
721 at a high rate. Hence, this processor can be attacked by flooding
722 its input queue with more packets than it can process. The control
723 plane processor is then unable to process valid control packets and
724 the router can lose OSPF or BGP adjacencies which can cause a severe
725 network disruption.
727 [RFC6192] provides detailed guidance to protect the router control
728 plane in IPv6 networks. The rest of this section contains simplified
729 guidance.
731 The mitigation techniques are:
733 o To drop non-legit control packet before they are queued to the RP
734 (this can be done by a forwarding plane ACL) and
736 o To rate limit the remaining packets to a rate that the RP can
737 sustain. Protocol specific protection should also be done (for
738 example, a spoofed OSPFv3 packet could trigger the execution of
739 the Dijkstra algorithm, therefore, the frequency of Dijsktra
740 calculations should be also rate limited).
742 This section will consider several classes of control packets:
744 o Control protocols: routing protocols: such as OSPFv3, BGP and by
745 extension Neighbor Discovery and ICMP
747 o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc
749 o Packet exceptions: normal data packets which requires a specific
750 processing such as generating a packet-too-big ICMP message or
751 processing the hop-by-hop options header.
753 2.4.1. Control Protocols
755 This class includes OSPFv3, BGP, NDP, ICMP.
757 An ingress ACL to be applied on all the router interfaces for packets
758 to be processed by the RP should be configured so as to:
760 o drop OSPFv3 (identified by Next-Header being 89) and RIPng
761 (identified by UDP port 521) packets from a non link-local address
762 (except for OSPFv3 virtual links)
764 o allow BGP (identified by TCP port 179) packets from all BGP
765 neighbors and drop the others
767 o allow all ICMP packets (transit and to the router interfaces)
769 Note: dropping OSPFv3 packets which are authenticated by IPsec could
770 be impossible on some routers whose ACL are unable to parse the IPsec
771 ESP or AH extension headers.
773 Rate limiting of the valid packets should be done. The exact
774 configuration will depend on the available resources of the router
775 (CPU, TCAM, ...).
777 2.4.2. Management Protocols
779 This class includes: SSH, SNMP, RESTCONF, NETCONF, gRPC, syslog, NTP,
780 etc.
782 An ingress ACL to be applied on all the router interfaces (or at
783 ingress interfaces of the security perimeter or by using specific
784 features of the platform) should be configured for packets destined
785 to the RP such as:
787 o Drop packets destined to the routers except those belonging to
788 protocols which are used (for example, permit TCP 22 and drop all
789 when only SSH is used);
791 o Drop packets where the source does not match the security policy,
792 for example if SSH connections should only be originated from the
793 NOC, then the ACL should permit TCP port 22 packets only from the
794 NOC prefix.
796 Rate limiting of the valid packets should be done. The exact
797 configuration will depend on the available resources of the router.
799 2.4.3. Packet Exceptions
801 This class covers multiple cases where a data plane packet is punted
802 to the route processor because it requires specific processing:
804 o generation of an ICMP packet-too-big message when a data plane
805 packet cannot be forwarded because it is too large (required to
806 discover the Path MTU);
808 o generation of an ICMP hop-limit-expired message when a data plane
809 packet cannot be forwarded because its hop-limit field has reached
810 0 (also used by the traceroute utility);
812 o generation of an ICMP destination-unreachable message when a data
813 plane packet cannot be forwarded for any reason;
815 o processing of the hop-by-hop options header, new implementations
816 follow section 4.3 of [RFC8200] where this processing is optional;
818 o or more specific to some router implementation: an oversized
819 extension header chain which cannot be processed by the hardware
820 and force the packet to be punted to the RP.
822 On some routers, not everything can be done by the specialized data
823 plane hardware which requires some packets to be 'punted' to the
824 generic RP. This could include for example the processing of a long
825 extension header chain in order to apply an ACL based on layer-4
826 information. [RFC6980] and more generally [RFC7112] highlight the
827 security implications of oversized extension header chains on routers
828 and updates the original IPv6 specifications, [RFC2460], such that
829 the first fragment of a packet is required to contain the entire IPv6
830 header chain. Those changes are incorporated in the IPv6 standard
831 [RFC8200]
833 An ingress ACL cannot mitigate a control plane attack using these
834 packet exceptions. The only protection for the RP is to limit the
835 rate of those packet exceptions forwarded to the RP, this means that
836 some data plane packets will be dropped without an ICMP message sent
837 to the source which may delay Path MTU discovery and cause drops.
839 In addition to limiting the rate of data plane packets queued to the
840 RP, it is also important to limit the generation rate of ICMP
841 messages. This is important both to preserve RP resources and also
842 to prevent an amplification attack using the router as a reflector.
843 It is worth noting that some platforms implement this rate limiting
844 in hardware. Of course, a consequence of not generating an ICMP
845 message will break some IPv6 mechanisms such as Path MTU discovery or
846 a simple traceroute.
848 2.5. Routing Security
850 Preamble: IPv6 routing security is congruent with IPv4 routing
851 security at the exception of OSPv3 neighbor authentication (see
852 Section 2.5.2).
854 Routing security in general can be broadly divided into three
855 sections:
857 1. Authenticating neighbors/peers
859 2. Securing routing updates between peers
860 3. Route filtering
862 [RFC5082] is also applicable to IPv6 and can ensure that routing
863 protocol packets are coming from the local network; it must also be
864 noted that in IPv6 all interior gateway protocols use link-local
865 addresses.
867 As for IPv4, it is recommended to enable a routing protocol only on
868 interface where it is required.
870 2.5.1. BGP Security
872 As BGP is identical for IPv4 and IPv6 and as [RFC7454] covers all the
873 security aspects for BGP in detail, [RFC7454] is also applicable to
874 IPv6.
876 2.5.2. Authenticating OSPFv3 Neighbors
878 OSPFv3 can rely on IPsec to fulfill the authentication function.
879 However, it should be noted that IPsec support is not standard on all
880 routing platforms. In some cases, this requires specialized hardware
881 that offloads crypto over to dedicated ASICs or enhanced software
882 images (both of which often come with added financial cost) to
883 provide such functionality. An added detail is to determine whether
884 OSPFv3 IPsec implementations use AH or ESP-Null for integrity
885 protection. In early implementations, all OSPFv3 IPsec
886 configurations relied on AH since the details weren't specified in
887 [RFC5340]. However, the document which specifically describes how
888 IPsec should be implemented for OSPFv3 [RFC4552] specifically states
889 that "ESP-Null MUST and AH MAY be implemented" since it follows the
890 overall IPsec standards wording. OSPFv3 can also use normal ESP to
891 encrypt the OSPFv3 payload to provide confidentiality for the routing
892 information.
894 [RFC7166] changes OSPFv3 reliance on IPsec by appending an
895 authentication trailer to the end of the OSPFv3 packets; it does not
896 specifically authenticate the specific originator of an OSPFv3
897 packet; rather, it allows a router to confirm that the packet has
898 been issued by a router that had access to the shared authentication
899 key.
901 With all authentication mechanisms, operators should confirm that
902 implementations can support re-keying mechanisms that do not cause
903 outages. There have been instances where any re-keying cause outages
904 and therefore, the tradeoff between utilizing this functionality
905 needs to be weighed against the protection it provides.
907 2.5.3. Securing Routing Updates
909 IPv6 initially mandated the provisioning of IPsec capability in all
910 nodes. However, in the updated IPv6 Nodes Requirement standard
911 [RFC8504] is a 'SHOULD' and not a 'MUST' implement. Theoretically it
912 is possible that communication between two IPv6 nodes, especially
913 routers exchanging routing information be encrypted using IPsec. In
914 practice however, deploying IPsec is not always feasible given
915 hardware and software limitations of various platforms deployed.
917 2.5.4. Route Filtering
919 Route filtering policies will be different depending on whether they
920 pertain to edge route filtering vs internal route filtering. At a
921 minimum, IPv6 routing policy as it pertains to routing between
922 different administrative domains should aim to maintain parity with
923 IPv4 from a policy perspective, e.g.,
925 o Filter internal-use, non-globally routable IPv6 addresses at the
926 perimeter;
928 o Discard routes for bogon [CYMRU] and reserved space (see
929 [RFC8190]);
931 o Configure ingress route filters that validate route origin, prefix
932 ownership, etc. through the use of various routing databases,
933 e.g., [RADB]. There is additional work being done in this area to
934 formally validate the origin ASs of BGP announcements in
935 [RFC8210].
937 Some good guidance can be found at [RFC7454].
939 A valid routing table can also be used apply network ingress
940 filtering (see [RFC2827]).
942 2.6. Logging/Monitoring
944 In order to perform forensic research in the cases of a security
945 incidents or detection abnormal behavior, network operators should
946 log multiple pieces of information in some cases this requires a
947 frequent poll of devices via a Network Management Station.
949 This logging should include:
951 o logs of all applications using the network (including user space
952 and kernel space) when available (for example web servers);
954 o data from IP Flow Information Export [RFC7011] also known as
955 IPFIX;
957 o data from various SNMP MIBs [RFC4293] or YANG data via RESTCONF
958 [RFC8040] or NETCONF [RFC6241];
960 o historical data of Neighbor Cache entries;
962 o stateful DHCPv6 [RFC8415] lease cache, especially when a relay
963 agent [RFC6221] is used;
965 o Source Address Validation Improvement (SAVI) [RFC7039] events,
966 especially the binding of an IPv6 address to a MAC address and a
967 specific switch or router interface;
969 o RADIUS [RFC2866] accounting records.
971 Please note that there are privacy issues or regulations related to
972 how these logs are collected, stored, and safely discarded.
973 Operators are urged to check their country legislation (e.g., General
974 Data Protection Regulation GDPR [GDPR] in the European Union).
976 All those pieces of information can be used for:
978 o forensic (Section 2.6.2.1) investigations such as who did what and
979 when?
981 o correlation (Section 2.6.2.3): which IP addresses were used by a
982 specific node (assuming the use of privacy extensions addresses
983 [RFC4941])
985 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network?
987 o abnormal behavior detection (Section 2.6.2.4): unusual traffic
988 patterns are often the symptoms of an abnormal behavior which is
989 in turn a potential attack (denial of service, network scan, a
990 node being part of a botnet, etc.)
992 2.6.1. Data Sources
994 This section lists the most important sources of data that are useful
995 for operational security.
997 2.6.1.1. Application Logs
999 Those logs are usually text files where the remote IPv6 address is
1000 stored in clear text (not binary). This can complicate the
1001 processing since one IPv6 address, for example 2001:db8::1 can be
1002 written in multiple ways, such as:
1004 o 2001:DB8::1 (in uppercase)
1006 o 2001:0db8::0001 (with leading 0)
1008 o and many other ways including the reverse DNS mapping into a FQDN
1009 (which should not be trusted).
1011 [RFC5952] explains this problem in detail and recommends the use of a
1012 single canonical format. This document recommends the use of
1013 canonical format [RFC5952] for IPv6 addresses in all possible cases.
1014 If the existing application cannot log under the canonical format,
1015 then it is recommended to use an external program in order to
1016 canonicalize all IPv6 addresses.
1018 For example, this perl script can be used:
1020
1022 #!/usr/bin/perl -w
1023 use strict ;
1024 use warnings ;
1025 use Socket ;
1026 use Socket6 ;
1028 my (@words, $word, $binary_address) ;
1030 ## go through the file one line at a time
1031 while (my $line = ) {
1032 chomp $line;
1033 foreach my $word (split /[\s+]/, $line) {
1034 $binary_address = inet_pton AF_INET6, $word ;
1035 if ($binary_address) {
1036 print inet_ntop AF_INET6, $binary_address ;
1037 } else {
1038 print $word ;
1039 }
1040 print " " ;
1041 }
1042 print "\n" ;
1043 }
1045
1047 2.6.1.2. IP Flow Information Export by IPv6 Routers
1049 IPFIX [RFC7012] defines some data elements that are useful for
1050 security:
1052 o in section 5.4 (IP Header fields): nextHeaderIPv6 and
1053 sourceIPv6Address;
1055 o in section 5.6 (Sub-IP fields) sourceMacAddress.
1057 The IP version is the ipVersion element defined in [IANA-IPFIX].
1059 Moreover, IPFIX is very efficient in terms of data handling and
1060 transport. It can also aggregate flows by a key such as
1061 sourceMacAddress in order to have aggregated data associated with a
1062 specific sourceMacAddress. This memo recommends the use of IPFIX and
1063 aggregation on nextHeaderIPv6, sourceIPv6Address, and
1064 sourceMacAddress.
1066 2.6.1.3. SNMP MIB and NETCONF/RESTCONF YANG Modules data by IPv6
1067 Routers
1069 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for
1070 the two address families of IP. This memo recommends the use of:
1072 o ipIfStatsTable table which collects traffic counters per
1073 interface;
1075 o ipNetToPhysicalTable table which is the content of the Neighbor
1076 cache, i.e., the mapping between IPv6 and data-link layer
1077 addresses.
1079 There are also YANG modules about the two IP addresses families and
1080 can be used with [RFC6241] and [RFC8040]. This memo recommends the
1081 use of:
1083 o interfaces-state/interface/statistics from ietf-
1084 interfaces@2018-02-20.yang [RFC8343] which contains counters for
1085 interface .
1087 o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the
1088 content of the Neighbor cache, i.e., the mapping between IPv6 and
1089 data-link layer addresses.
1091 2.6.1.4. Neighbor Cache of IPv6 Routers
1093 The neighbor cache of routers contains all mappings between IPv6
1094 addresses and data-link layer addresses. There are multiple ways to
1095 collect the current entries in the Neighbor Cache, notably but not
1096 limited to:
1098 o the SNMP MIB (Section 2.6.1.3) as explained above;
1100 o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to
1101 collect the operational state of the neighbor cache;
1103 o also by connecting over a secure management channel (such as SSH)
1104 and explicitly requesting a neighbor cache dump via the Command
1105 Line Interface or another monitoring mechanism.
1107 The neighbor cache is highly dynamic as mappings are added when a new
1108 IPv6 address appears on the network. This could be quite frequently
1109 with privacy extension addresses [RFC4941] or when they are removed
1110 when the state goes from UNREACH to removed (the default time for a
1111 removal per Neighbor Unreachability Detection [RFC4861] algorithm is
1112 38 seconds for a host using Windows 7). This means that the content
1113 of the neighbor cache must periodically be fetched at an interval
1114 which does not exhaust the router resources and still provides
1115 valuable information (suggested value is 30 seconds but to be checked
1116 in the actual setup) and stored for later use.
1118 This is an important source of information because it is trivial (on
1119 a switch not using the SAVI [RFC7039] algorithm) to defeat the
1120 mapping between data-link layer address and IPv6 address. Let us
1121 rephrase the previous statement: having access to the current and
1122 past content of the neighbor cache has a paramount value for forensic
1123 and audit trail.
1125 When using one /64 per host (Section 2.1.7) or DHCP-PD, it is
1126 sufficient to keep the history of the allocated prefixes when
1127 combined with strict source address prefix enforcement on the routers
1128 and layer-2 switches to prevent IPv6 spoofing.
1130 2.6.1.5. Stateful DHCPv6 Lease
1132 In some networks, IPv6 addresses/prefixes are managed by a stateful
1133 DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to
1134 clients. It is indeed quite similar to DHCP for IPv4 so it can be
1135 tempting to use this DHCP lease file to discover the mapping between
1136 IPv6 addresses/prefixes and data-link layer addresses as is commonly
1137 used in IPv4 networking .
1139 It is not so easy in the IPv6 networks because not all nodes will use
1140 DHCPv6 (there are nodes which can only do stateless
1141 autoconfiguration) but also because DHCPv6 clients are identified not
1142 by their hardware-client address as in IPv4 but by a DHCP Unique ID
1143 (DUID) which can have several formats: some being the data-link layer
1144 address, some being data-link layer address prepended with time
1145 information, or even an opaque number which is useless for
1146 operational security. Moreover, when the DUID is based on the data-
1147 link address, this address can be of any client interface (such as
1148 the wireless interface while the client actually uses its wired
1149 interface to connect to the network).
1151 If a lightweight DHCP relay agent [RFC6221] is used in a layer-2
1152 switche, then the DHCP servers also receives the Interface-ID
1153 information which could be saved in order to identify the interface
1154 on which the switch received a specific leased IPv6 address. Also,
1155 if a 'normal' (not lightweight) relay agent adds the data-link layer
1156 address in the option for Relay Agent Remote-ID [RFC4649] or
1157 [RFC6939], then the DHCPv6 server can keep track of the data-link and
1158 leased IPv6 addresses.
1160 In short, the DHCPv6 lease file is less interesting than for IPv4
1161 networks. If possible, it is recommended to use DHCPv6 servers that
1162 keep the relayed data-link layer address in addition to the DUID in
1163 the lease file as those servers have the equivalent information to
1164 IPv4 DHCP servers.
1166 The mapping between data-link layer address and the IPv6 address can
1167 be secured by deploying switches implementing the SAVI [RFC7513]
1168 mechanisms. Of course, this also requires that the data-link layer
1169 address is protected by using a layer-2 mechanism such as
1170 [IEEE-802.1X].
1172 2.6.1.6. RADIUS Accounting Log
1174 For interfaces where the user is authenticated via a RADIUS [RFC2866]
1175 server, and if RADIUS accounting is enabled, then the RADIUS server
1176 receives accounting Acct-Status-Type records at the start and at the
1177 end of the connection which include all IPv6 (and IPv4) addresses
1178 used by the user. This technique can be used notably for Wi-Fi
1179 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X
1180 [IEEE-802.1X] wired interface on an Ethernet switch.
1182 2.6.1.7. Other Data Sources
1184 There are other data sources for log information that must be
1185 collected (as currently collected as in the IPv4 networks):
1187 o historical mapping of IPv6 addresses to users of remote access
1188 VPN;
1190 o historical mappings of MAC addresses to switch interface in a
1191 wired network.
1193 2.6.2. Use of Collected Data
1195 This section leverages the data collected as described before
1196 (Section 2.6.1) in order to achieve several security benefits.
1197 Section 9.1 of [RFC7934] contains more details about host tracking.
1199 2.6.2.1. Forensic and User Accountability
1201 The forensic use case is when the network operator must locate an
1202 IPv6 address that was present in the network at a certain time or is
1203 still currently in the network.
1205 To locate an IPv6 address in an enterprise network where the operator
1206 has control over all resources, the source of information can be the
1207 neighbor cache, or, if not found, the DHCP lease file. Then, the
1208 procedure is:
1210 1. Based on the IPv6 prefix of the IPv6 address, find the router(s)
1211 which is(are) used to reach this prefix (assuming that anti-
1212 spoofing mechanisms are used).
1214 2. Based on this limited set of routers, on the incident time and on
1215 the IPv6 address, retrieve the data-link address from the live
1216 neighbor cache, from the historical neighbor cache data, or from
1217 SAVI events, or retrieve the data-link address from the DHCP
1218 lease file (Section 2.6.1.5).
1220 3. Based on the data-link layer address, look-up the switch
1221 interface associated with the data-link layer address. In the
1222 case of wireless LAN with RADIUS accounting (see
1223 Section 2.6.1.6), the RADIUS log has the mapping between the user
1224 identification and the MAC address. If a Configuration
1225 Management Data Base (CMDB) is used, then it can be used to map
1226 the data-link layer address to a switch port.
1228 At the end of the process, the interface of the host originating
1229 malicious activity or the username perpetrating the malicious
1230 activity has been determined.
1232 To identify the subscriber of an IPv6 address in a residential
1233 Internet Service Provider, the starting point is the DHCP-PD leased
1234 prefix covering the IPv6 address; this prefix can often be linked to
1235 a subscriber via the RADIUS log. Alternatively, the Forwarding
1236 Information Base of the CMTS or BNG indicates the CPE of the
1237 subscriber and the RADIUS log can be used to retrieve the actual
1238 subscriber.
1240 More generally, a mix of the above techniques can be used in most, if
1241 not all, networks.
1243 2.6.2.2. Inventory
1245 RFC 7707 [RFC7707] describes the difficulties for an attacker to scan
1246 an IPv6 network due to the vast number of IPv6 addresses per link
1247 (and why in some cases it can still be done). While the huge
1248 addressing space can sometimes be perceived as a 'protection', it
1249 also makes the inventory task difficult in an IPv6 network while it
1250 was trivial to do in an IPv4 network (a simple enumeration of all
1251 IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting
1252 an inventory of all connected devices is of prime importance for a
1253 secure network operation.
1255 There are many ways to do an inventory of an IPv6 network.
1257 The first technique is to use the IPFIX information and extract the
1258 list of all IPv6 source addresses to find all IPv6 nodes that sent
1259 packets through a router. This is very efficient but, alas, will not
1260 discover silent nodes that never transmitted packets traversing the
1261 the IPFIX target router. Also, it must be noted that link-local
1262 addresses will never be discovered by this means.
1264 The second way is again to use the collected neighbor cache content
1265 to find all IPv6 addresses in the cache. This process will also
1266 discover all link-local addresses. See Section 2.6.1.4.
1268 Another way that works only for local network, consists in sending a
1269 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which
1270 addresses all IPv6 nodes on the network. All nodes should reply to
1271 this ECHO_REQUEST per [RFC4443].
1273 Other techniques involve obtaining data from DNS, parsing log files,
1274 leveraging service discovery such as mDNS [RFC6762] and [RFC6763].
1276 Enumerating DNS zones, especially looking at reverse DNS records and
1277 CNAMES, is another common method employed by various tools. As
1278 already mentioned in [RFC7707], this allows an attacker to prune the
1279 IPv6 reverse DNS tree, and hence enumerate it in a feasible time.
1280 Furthermore, authoritative servers that allow zone transfers (AXFR)
1281 may be a further information source.
1283 2.6.2.3. Correlation
1285 In an IPv4 network, it is easy to correlate multiple logs, for
1286 example to find events related to a specific IPv4 address. A simple
1287 Unix grep command is enough to scan through multiple text-based files
1288 and extract all lines relevant to a specific IPv4 address.
1290 In an IPv6 network, this is slightly more difficult because different
1291 character strings can express the same IPv6 address. Therefore, the
1292 simple Unix grep command cannot be used. Moreover, an IPv6 node can
1293 have multiple IPv6 addresses.
1295 In order to do correlation in IPv6-related logs, it is advised to
1296 have all logs in a format with only canonical IPv6 addresses
1297 [RFC5952]. Then, the neighbor cache current (or historical) data set
1298 must be searched to find the data-link layer address of the IPv6
1299 address. Then, the current and historical neighbor cache data sets
1300 must be searched for all IPv6 addresses associated to this data-link
1301 layer address to derive the search set. The last step is to search
1302 in all log files (containing only IPv6 address in canonical format)
1303 for any IPv6 addresses in the search set.
1305 Moreover, [RFC7934] recommends using multiple IPv6 addresses per
1306 prefix, so, the correlation must also be done among those multiple
1307 IPv6 addresses, for example by discovering in the NDP cache
1308 (Section 2.6.1.4) all IPv6 addresses associated with the same MAC
1309 address and interface.
1311 2.6.2.4. Abnormal Behavior Detection
1313 Abnormal behavior (such as network scanning, spamming, denial of
1314 service) can be detected in the same way as in an IPv4 network.
1316 o Sudden increase of traffic detected by interface counter (SNMP) or
1317 by aggregated traffic from IPFIX records [RFC7012].
1319 o Change in traffic pattern (number of connections per second,
1320 number of connection per host...) with the use of IPFIX [RFC7012].
1322 2.6.3. Summary
1324 While some data sources (IPFIX, MIB, switch CAM tables, logs, ...)
1325 used in IPv4 are also used in the secure operation of an IPv6
1326 network, the DHCPv6 lease file is less reliable and the neighbor
1327 cache is of prime importance.
1329 The fact that there are multiple ways to express the same IPv6
1330 address in a character string renders the use of filters mandatory
1331 when correlation must be done.
1333 2.7. Transition/Coexistence Technologies
1335 As it is expected that some networks will not run in a pure IPv6-only
1336 mode, the different transition mechanisms must be deployed and
1337 operated in a secure way. This section proposes operational
1338 guidelines for the most known and deployed transition techniques.
1340 2.7.1. Dual Stack
1342 Dual stack is often the first deployment choice for network
1343 operators. Dual stacking the network offers some advantages over
1344 other transition mechanisms. Firstly, the impact on existing IPv4
1345 operations is reduced. Secondly, in the absence of tunnels or
1346 address translation, the IPv4 and IPv6 traffics are native (easier to
1347 observe and secure) and should have the same network processing
1348 (network path, quality of service, ...). Dual stack enables a
1349 gradual termination of the IPv4 operations when the IPv6 network is
1350 ready for prime time. On the other hand, the operators have to
1351 manage two network stacks with the added complexities.
1353 From an operational security perspective, this now means that the
1354 network operator has twice the exposure. One needs to think about
1355 protecting both protocols now. At a minimum, the IPv6 portion of a
1356 dual-stacked network should be consistent with IPv4 from a security
1357 policy point of view. Typically, the following methods are employed
1358 to protect IPv4 networks at the edge or security perimeter:
1360 o ACLs to permit or deny traffic;
1362 o Firewalls with stateful packet inspection.
1364 It is recommended that these ACLs and/or firewalls be additionally
1365 configured to protect IPv6 communications. The enforced IPv6
1366 security must be congruent with the IPv4 security policy, otherwise
1367 the attacker will use the protocol version having the more relaxed
1368 security policy. Maintaining the congruence between security
1369 policies can be challenging (especially over time); it is recommended
1370 to use a firewall or an ACL manager that is dual-stack, i.e., a
1371 system that can apply a single ACL entry to a mixed group of IPv4 and
1372 IPv6 addresses.
1374 Also, given the end-to-end connectivity that IPv6 provides, it is
1375 recommended that hosts be fortified against threats. General device
1376 hardening guidelines are provided in Section 2.8.
1378 For many years, all host operating systems have IPv6 enabled by
1379 default, so, it is possible even in an 'IPv4-only' network to attack
1380 layer-2 adjacent victims via their IPv6 link-local address or via a
1381 global IPv6 address when the attacker provides rogue RAs or a rogue
1382 DHCPv6 service.
1384 [RFC7123] discusses the security implications of native IPv6 support
1385 and IPv6 transition/coexistence technologies on "IPv4-only" networks
1386 and describes possible mitigations for the aforementioned issues.
1388 2.7.2. Encapsulation Mechanisms
1390 There are many tunnels used for specific use cases. Except when
1391 protected by IPsec [RFC4301], all those tunnels have a couple of
1392 security issues as described in RFC 6169 [RFC6169];
1394 o tunnel injection: a malevolent person knowing a few pieces of
1395 information (for example the tunnel endpoints and the
1396 encapsulation protocol) can forge a packet which looks like a
1397 legit and valid encapsulated packet that will gladly be accepted
1398 by the destination tunnel endpoint, this is a specific case of
1399 spoofing;
1401 o traffic interception: no confidentiality is provided by the tunnel
1402 protocols (without the use of IPsec or alternative encryption
1403 methods), therefore anybody on the tunnel path can intercept the
1404 traffic and have access to the clear-text IPv6 packet; combined
1405 with the absence of authentication, a on-path attack can also be
1406 mounted;
1408 o service theft: as there is no authorization, even a non-authorized
1409 user can use a tunnel relay for free (this is a specific case of
1410 tunnel injection);
1412 o reflection attack: another specific use case of tunnel injection
1413 where the attacker injects packets with an IPv4 destination
1414 address not matching the IPv6 address causing the first tunnel
1415 endpoint to re-encapsulate the packet to the destination... Hence,
1416 the final IPv4 destination will not see the original IPv4 address
1417 but only the IPv4 address of the relay router.
1419 o bypassing security policy: if a firewall or an IPS is on the path
1420 of the tunnel, then it may neither inspect nor detect a malevolent
1421 IPv6 traffic transmitted over the tunnel.
1423 To mitigate the bypassing of security policies, it is recommended to
1424 block all default configuration tunnels by denying IPv4 packets
1425 matching:
1427 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4
1428 (Section 2.7.2.7), 6rd (Section 2.7.2.3) as well as 6in4
1429 (Section 2.7.2.1) tunnels;
1431 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels;
1433 o UDP protocol 3544: this will block the default encapsulation of
1434 Teredo (Section 2.7.2.8) tunnels.
1436 Ingress filtering [RFC2827] should also be applied on all tunnel
1437 endpoints if applicable to prevent IPv6 address spoofing.
1439 As several of the tunnel techniques share the same encapsulation
1440 (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6
1441 address, there are a set of well-known looping attacks described in
1442 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques.
1444 2.7.2.1. Site-to-Site Static Tunnels
1446 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and
1447 in GRE [RFC2784]. As the IPv4 endpoints are statically configured
1448 and are not dynamic they are slightly more secure (bi-directional
1449 service theft is mostly impossible) but traffic interception and
1450 tunnel injection are still possible. Therefore, the use of IPsec
1451 [RFC4301] in transport mode and protecting the encapsulated IPv4
1452 packets is recommended for those tunnels. Alternatively, IPsec in
1453 tunnel mode can be used to transport IPv6 traffic over a non-trusted
1454 IPv4 network.
1456 2.7.2.2. ISATAP
1458 ISATAP tunnels [RFC5214] are mainly used within a single
1459 administrative domain and to connect a single IPv6 host to the IPv6
1460 network. This often implies that those systems are usually managed
1461 by a single entity; therefore, audit trail and strict anti-spoofing
1462 are usually possible and this raises the overall security.
1464 Special care must be taken to avoid a looping attack by implementing
1465 the measures of RFC 6324 [RFC6324] and of [RFC6964].
1467 IPsec [RFC4301] in transport or tunnel mode can be used to secure the
1468 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and
1469 prevent service theft.
1471 2.7.2.3. 6rd
1473 While 6rd tunnels share the same encapsulation as 6to4 tunnels
1474 (Section 2.7.2.7), they are designed to be used within a single SP
1475 domain, in other words they are deployed in a more constrained
1476 environment than 6to4 tunnels and have few security issues other than
1477 lack of confidentiality. The security considerations (Section 12) of
1478 [RFC5969] describes how to secure 6rd tunnels.
1480 IPsec [RFC4301] for the transported IPv6 traffic can be used if
1481 confidentiality is important.
1483 2.7.2.4. 6PE, 6VPE, and LDPv6
1485 Organizations using MPLS in their core can also use 6PE [RFC4798] and
1486 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are
1487 really similar to BGP/MPLS IP VPN described in [RFC4364], the
1488 security properties of these networks are also similar to those
1489 described in [RFC4381]. It relies on:
1491 o Address space, routing and traffic separation with the help of
1492 VRFs (only applicable to 6VPE);
1494 o Hiding the IPv4 core, hence removing all attacks against
1495 P-routers;
1497 o Securing the routing protocol between CE and PE; in the case of
1498 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and
1499 as these addresses cannot be reached from outside of the link, the
1500 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP
1501 VPN.
1503 LDPv6 itself does not induce new risks, see also [RFC7552].
1505 2.7.2.5. DS-Lite
1507 DS-lite is also a translation mechanism and is therefore analyzed
1508 further (Section 2.7.3.3) in this document as it includes IPv4 NAPT.
1510 2.7.2.6. Mapping of Address and Port
1512 With the encapsulation and translation versions of mapping of Address
1513 and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access
1514 network is purely an IPv6 network and MAP protocols are used to
1515 connect IPv4 hosts on the subscriber network access to IPv4 hosts on
1516 the Internet. The subscriber router does stateful operations in
1517 order to map all internal IPv4 addresses and layer-4 ports to the
1518 IPv4 address and the set of layer-4 ports received through MAP
1519 configuration process. The SP equipment always does stateless
1520 operations (either decapsulation or stateless translation).
1521 Therefore, as opposed to Section 2.7.3.3 there is no state-exhaustion
1522 DoS attack against the SP equipment because there is no state and
1523 there is no operation caused by a new layer-4 connection (no logging
1524 operation).
1526 The SP MAP equipment should implement all the security considerations
1527 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address
1528 and port are consistent with the configuration. As MAP has a
1529 predictable IPv4 address and port mapping, the audit logs are easier
1530 to manage.
1532 2.7.2.7. 6to4
1534 6to4 tunnels [RFC3056] require a public routable IPv4 address in
1535 order to work correctly. They can be used to provide either single
1536 IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks
1537 connectivity to the IPv6 Internet. The 6to4 relay was historically
1538 the anycast address defined in [RFC3068] which has been deprecated by
1539 [RFC7526] and is no longer used by recent Operating Systems. Some
1540 security considerations are explained in [RFC3964].
1542 [RFC6343] points out that if an operator provides well-managed
1543 servers and relays for 6to4, non-encapsulated IPv6 packets will pass
1544 through well-defined points (the native IPv6 interfaces of those
1545 servers and relays) at which security mechanisms may be applied.
1546 Client usage of 6to4 by default is now discouraged, and significant
1547 precautions are needed to avoid operational problems.
1549 2.7.2.8. Teredo
1551 Teredo tunnels [RFC4380] are mainly used in a residential environment
1552 because Teredo easily traverses an IPv4 NAPT device thanks to its UDP
1553 encapsulation. Teredo tunnels connect a single host to the IPv6
1554 Internet. Teredo shares the same issues as other tunnels: no
1555 authentication, no confidentiality, possible spoofing and reflection
1556 attacks.
1558 IPsec [RFC4301] for the transported IPv6 traffic is recommended.
1560 The biggest threat to Teredo is probably for an IPv4-only network as
1561 Teredo has been designed to easily traverse IPV4 NAT-PT devices which
1562 are quite often co-located with a stateful firewall. Therefore, if
1563 the stateful IPv4 firewall allows unrestricted UDP outbound and
1564 accepts the return UDP traffic, then Teredo actually punches a hole
1565 in this firewall for all IPv6 traffic to the Internet and from the
1566 Internet. While host policies can be deployed to block Teredo in an
1567 IPv4-only network in order to avoid this firewall bypass, it would be
1568 enough to block all UDP outbound traffic at the IPv4 firewall if
1569 deemed possible (of course, at least port 53 should be left open for
1570 DNS traffic, port 443 for QUIC, port 500 for IKE, port 3478 for STUN,
1571 i.e., filter judiciously).
1573 Teredo is now hardly never used and no longer enabled by default in
1574 most environments, so, it is less of a threat, however, special
1575 consideration must be taken in case of devices with older or non-
1576 updated operating systems may be present and by default were running
1577 Teredo.
1579 2.7.3. Translation Mechanisms
1581 Translation mechanisms between IPv4 and IPv6 networks are alternate
1582 coexistence strategies while networks transition to IPv6. While a
1583 framework is described in [RFC6144], the specific security
1584 considerations are documented in each individual mechanism. For the
1585 most part, they specifically mention interference with IPsec or
1586 DNSSEC deployments, how to mitigate spoofed traffic, and what some
1587 effective filtering strategies may be.
1589 While not really a transition mechanism to IPv6, this section also
1590 includes the discussion about the use of heavy IPv4-to-IPv4 network
1591 address and port translation to prolong the life of IPv4-only
1592 networks.
1594 2.7.3.1. Carrier-Grade NAT (CGN)
1596 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT
1597 (LSN) or SP NAT is described in [RFC6264] and is utilized as an
1598 interim measure to extend the use of IPv4 in a large service provider
1599 network until the provider can deploy an effective IPv6 solution.
1600 [RFC6598] requested a specific IANA allocated /10 IPv4 address block
1601 to be used as address space shared by all access networks using CGN.
1602 This has been allocated as 100.64.0.0/10.
1604 Section 13 of [RFC6269] lists some specific security-related issues
1605 caused by large scale address sharing. The Security Considerations
1606 section of [RFC6598] also lists some specific mitigation techniques
1607 for potential misuse of shared address space. Some Law Enforcement
1608 Agencies have identified CGN as impeding their cyber-crime
1609 investigations (for example Europol press release on CGN
1610 [europol-cgn]). Many translation techniques (NAT64, DS-lite, ...)
1611 have the same security issues as CGN when one part of the connection
1612 is IPv4-only.
1614 [RFC6302] has recommendations for Internet-facing servers to also log
1615 the source TCP or UDP ports of incoming connections in an attempt to
1616 help identify the users behind such a CGN.
1618 [RFC7422] suggests the use of deterministic address mapping in order
1619 to reduce logging requirements for CGN. The idea is to have a known
1620 algorithm for mapping the internal subscriber to/from public TCP and
1621 UDP ports.
1623 [RFC6888] lists common requirements for CGNs. [RFC6967] analyzes
1624 some solutions to enforce policies on misbehaving nodes when address
1625 sharing is used. [RFC7857] also updates the NAT behavioral
1626 requirements.
1628 2.7.3.2. NAT64/DNS64 and 464XLAT
1630 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to
1631 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used
1632 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes
1633 AAAA records from existing A records. There is also a stateless
1634 NAT64 [RFC7915] which is similar for the security aspects with the
1635 added benefit of being stateless, so, less prone to a state
1636 exhaustion attack.
1638 The Security Consideration sections of [RFC6146] and [RFC6147] list
1639 the comprehensive issues. A specific issue with the use of NAT64 is
1640 that it will interfere with most IPsec deployments unless UDP
1641 encapsulation is used. DNSSEC has an impact on DNS64 see section 3.1
1642 of [RFC7050].
1644 Another translation mechanism relying on a combination of stateful
1645 and stateless translation, 464XLAT [RFC6877], can be used to do host
1646 local translation from IPv4 to IPv6 and a network provider
1647 translation from IPv6 to IPv4, i.e., giving IPv4-only application
1648 access to an IPv4-only server over an IPv6-only network. 464XLAT
1649 shares the same security considerations as NAT64 and DNS64, however
1650 it can be used without DNS64, avoiding the DNSSEC implications.
1652 2.7.3.3. DS-Lite
1654 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that
1655 enables a service provider to share IPv4 addresses among customers by
1656 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and
1657 IPv4 NAPT.
1659 Security considerations with respect to DS-Lite mainly revolve around
1660 logging data, preventing DoS attacks from rogue devices (as the
1661 Address Family Translation Router (AFTR) [RFC6333] function is
1662 stateful and restricting service offered by the AFTR only to
1663 registered customers.
1665 Section 11 of [RFC6333] and section 2 of [RFC7785] describe important
1666 security issues associated with this technology.
1668 2.8. General Device Hardening
1670 With almost all devices being IPv6 enabled by default and with many
1671 end points having IPv6 connectivity to the Internet, it is critical
1672 to also harden those devices against attacks over IPv6.
1674 The following guidelines should be used to ensure appropriate
1675 hardening of the host, be it an individual computer or router,
1676 firewall, load-balancer, server, etc. device.
1678 o Restrict device access to authorized individuals
1680 o Monitor and audit access to the device
1682 o Turn off any unused services on the end node
1684 o Understand which IPv6 addresses are being used to source traffic
1685 and change defaults if necessary
1687 o Use cryptographically protected protocols for device management if
1688 possible (SCP, SNMPv3, SSH, TLS, etc.)
1690 o Use host firewall capabilities to control traffic that gets
1691 processed by upper layer protocols
1693 o Use virus scanners to detect malicious programs
1695 3. Enterprises Specific Security Considerations
1697 Enterprises [RFC7381] generally have robust network security policies
1698 in place to protect existing IPv4 networks. These policies have been
1699 distilled from years of experiential knowledge of securing IPv4
1700 networks. At the very least, it is recommended that enterprise
1701 networks have parity between their security policies for both
1702 protocol versions. This section also applies to the enterprise part
1703 of all SP networs, i.e., the part of the network where the SP
1704 employees are connected.
1706 Security considerations in the enterprise can be broadly categorized
1707 into two sections - External and Internal.
1709 3.1. External Security Considerations
1711 The external aspect deals with providing security at the edge or
1712 perimeter of the enterprise network where it meets the service
1713 providers network. This is commonly achieved by enforcing a security
1714 policy either by implementing dedicated firewalls with stateful
1715 packet inspection or a router with ACLs. A common default IPv4
1716 policy on firewalls that could easily be ported to IPv6 is to allow
1717 all traffic outbound while only allowing specific traffic, such as
1718 established sessions, inbound (see also [RFC6092]). Section 3.2 of
1719 [RFC7381] also provides similar recommendations.
1721 Here are a few more things that could enhance the default policy:
1723 o Filter internal-use IPv6 addresses at the perimeter this will also
1724 mitigate the vulnerabilities listed in [RFC7359]
1726 o Discard packets from and to bogon and reserved space, see also
1727 [CYMRU] and [RFC8190]
1729 o Accept certain ICMPv6 messages to allow proper operation of ND and
1730 PMTUD, see also [RFC4890] or [REY_PF] for hosts
1732 o Filter specific extension headers by accepting only the required
1733 ones (permit list approach) such as ESP, AH (not forgetting the
1734 required transport layers: ICMP, TCP, UDP, ...), where possible at
1735 the edge and possibly inside the perimeter; see also
1736 [I-D.ietf-opsec-ipv6-eh-filtering]
1738 o Filter packets having an illegal IPv6 headers chain at the
1739 perimeter (and if possible, inside the network as well), see
1740 Section 2.2
1742 o Filter unneeded services at the perimeter
1744 o Implement ingress and egress anti-spoofing in the forwarding and
1745 control planes, see [RFC2827] and [RFC3704]
1747 o Implement appropriate rate limiters and control-plane policers
1749 Having global IPv6 address on all the enterprises sites is different
1750 than in IPv4 where [RFC1918] addresses are used internally and not
1751 routed usually over the Internet. [RFC7359] and [WEBER_VPN] explain
1752 that without careful design, there could be IPv6 leakages out of
1753 layer-3 VPN.
1755 3.2. Internal Security Considerations
1757 The internal aspect deals with providing security inside the
1758 perimeter of the network, including end hosts. Internal networks of
1759 enterprises are often different: University campus, wireless guest
1760 access, ... so there is no "one size fits all" recommendations.
1762 The most significant concerns here are related to Neighbor Discovery.
1763 At the network level, it is recommended that all security
1764 considerations discussed in Section 2.3 be reviewed carefully and the
1765 recommendations be considered in-depth as well. Section 4.1 of
1766 [RFC7381] also provides some recommendations.
1768 As mentioned in Section 2.7.2, care must be taken when running
1769 automated IPv6-in-IPv4 tunnels.
1771 When site-to-site VPNs are used it should be kept in mind that, given
1772 the global scope of IPv6 global addresses as opposed to the common
1773 use of IPv4 private address space [RFC1918], sites might be able to
1774 communicate with each other over the Internet even when the VPN
1775 mechanism is not available and hence no traffic encryption is
1776 performed and traffic could be injected from the Internet into the
1777 site, see [WEBER_VPN]. It is recommended to filter at the Internet
1778 connection(s) packets having a source or destination address
1779 belonging to the site internal prefix(es); this should be done for
1780 ingress and egress traffic.
1782 Hosts need to be hardened directly through security policy to protect
1783 against security threats. The host firewall default capabilities
1784 have to be clearly understood. In some cases, 3rd party firewalls
1785 have no IPv6 support whereas the native firewall installed by default
1786 has IPv6 support. General device hardening guidelines are provided
1787 in Section 2.8.
1789 It should also be noted that many hosts still use IPv4 for
1790 transporting logs for RADIUS, DIAMETER, TACACS+, SYSLOG, etc.
1791 Operators cannot rely on an IPv6-only security policy to secure such
1792 protocols that are still using IPv4.
1794 4. Service Providers Security Considerations
1796 4.1. BGP
1798 The threats and mitigation techniques are identical between IPv4 and
1799 IPv6. Broadly speaking they are:
1801 o Authenticating the TCP session;
1802 o TTL security (which becomes hop-limit security in IPv6) as
1803 [RFC5082];
1805 o bogon AS filtering, see [CYMRU];
1807 o Prefix filtering.
1809 These are explained in more detail in Section 2.5. Also, the
1810 recommendations of [RFC7454] should be considered.
1812 4.1.1. Remote Triggered Black Hole Filtering
1814 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has
1815 allocated the 100::/64 prefix to be used as the discard prefix
1816 [RFC6666].
1818 4.2. Transition/Coexistence Mechanism
1820 SP will typically use transition mechanisms such as 6rd, 6PE, MAP,
1821 NAT64 which have been analyzed in the transition and coexistence
1822 Section 2.7 section.
1824 4.3. Lawful Intercept
1826 The Lawful Intercept requirements are similar for IPv6 and IPv4
1827 architectures and will be subject to the laws enforced in varying
1828 geographic regions. The local issues with each jurisdiction can make
1829 this challenging and both corporate legal and privacy personnel
1830 should be involved in discussions pertaining to what information gets
1831 logged and what the logging retention policies will be.
1833 The target of interception will usually be a residential subscriber
1834 (e.g., his/her PPP session or physical line or CPE MAC address).
1835 With the absence of IPv6 NAT on the CPE, IPv6 has the possibility to
1836 allow for intercepting the traffic from a single host (a /128 target)
1837 rather than the whole set of hosts of a subscriber (which could be a
1838 /48, a /60 or /64).
1840 In contrast, in mobile environments, since the 3GPP specifications
1841 allocate a /64 per device, it may be sufficient to intercept traffic
1842 from the /64 rather than specific /128's (since each time the device
1843 establishes a data connection it gets a new IID).
1845 A sample architecture which was written for informational purposes is
1846 found in [RFC3924].
1848 5. Residential Users Security Considerations
1850 The IETF Homenet working group is working standards and guidelines
1851 for IPv6 residential networks; this obviously includes operational
1852 security considerations; but this is still work in progress in early
1853 2020. [RFC8520] is an interesting approach on how firewalls could
1854 retrieve and apply specific security policies to some residential
1855 devices.
1857 Some residential users have less experience and knowledge about
1858 security or networking. As most of the recent hosts (e.g.,
1859 smartphones, tablets) all have IPv6 enabled by default, IPv6 security
1860 is important for those users. Even with an IPv4-only ISP, those
1861 users can get IPv6 Internet access with the help of Teredo
1862 (Section 2.7.2.8) tunnels. Several peer-to-peer programs support
1863 IPv6 and those programs can initiate a Teredo tunnel through an IPv4
1864 residential gateway, with the consequence of making the internal host
1865 reachable from any IPv6 host on the Internet. It is therefore
1866 recommended that all host security products (including personal
1867 firewalls) are configured with a dual-stack security policy.
1869 If the residential CPE has IPv6 connectivity, [RFC7084] defines the
1870 requirements of an IPv6 CPE and does not take position on the debate
1871 of default IPv6 security policy as defined in [RFC6092]:
1873 o outbound only: allowing all internally initiated connections and
1874 block all externally initiated ones, which is a common default
1875 security policy enforced by IPv4 Residential Gateway doing NAPT
1876 but it also breaks the end-to-end reachability promise of IPv6.
1877 [RFC6092] lists several recommendations to design such a CPE;
1879 o open/transparent: allowing all internally and externally initiated
1880 connections, therefore restoring the end-to-end nature of the
1881 Internet for the IPv6 traffic but having a different security
1882 policy for IPv6 than for IPv4.
1884 [RFC6092] REC-49 states that a choice must be given to the user to
1885 select one of those two policies.
1887 6. Further Reading
1889 There are several documents that describe in more details the
1890 security of an IPv6 network; these documents are not written by the
1891 IETF and some of them are dated but are listed here for the reader's
1892 convenience:
1894 1. Guidelines for the Secure Deployment of IPv6 [NIST]
1895 2. North American IPv6 Task Force Technology Report - IPv6 Security
1896 Technology Paper [NAv6TF_Security]
1898 3. IPv6 Security [IPv6_Security_Book]
1900 7. Acknowledgements
1902 The authors would like to thank the following people for their useful
1903 comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali,
1904 Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti,
1905 Markus de Bruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee
1906 Howard, Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari,
1907 Ted Lemon, Mark Lentczner, Jen Linkova (and her detailed review),
1908 Gyan S. Mishra, Jordi Palet, Bob Sleigh, Donald Smith, Tarko Tikan,
1909 Ole Troan, Bernie Volz (by alphabetical order).
1911 8. Security Considerations
1913 This memo attempts to give an overview of security considerations of
1914 operating an IPv6 network both for an IPv6-only network and for
1915 networks utilizing the most widely deployed IPv4/IPv6 coexistence
1916 strategies.
1918 9. References
1920 9.1. Normative References
1922 [IANA-IPFIX]
1923 IANA, "IP Flow Information Export (IPFIX) Entities",
1924 .
1926 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1927 (IPv6) Specification", STD 86, RFC 8200,
1928 DOI 10.17487/RFC8200, July 2017,
1929 .
1931 9.2. Informative References
1933 [CYMRU] Team, C., "The Bogon Reference", Existing in 2021,
1934 .
1937 [europol-cgn]
1938 Europol, "ARE YOU SHARING THE SAME IP ADDRESS AS A
1939 CRIMINAL? LAW ENFORCEMENT CALL FOR THE END OF CARRIER
1940 GRADE NAT (CGN) TO INCREASE ACCOUNTABILITY ONLINE",
1941 October 2017,
1942 .
1947 [GDPR] Union, O. J. O. T. E., "Regulation (EU) 2016/679 of the
1948 European Parliament and of the Council of 27 April 2016 on
1949 the protection of natural persons with regard to the
1950 processing of personal data and on the free movement of
1951 such data, and repealing Directive 95/46/EC (General Data
1952 Protection Regulation)", April 2016,
1953 .
1955 [I-D.ietf-opsec-ipv6-eh-filtering]
1956 Gont, F. and W. LIU, "Recommendations on the Filtering of
1957 IPv6 Packets Containing IPv6 Extension Headers at Transit
1958 Routers", draft-ietf-opsec-ipv6-eh-filtering-07 (work in
1959 progress), January 2021.
1961 [I-D.kampanakis-6man-ipv6-eh-parsing]
1962 Kampanakis, P., "Implementation Guidelines for parsing
1963 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh-
1964 parsing-01 (work in progress), August 2014.
1966 [IEEE-802.1X]
1967 IEEE, "IEEE Standard for Local and metropolitan area
1968 networks - Port-Based Network Access Control", IEEE Std
1969 802.1X-2010, February 2010.
1971 [IPv6_Security_Book]
1972 Hogg, S. and E. Vyncke, "IPv6 Security",
1973 ISBN 1-58705-594-5, Publisher CiscoPress, December 2008.
1975 [NAv6TF_Security]
1976 Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North
1977 American IPv6 Task Force Technology Report - IPv6 Security
1978 Technology Paper", 2006,
1979 .
1982 [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks,
1983 "Guidelines for the Secure Deployment of IPv6", 2010,
1984 .
1987 [RADB] INC., M. N., "RADb The Internet Routing Registry",
1988 Existing in 2021, .
1990 [REY_PF] Rey, E., "Local Packet Filtering with IPv6", July 2017,
1991 .
1994 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
1995 Converting Network Protocol Addresses to 48.bit Ethernet
1996 Address for Transmission on Ethernet Hardware", STD 37,
1997 RFC 826, DOI 10.17487/RFC0826, November 1982,
1998 .
2000 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
2001 and E. Lear, "Address Allocation for Private Internets",
2002 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
2003 .
2005 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
2006 RFC 2131, DOI 10.17487/RFC2131, March 1997,
2007 .
2009 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
2010 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
2011 December 1998, .
2013 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
2014 Domains without Explicit Tunnels", RFC 2529,
2015 DOI 10.17487/RFC2529, March 1999,
2016 .
2018 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
2019 Translator (NAT) Terminology and Considerations",
2020 RFC 2663, DOI 10.17487/RFC2663, August 1999,
2021 .
2023 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
2024 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
2025 DOI 10.17487/RFC2784, March 2000,
2026 .
2028 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
2029 Defeating Denial of Service Attacks which employ IP Source
2030 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
2031 May 2000, .
2033 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
2034 DOI 10.17487/RFC2866, June 2000,
2035 .
2037 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
2038 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2039 2001, .
2041 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
2042 RFC 3068, DOI 10.17487/RFC3068, June 2001,
2043 .
2045 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
2046 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627,
2047 September 2003, .
2049 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
2050 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2051 2004, .
2053 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
2054 Neighbor Discovery (ND) Trust Models and Threats",
2055 RFC 3756, DOI 10.17487/RFC3756, May 2004,
2056 .
2058 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture
2059 for Lawful Intercept in IP Networks", RFC 3924,
2060 DOI 10.17487/RFC3924, October 2004,
2061 .
2063 [RFC3964] Savola, P. and C. Patel, "Security Considerations for
2064 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004,
2065 .
2067 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
2068 "SEcure Neighbor Discovery (SEND)", RFC 3971,
2069 DOI 10.17487/RFC3971, March 2005,
2070 .
2072 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
2073 RFC 3972, DOI 10.17487/RFC3972, March 2005,
2074 .
2076 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
2077 Rose, "DNS Security Introduction and Requirements",
2078 RFC 4033, DOI 10.17487/RFC4033, March 2005,
2079 .
2081 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
2082 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
2083 .
2085 [RFC4293] Routhier, S., Ed., "Management Information Base for the
2086 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293,
2087 April 2006, .
2089 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
2090 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
2091 December 2005, .
2093 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
2094 DOI 10.17487/RFC4302, December 2005,
2095 .
2097 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
2098 RFC 4303, DOI 10.17487/RFC4303, December 2005,
2099 .
2101 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
2102 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2103 2006, .
2105 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
2106 Network Address Translations (NATs)", RFC 4380,
2107 DOI 10.17487/RFC4380, February 2006,
2108 .
2110 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
2111 Virtual Private Networks (VPNs)", RFC 4381,
2112 DOI 10.17487/RFC4381, February 2006,
2113 .
2115 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
2116 Control Message Protocol (ICMPv6) for the Internet
2117 Protocol Version 6 (IPv6) Specification", STD 89,
2118 RFC 4443, DOI 10.17487/RFC4443, March 2006,
2119 .
2121 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
2122 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
2123 .
2125 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
2126 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
2127 DOI 10.17487/RFC4649, August 2006,
2128 .
2130 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
2131 "BGP-MPLS IP Virtual Private Network (VPN) Extension for
2132 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
2133 .
2135 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
2136 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
2137 Provider Edge Routers (6PE)", RFC 4798,
2138 DOI 10.17487/RFC4798, February 2007,
2139 .
2141 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
2142 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
2143 DOI 10.17487/RFC4861, September 2007,
2144 .
2146 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
2147 E. Klein, "Local Network Protection for IPv6", RFC 4864,
2148 DOI 10.17487/RFC4864, May 2007,
2149 .
2151 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
2152 ICMPv6 Messages in Firewalls", RFC 4890,
2153 DOI 10.17487/RFC4890, May 2007,
2154 .
2156 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
2157 Extensions for Stateless Address Autoconfiguration in
2158 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
2159 .
2161 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
2162 Co-existence Security Considerations", RFC 4942,
2163 DOI 10.17487/RFC4942, September 2007,
2164 .
2166 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
2167 Pignataro, "The Generalized TTL Security Mechanism
2168 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
2169 .
2171 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
2172 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
2173 DOI 10.17487/RFC5214, March 2008,
2174 .
2176 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
2177 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
2178 .
2180 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
2181 Filtering with Unicast Reverse Path Forwarding (uRPF)",
2182 RFC 5635, DOI 10.17487/RFC5635, August 2009,
2183 .
2185 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
2186 Address Text Representation", RFC 5952,
2187 DOI 10.17487/RFC5952, August 2010,
2188 .
2190 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
2191 Infrastructures (6rd) -- Protocol Specification",
2192 RFC 5969, DOI 10.17487/RFC5969, August 2010,
2193 .
2195 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
2196 Capabilities in Customer Premises Equipment (CPE) for
2197 Providing Residential IPv6 Internet Service", RFC 6092,
2198 DOI 10.17487/RFC6092, January 2011,
2199 .
2201 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
2202 Problem Statement", RFC 6104, DOI 10.17487/RFC6104,
2203 February 2011, .
2205 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
2206 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
2207 DOI 10.17487/RFC6105, February 2011,
2208 .
2210 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
2211 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
2212 April 2011, .
2214 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
2215 NAT64: Network Address and Protocol Translation from IPv6
2216 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
2217 April 2011, .
2219 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
2220 Beijnum, "DNS64: DNS Extensions for Network Address
2221 Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
2222 DOI 10.17487/RFC6147, April 2011,
2223 .
2225 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
2226 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
2227 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
2228 .
2230 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
2231 Concerns with IP Tunneling", RFC 6169,
2232 DOI 10.17487/RFC6169, April 2011,
2233 .
2235 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
2236 Assignment to End Sites", BCP 157, RFC 6177,
2237 DOI 10.17487/RFC6177, March 2011,
2238 .
2240 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
2241 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
2242 March 2011, .
2244 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
2245 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
2246 DOI 10.17487/RFC6221, May 2011,
2247 .
2249 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
2250 and A. Bierman, Ed., "Network Configuration Protocol
2251 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
2252 .
2254 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
2255 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
2256 DOI 10.17487/RFC6264, June 2011,
2257 .
2259 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
2260 P. Roberts, "Issues with IP Address Sharing", RFC 6269,
2261 DOI 10.17487/RFC6269, June 2011,
2262 .
2264 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
2265 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
2266 .
2268 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
2269 "Logging Recommendations for Internet-Facing Servers",
2270 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011,
2271 .
2273 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using
2274 IPv6 Automatic Tunnels: Problem Statement and Proposed
2275 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011,
2276 .
2278 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
2279 Stack Lite Broadband Deployments Following IPv4
2280 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
2281 .
2283 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
2284 RFC 6343, DOI 10.17487/RFC6343, August 2011,
2285 .
2287 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
2288 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
2289 Partnership Project (3GPP) Evolved Packet System (EPS)",
2290 RFC 6459, DOI 10.17487/RFC6459, January 2012,
2291 .
2293 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547,
2294 DOI 10.17487/RFC6547, February 2012,
2295 .
2297 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
2298 M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
2299 RFC 6564, DOI 10.17487/RFC6564, April 2012,
2300 .
2302 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
2303 Neighbor Discovery Problems", RFC 6583,
2304 DOI 10.17487/RFC6583, March 2012,
2305 .
2307 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
2308 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
2309 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2310 2012, .
2312 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
2313 SAVI: First-Come, First-Served Source Address Validation
2314 Improvement for Locally Assigned IPv6 Addresses",
2315 RFC 6620, DOI 10.17487/RFC6620, May 2012,
2316 .
2318 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6",
2319 RFC 6666, DOI 10.17487/RFC6666, August 2012,
2320 .
2322 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
2323 DOI 10.17487/RFC6762, February 2013,
2324 .
2326 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
2327 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
2328 .
2330 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
2331 Bormann, "Neighbor Discovery Optimization for IPv6 over
2332 Low-Power Wireless Personal Area Networks (6LoWPANs)",
2333 RFC 6775, DOI 10.17487/RFC6775, November 2012,
2334 .
2336 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
2337 Combination of Stateful and Stateless Translation",
2338 RFC 6877, DOI 10.17487/RFC6877, April 2013,
2339 .
2341 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
2342 A., and H. Ashida, "Common Requirements for Carrier-Grade
2343 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
2344 April 2013, .
2346 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
2347 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
2348 May 2013, .
2350 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in
2351 IPv4 Sites Using the Intra-Site Automatic Tunnel
2352 Addressing Protocol (ISATAP)", RFC 6964,
2353 DOI 10.17487/RFC6964, May 2013,
2354 .
2356 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
2357 "Analysis of Potential Solutions for Revealing a Host
2358 Identifier (HOST_ID) in Shared Address Deployments",
2359 RFC 6967, DOI 10.17487/RFC6967, June 2013,
2360 .
2362 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation
2363 with IPv6 Neighbor Discovery", RFC 6980,
2364 DOI 10.17487/RFC6980, August 2013,
2365 .
2367 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
2368 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
2369 DOI 10.17487/RFC7010, September 2013,
2370 .
2372 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
2373 "Specification of the IP Flow Information Export (IPFIX)
2374 Protocol for the Exchange of Flow Information", STD 77,
2375 RFC 7011, DOI 10.17487/RFC7011, September 2013,
2376 .
2378 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
2379 for IP Flow Information Export (IPFIX)", RFC 7012,
2380 DOI 10.17487/RFC7012, September 2013,
2381 .
2383 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
2384 "Source Address Validation Improvement (SAVI) Framework",
2385 RFC 7039, DOI 10.17487/RFC7039, October 2013,
2386 .
2388 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
2389 of IPv6 Extension Headers", RFC 7045,
2390 DOI 10.17487/RFC7045, December 2013,
2391 .
2393 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
2394 the IPv6 Prefix Used for IPv6 Address Synthesis",
2395 RFC 7050, DOI 10.17487/RFC7050, November 2013,
2396 .
2398 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
2399 Requirements for IPv6 Customer Edge Routers", RFC 7084,
2400 DOI 10.17487/RFC7084, November 2013,
2401 .
2403 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
2404 Oversized IPv6 Header Chains", RFC 7112,
2405 DOI 10.17487/RFC7112, January 2014,
2406 .
2408 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router
2409 Advertisement Guard (RA-Guard)", RFC 7113,
2410 DOI 10.17487/RFC7113, February 2014,
2411 .
2413 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on
2414 IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February
2415 2014, .
2417 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
2418 Authentication Trailer for OSPFv3", RFC 7166,
2419 DOI 10.17487/RFC7166, March 2014,
2420 .
2422 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
2423 Interface Identifiers with IPv6 Stateless Address
2424 Autoconfiguration (SLAAC)", RFC 7217,
2425 DOI 10.17487/RFC7217, April 2014,
2426 .
2428 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel
2429 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359,
2430 DOI 10.17487/RFC7359, August 2014,
2431 .
2433 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
2434 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
2435 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,
2436 .
2438 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
2439 Addressing inside an IPv6 Network", RFC 7404,
2440 DOI 10.17487/RFC7404, November 2014,
2441 .
2443 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
2444 and O. Vautrin, "Deterministic Address Mapping to Reduce
2445 Logging in Carrier-Grade NAT Deployments", RFC 7422,
2446 DOI 10.17487/RFC7422, December 2014,
2447 .
2449 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
2450 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
2451 February 2015, .
2453 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
2454 Validation Improvement (SAVI) Solution for DHCP",
2455 RFC 7513, DOI 10.17487/RFC7513, May 2015,
2456 .
2458 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast
2459 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526,
2460 DOI 10.17487/RFC7526, May 2015,
2461 .
2463 [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R.
2464 Papneja, "Updates to LDP for IPv6", RFC 7552,
2465 DOI 10.17487/RFC7552, June 2015,
2466 .
2468 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
2469 Murakami, T., and T. Taylor, Ed., "Mapping of Address and
2470 Port with Encapsulation (MAP-E)", RFC 7597,
2471 DOI 10.17487/RFC7597, July 2015,
2472 .
2474 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
2475 and T. Murakami, "Mapping of Address and Port using
2476 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2477 2015, .
2479 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
2480 Protecting against Rogue DHCPv6 Servers", BCP 199,
2481 RFC 7610, DOI 10.17487/RFC7610, August 2015,
2482 .
2484 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
2485 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
2486 .
2488 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
2489 Considerations for IPv6 Address Generation Mechanisms",
2490 RFC 7721, DOI 10.17487/RFC7721, March 2016,
2491 .
2493 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
2494 Consumption of Router Advertisements", BCP 202, RFC 7772,
2495 DOI 10.17487/RFC7772, February 2016,
2496 .
2498 [RFC7785] Vinapamula, S. and M. Boucadair, "Recommendations for
2499 Prefix Binding in the Context of Softwire Dual-Stack
2500 Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016,
2501 .
2503 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
2504 Considerations for DHCPv6", RFC 7824,
2505 DOI 10.17487/RFC7824, May 2016,
2506 .
2508 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
2509 Profiles for DHCP Clients", RFC 7844,
2510 DOI 10.17487/RFC7844, May 2016,
2511 .
2513 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
2514 S., and K. Naito, "Updates to Network Address Translation
2515 (NAT) Behavioral Requirements", BCP 127, RFC 7857,
2516 DOI 10.17487/RFC7857, April 2016,
2517 .
2519 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
2520 "Observations on the Dropping of Packets with IPv6
2521 Extension Headers in the Real World", RFC 7872,
2522 DOI 10.17487/RFC7872, June 2016,
2523 .
2525 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
2526 "IP/ICMP Translation Algorithm", RFC 7915,
2527 DOI 10.17487/RFC7915, June 2016,
2528 .
2530 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
2531 "Host Address Availability Recommendations", BCP 204,
2532 RFC 7934, DOI 10.17487/RFC7934, July 2016,
2533 .
2535 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
2536 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
2537 .
2539 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
2540 "Recommendation on Stable IPv6 Interface Identifiers",
2541 RFC 8064, DOI 10.17487/RFC8064, February 2017,
2542 .
2544 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
2545 "Updates to the Special-Purpose IP Address Registries",
2546 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
2547 .
2549 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key
2550 Infrastructure (RPKI) to Router Protocol, Version 1",
2551 RFC 8210, DOI 10.17487/RFC8210, September 2017,
2552 .
2554 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
2555 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
2556 .
2558 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
2559 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
2560 .
2562 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
2563 RFC 8344, DOI 10.17487/RFC8344, March 2018,
2564 .
2566 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
2567 Richardson, M., Jiang, S., Lemon, T., and T. Winters,
2568 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
2569 RFC 8415, DOI 10.17487/RFC8415, November 2018,
2570 .
2572 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
2573 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
2574 January 2019, .
2576 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
2577 Description Specification", RFC 8520,
2578 DOI 10.17487/RFC8520, March 2019,
2579 .
2581 [SCANNING]
2582 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great
2583 Void - Smarter scanning for IPv6", February 2012,
2584 .
2587 [WEBER_VPN]
2588 Weber, J., "Dynamic IPv6 Prefix - Problems and VPNs",
2589 March 2018, .
2593 Authors' Addresses
2595 Eric Vyncke
2596 Cisco
2597 De Kleetlaan 6a
2598 Diegem 1831
2599 Belgium
2601 Phone: +32 2 778 4677
2602 Email: evyncke@cisco.com
2604 Kiran Kumar
2605 WeWork
2606 415 Mission St.
2607 San Francisco 94105
2608 United States of America
2610 Email: kk.chittimaneni@gmail.com
2612 Merike Kaeo
2613 Double Shot Security
2614 3518 Fremont Ave N 363
2615 Seattle 98103
2616 United States of America
2618 Phone: +12066696394
2619 Email: merike@doubleshotsecurity.com
2621 Enno Rey
2622 ERNW
2623 Carl-Bosch-Str. 4
2624 Heidelberg, Baden-Wuertemberg 69115
2625 Germany
2627 Phone: +49 6221 480390
2628 Email: erey@ernw.de