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