idnits 2.17.00 (12 Aug 2021) /tmp/idnits1186/draft-ietf-opsec-ipv6-host-scanning-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2015) is 2451 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) == Outdated reference: draft-ietf-6man-default-iids has been published as RFC 8064 == Outdated reference: draft-ietf-6man-ipv6-address-generation-privacy has been published as RFC 7721 == Outdated reference: draft-ietf-opsec-v6 has been published as RFC 9099 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft Huawei Technologies 4 Obsoletes: 5157 (if approved) T. Chown 5 Intended status: Informational University of Southampton 6 Expires: February 29, 2016 August 28, 2015 8 Network Reconnaissance in IPv6 Networks 9 draft-ietf-opsec-ipv6-host-scanning-08 11 Abstract 13 IPv6 offers a much larger address space than that of its IPv4 14 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate 15 approximately 1.844 * 10^19 hosts, thus resulting in a much lower 16 host density (#hosts/#addresses) than is typical in IPv4 networks, 17 where a site typically has 65,000 or less unique addresses. As a 18 result, it is widely assumed that it would take a tremendous effort 19 to perform address scanning attacks against IPv6 networks, and 20 therefore brute-force IPv6 address scanning attacks have been 21 considered unfeasible. This document formally obsoletes RFC 5157, 22 which first discussed this assumption, by providing further analysis 23 on how traditional address scanning techniques apply to IPv6 24 networks, and exploring some additional techniques that can be 25 employed for IPv6 network reconnaissance. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 29, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements for the Applicability of Network Reconnaissance 63 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6 66 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 67 3.1.2. Dynamic Host Configuration Protocol version 6 68 (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 11 69 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 11 70 3.1.4. IPv6 Addresses Corresponding to Transition/Co- 71 existence Technologies . . . . . . . . . . . . . . . 14 72 3.1.5. IPv6 Address Assignment in Real-world Network 73 Scenarios . . . . . . . . . . . . . . . . . . . . . . 14 74 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17 75 3.2.1. Reducing the subnet ID search space . . . . . . . . . 17 76 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 18 77 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 19 78 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 19 79 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 20 80 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 20 81 4. Leveraging the Domain Name System (DNS) for Network 82 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 21 83 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 21 84 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 22 85 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 22 86 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 22 87 5. Leveraging Local Name Resolution and Service Discovery 88 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 23 90 7. Application Participation . . . . . . . . . . . . . . . . . . 23 91 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 23 92 9. Inspection of System Configuration and Log Files . . . . . . 24 93 10. Gleaning Information from Routing Protocols . . . . . . . . . 24 94 11. Gleaning Information from IP Flow Information Export (IPFIX) 24 95 12. Obtaining Network Information with traceroute6 . . . . . . . 24 96 13. Gleaning Information from Network Devices Using SNMP . . . . 25 97 14. Obtaining Network Information via Traffic Snooping . . . . . 25 98 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 100 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 102 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 19.1. Normative References . . . . . . . . . . . . . . . . . . 26 104 19.2. Informative References . . . . . . . . . . . . . . . . . 28 105 Appendix A. Implementation of a full-fledged IPv6 address- 106 scanning tool . . . . . . . . . . . . . . . . . . . 31 107 A.1. Host-probing considerations . . . . . . . . . . . . . . . 31 108 A.2. Implementation of an IPv6 local address-scanning tool . . 33 109 A.3. Implementation of a IPv6 remote address-scanning tool . . 34 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 112 1. Introduction 114 The main driver for IPv6 [RFC2460] deployment is its larger address 115 space [CPNI-IPv6]. This larger address space not only allows for an 116 increased number of connected devices, but also introduces a number 117 of subtle changes in several aspects of the resulting networks. One 118 of these changes is the reduced host density (the number of hosts 119 divided by the number of addresses) of typical IPv6 subnetworks, when 120 compared to their IPv4 counterparts. [RFC5157] describes how this 121 significantly lower IPv6 host-density is likely to make classic 122 network address scans less feasible, since even by applying various 123 heuristics, the address space to be scanned remains very large. RFC 124 5157 goes on to describe some alternative methods for attackers to 125 glean active IPv6 addresses, and provides some guidance for 126 administrators and implementors, e.g. not using sequential addresses 127 with DHCPv6. 129 With the benefit of more than five years of additional IPv6 130 deployment experience, this document formally obsoletes RFC 5157. It 131 emphasises that while scanning attacks are less feasible, they may, 132 with appropriate heuristics, remain possible. At the time that RFC 133 5157 was written, observed scans were typically across ports on the 134 addresses of discovered servers; since then, evidence that some 135 classic address scanning is occurring is being witnessed. This text 136 thus updates the analysis on the feasibility of "traditional" 137 address-scanning attacks in IPv6 networks, and it explores a number 138 of additional techniques that can be employed for IPv6 network 139 reconnaissance. Practical examples and guidance are also included in 140 the Appendices. 142 On one hand, raising awareness about IPv6 network reconnaissance 143 techniques may allow (in some cases) network and security 144 administrators to prevent or detect such attempts. On the other 145 hand, network reconnaissance is essential for the so-called 146 "penetration tests" typically performed to assess the security of 147 production networks. As a result, we believe the benefits of a 148 thorough discussion of IPv6 network reconnaissance are two-fold. 150 Section 3 analyzes the feasibility of traditional address-scanning 151 attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of 152 possible improvements to such techniques. Appendix A describes how 153 the aforementioned analysis can be leveraged to produce address- 154 scanning tools (e.g. for penetration testing purposes). Section 4 155 analyzes network reconnaissance techniques that leverage the Domain 156 Name System (DNS). Finally, the rest of this document discusses a 157 number of other miscellaneous techniques that could be leveraged for 158 IPv6 network reconnaissance. 160 2. Requirements for the Applicability of Network Reconnaissance 161 Techniques 163 Throughout this document, a number of network reconnaissance 164 techniques are discussed. Each of these techniques have different 165 requirements on the side of the practitioner, with respect to whether 166 they require local access to the target network, and whether they 167 require login access (or similar access credentials) to the system on 168 which the technique is applied. 170 The following table tries to summarize the aforementioned 171 requirements, and serves as a cross index to the corresponding 172 sections. 174 +---------------------------------------------+----------+----------+ 175 | Technique | Local | Login | 176 | | access | access | 177 +---------------------------------------------+----------+----------+ 178 | Local address scans (Section 3.3) | Yes | No | 179 +---------------------------------------------+----------+----------+ 180 | Remote Address scans (Section 3.2) | No | No | 181 +---------------------------------------------+----------+----------+ 182 | DNS Advertised Hosts (Section 4.1) | No | No | 183 +---------------------------------------------+----------+----------+ 184 | DNS Zone Transfers (Section 4.2) | No | No | 185 +---------------------------------------------+----------+----------+ 186 | DNS reverse mappings (Section 4.4) | No | No | 187 +---------------------------------------------+----------+----------+ 188 | Public archives (Section 6) | No | No | 189 +---------------------------------------------+----------+----------+ 190 | Application Participation (Section 7) | No | No | 191 +---------------------------------------------+----------+----------+ 192 | Inspection of the IPv6 Neighbor Cache and | No | Yes | 193 | Routing Table (Section 8) | | | 194 +---------------------------------------------+----------+----------+ 195 | Inspecting System Configuration and Log | No | Yes | 196 | Files (Section 9) | | | 197 +---------------------------------------------+----------+----------+ 198 | Gleaning information from Routing Protocols | Yes | No | 199 | (Section 10) | | | 200 +---------------------------------------------+----------+----------+ 201 | Gleaning Information from IP Flow | No | Yes | 202 | Information Export (IPFIX) (Section 11) | | | 203 +---------------------------------------------+----------+----------+ 204 | Obtaining Network Information with | No | No | 205 | traceroute6 (Section 12) | | | 206 +---------------------------------------------+----------+----------+ 207 | Gleaning Information from Network Devices | No | Yes | 208 | Using SNMP | | | 209 +---------------------------------------------+----------+----------+ 210 | Obtaining Network Information via Traffic | Yes | No | 211 | Snooping | | | 212 +---------------------------------------------+----------+----------+ 214 Table 1: Requirements for the Applicability of Network Reconnaissance 215 Techniques 217 3. IPv6 Address Scanning 219 This section discusses how traditional address scanning techniques 220 (e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an 221 essential analysis of how address configuration is performed in IPv6, 222 identifying patterns in IPv6 addresses that can be leveraged to 223 reduce the IPv6 address search space when performing IPv6 address 224 scans. Appendix A discusses how the insights obtained in the 225 previous sub-sections can be incorporated into into a fully-fledged 226 IPv6 address scanning tool. Section 3.5 provides advice on how to 227 mitigate IPv6 address scans. 229 3.1. Address Configuration in IPv6 231 IPv6 incorporates two automatic address-configuration mechanisms: 232 SLAAC (StateLess Address Auto-Configuration) [RFC4862] and DHCPv6 233 (Dynamic Host Configuration Protocol version 6) [RFC3315]. SLAAC is 234 the mandatory mechanism for automatic address configuration, while 235 DHCPv6 is optional - however, most current versions of general- 236 purpose operating systems support both. In addition to automatic 237 address configuration, hosts, typically servers, may employ manual 238 configuration, in which all the necessary information is manually 239 entered by the host or network administrator into configuration files 240 at the host. 242 The following subsections describe each of the possible configuration 243 mechanisms/approaches in more detail. 245 3.1.1. StateLess Address Auto-Configuration (SLAAC) 247 The basic idea behind SLAAC is that every host joining a network will 248 send a multicasted solicitation requesting network configuration 249 information, and local routers will respond to the request providing 250 the necessary information. SLAAC employs two different ICMPv6 251 message types: ICMPv6 Router Solicitation and ICMPv6 Router 252 Advertisement messages. Router Solicitation messages are employed by 253 hosts to query local routers for configuration information, while 254 Router Advertisement messages are employed by local routers to convey 255 the requested information. 257 Router Advertisement messages convey a plethora of network 258 configuration information, including the IPv6 prefix that should be 259 used for configuring IPv6 addresses on the local network. For each 260 local prefix learned from a Router Advertisement message, an IPv6 261 address is configured by appending a locally-generated Interface 262 Identifier (IID) to the corresponding IPv6 prefix. 264 The following subsections describe currently-deployed policies for 265 generating the IIDs used with SLAAC. 267 3.1.1.1. Interface-Identifiers Embedding IEEE Identifiers 269 The traditional SLAAC interface identifiers are based on the link- 270 layer address of the corresponding network interface card. For 271 example, in the case of Ethernet addresses, the IIDs are constructed 272 as follows: 274 1. The "Universal" bit (bit 6, from left to right) of the address is 275 set to 1 277 2. The word 0xfffe is inserted between the OUI (Organizationally 278 Unique Identifier) and the rest of the Ethernet address 280 For example, the MAC address 00:1b:38:83:88:3c would lead to the IID 281 021b:38ff:fe83:883c. 283 NOTE: 284 [RFC7136] notes that all bits of an IID should be treated as 285 "opaque" bits. Furthermore, [I-D.ietf-6man-default-iids] is 286 currently in the process of changing the default IID generation 287 scheme to [RFC7217]. Therefore, the traditional IIDs based on 288 link-layer addresses are expected to become less common over time. 290 Throughout this document we consider that bits are numbered from 291 left to right, starting at 0, and that bytes are numbered from 292 left to right, starting at 0. 294 A number of considerations should be made about these identifiers. 295 Firstly, two bytes (bytes 3-4) of the resulting address always have a 296 fixed value (0xff, 0xfe), thus reducing the search space for the IID. 297 Secondly, the first three bytes of these identifiers correspond to 298 the OUI of the network interface card vendor. Since not all possible 299 OUIs have been assigned, this further reduces the IID search space. 300 Furthermore, of the assigned OUIs, many could be regarded as 301 corresponding to legacy devices, and thus unlikely to be used for 302 Internet-connected IPv6-enabled systems, yet further reducing the IID 303 search space. Finally, in some scenarios it could be possible to 304 infer the OUI in use by the target network devices, yet narrowing 305 down the possible IIDs even more. 307 For example, an organization known for being provisioned by vendor 308 X is likely to have most of the nodes in its organizational 309 network with OUIs corresponding to vendor X. 311 These considerations mean that in some scenarios, the original IID 312 search space of 64 bits may be effectively reduced to 2^24 , or n * 313 2^24 (where "n" is the number of different OUIs assigned to the 314 target vendor). 316 Further, if just one host address is detected or known within a 317 subnet, it is not unlikely that, if systems were ordered in a batch, 318 that they may have sequential MAC addresses. Additionally, given a 319 MAC address observed in one subnet, sequential or nearby MAC 320 addresses may be seen in other subnets in the same site. 322 3.1.1.2. Interface-Identifiers of Virtualization Technologies 324 IIDs resulting from virtualization technologies can be considered a 325 specific sub-case of IIDs embedding IEEE identifiers (please see 326 Section 3.1.1.1): they employ IEEE identifiers, but part of the lower 327 half of the IID has specific patterns. The following subsections 328 describe IIDs of some popular virtualization technologies. 330 3.1.1.2.1. VirtualBox 332 All automatically-generated MAC addresses in VirtualBox virtual 333 machines employ the OUI 08:00:27 [VBox2011]. This means that all 334 SLAAC-produced addresses will have an IID of the form 335 a00:27ff:feXX:XXXX, thus effectively reducing the IID search space 336 from 64 bits to 24 bits. 338 3.1.1.2.2. VMWare ESX server 340 VMWare ESX server (versions 1.0 to 2.5) provides yet a more 341 interesting example. Automatically-generated MAC addresses have the 342 following pattern [vmesx2011]: 344 1. The OUI is set to 00:05:69 346 2. The next 16 bits of the MAC address are set to the same value as 347 the last 16 bits of the console operating system's primary IPv4 348 address 350 3. The final 8 bits of the MAC address are set to a hash value based 351 on the name of the virtual machine's configuration file. 353 This means that, assuming the console operating system's primary IPv4 354 address is known, the IID search space is reduced from 64 bits to 8 355 bits. 357 On the other hand, manually-configured MAC addresses in VMWare ESX 358 server employ the OUI 00:50:56, with the low-order three bytes being 359 in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware 360 products). Therefore, even in the case of manually-configured MAC 361 addresses, the IID search space is reduced from 64 bits to 22 bits. 363 3.1.1.2.3. VMWare vSphere 365 VMWare vSphere [vSphere] supports these default MAC address 366 generation algorithms: 368 o Generated addresses 370 * Assigned by vCenter Server 372 * Assigned by the ESXi host 374 o Manually-configured addresses 376 By default, MAC addresses assigned by the vCenter server use the OUI 377 00:50:56, and have the format 00:50:56:XX:YY:ZZ, where XX is 378 calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)), 379 and XX and YY are random two-digit hexadecimal numbers. Thus, the 380 possible IID range is 00:50:56:80:00:00-00:50:56:BF:FF:FF, and 381 therefore the search space for the resulting SLAAC addresses will be 382 24 bits. 384 MAC addresses generated by the ESXi host use the OUI 00:0C:29, and 385 have the format 00:0C:29:XX:YY:ZZ, where XX, YY, and ZZ are the 386 lastthree octets in hexadecimal format of the virtual machine UUID 387 (based on a hash calculated by using the UUID of the ESXi physical 388 machine and the path to a configuration file). Thus, the MAC 389 addresses will be in the range 00:0C:29:XX:YY:ZZ-00:0C:29:FF:FF:FF, 390 and therefore the search space for the resulting SLAAC addresses will 391 be 22 bits. 393 Finally, manually-configured MAC addresses employ the OUI 00:50:56, 394 with the low-order three bytes being in the range 0x000000-0x3fffff 395 (to avoid conflicts with other VMware products). Therefore, 396 therefore the search space for the resulting SLAAC addresses will be 397 22 bits. 399 3.1.1.3. Temporary Addresses 401 Privacy concerns [Gont-DEEPSEC2011] 402 [I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface 403 identifiers embedding IEEE identifiers led to the introduction of 404 "Privacy Extensions for Stateless Address Auto-configuration in IPv6" 405 [RFC4941], also known as "temporary addresses" or "privacy 406 addresses". Essentially, "temporary addresses" produce random 407 addresses by concatenating a random identifier to the auto- 408 configuration IPv6 prefix advertised in a Router Advertisement. 410 In addition to their unpredictability, these addresses are 411 typically short-lived, such that even if an attacker were to learn 412 one of these addresses, they would be of use for a limited period 413 of time. A typical implementation may keep a temporary address 414 preferred for 24 hours, and configured but deprecated for seven 415 days. 417 It is important to note that "temporary addresses" are generated in 418 addition to traditional SLAAC addresses (i.e., based on IEEE 419 identifiers): traditional SLAAC addresses are meant to be employed 420 for "server-like" inbound communications, while "temporary addresses" 421 are meant to be employed for "client-like" outbound communications. 422 This means that implementation/use of "temporary addresses" does not 423 prevent an attacker from leveraging the predictability of traditional 424 SLAAC addresses, since "temporary addresses" are generated in 425 addition to (rather than as a replacement of) the traditional SLAAC 426 addresses derived from e.g. IEEE identifiers. 428 The benefit that temporary addresses offer in this context is that 429 they reduce the exposure of the SLAAC address to any third parties 430 that may observe traffic sent from a host where temporary addresses 431 are enabled and used by default. But, in the absence of firewall 432 protection for the host, its SLAAC address remains liable to be 433 scanned from offsite. 435 3.1.1.4. Constant, semantically opaque IIDs 437 In order to mitigate the security implications arising from the 438 predictable IPv6 addresses derived from IEEE identifiers, Microsoft 439 Windows produced an alternative scheme for generating "stable 440 addresses" (in replacement of the ones embedding IEEE identifiers). 441 The aforementioned scheme is believed to be an implementation of RFC 442 4941 [RFC4941], but without regenerating the addresses over time. 443 The resulting interface IDs are constant across system bootstraps, 444 and also constant across networks. 446 Assuming no flaws in the aforementioned algorithm, this scheme would 447 remove any patterns from the SLAAC addresses. 449 However, since the resulting interface IDs are constant across 450 networks, these addresses may still be leveraged for host tracking 451 purposes [RFC7217] 452 [I-D.ietf-6man-ipv6-address-generation-privacy]. 454 The benefit of this scheme is thus that the host may be less readily 455 detected by applying heuristics to a scan, but, in the absence of 456 concurrent use of temporary addresses, the host is liable to be 457 tracked across visited networks. 459 3.1.1.5. Stable, semantically opaque IIDs 461 In response to the predictability issues discussed in Section 3.1.1.1 462 and the privacy issues discussed in 463 [I-D.ietf-6man-ipv6-address-generation-privacy], the IETF has 464 standardized (in [RFC7217]) a method for generating IPv6 Interface 465 Identifiers to be used with IPv6 Stateless Address Autoconfiguration 466 (SLAAC), such that addresses configured using this method are stable 467 within each subnet, but the Interface Identifier changes when hosts 468 move from one subnet to another. The aforementioned method is meant 469 to be an alternative to generating Interface Identifiers based on 470 IEEE identifiers, such that the benefits of stable addresses can be 471 achieved without sacrificing the privacy of users. 473 Implementation of this method (in replacement of Interface 474 Identifiers based on IEEE identifiers) would eliminate any patterns 475 from the Interface ID, thus benefiting user privacy and reducing the 476 ease with which addresses can be scanned. 478 3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) 480 DHC DHCPv6 can be employed as a stateful address configuration 481 mechanism, in which a server (the DHCPv6 server) leases IPv6 482 addresses to IPv6 hosts. As with the IPv4 counterpart, addresses are 483 assigned according to a configuration-defined address range and 484 policy, with some DHCPv6 servers assigning addresses sequentially, 485 from a specific range. In such cases, addresses tend to be 486 predictable. 488 For example, if the prefix 2001:db8::/64 is used for assigning 489 addresses on the local network, the DHCPv6 server might 490 (sequentially) assign addresses from the range 2001:db8::1 - 491 2001:db8::100. 493 In most common scenarios, this means that the IID search space will 494 be reduced from the original 64 bits, to 8 or 16 bits. RFC 5157 495 recommended that DHCPv6 instead issue addresses randomly from a large 496 pool; that advice is repeated here. 497 [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that 498 can be employed by DHCPv6 servers to produce stable addresses which 499 do not follow any specific pattern, thus resulting in an IID search 500 space of 64 bits. 502 3.1.3. Manually-configured Addresses 504 In some scenarios, node addresses may be manually configured. This 505 is typically the case for IPv6 addresses assigned to routers (since 506 routers do not employ automatic address configuration) but also for 507 servers (since having a stable address that does not depend on the 508 underlying link-layer address is generally desirable). 510 While network administrators are mostly free to select the IID from 511 any value in the range 1 - 2^64, for the sake of simplicity (i.e., 512 ease of remembering) they tend to select addresses with one of the 513 following patterns: 515 o "low-byte" addresses: in which most of the bytes of the IID are 516 set to 0 (except for the least significant byte). 518 o IPv4-based addresses: in which the IID embeds the IPv4 address of 519 the network interface (as in 2001:db8::192.0.2.1) 521 o "service port" addresses: in which the IID embeds the TCP/UDP 522 service port of the main service running on that node (as in 523 2001:db8::80 or 2001:db8::25) 525 o wordy addresses: which encode words (as in 2001:db8::dead:beef) 527 Each of these patterns is discussed in detail in the following 528 subsections. 530 3.1.3.1. Low-byte Addresses 532 The most common form of low-byte addresses is that in which all the 533 the bytes of the IID (except the least significant bytes) are set to 534 zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also 535 common to find similar addresses in which the two lowest order 16-bit 536 words (from the right to left) are set to small numbers (as in 537 2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to 538 find IPv6 addresses in which the second lowest-order 16-bit word 539 (from right to left) is set to a small value in the range 0-255, 540 while the lowest-order 16-bit word (from right to left) varies in the 541 range 0-65535. It should be noted that all of these address patterns 542 are generally referred to as "low-byte addresses", even when, 543 strictly speaking, it is not only the lowest-order byte of the IPv6 544 address that varies from one address to another. 546 In the worst-case scenario, the search space for this pattern is 2^24 547 (although most systems can be found by searching 2^16 or even 2^8 548 addresses). 550 3.1.3.2. IPv4-based Addresses 552 The most common form of these addresses is that in which an IPv4 553 address is encoded in the lowest-order 32 bits of the IPv6 address 554 (usually as a result of the notation of addresses in the form 555 2001:db8::192.0.2.1). However, it is also common for administrators 556 to encode one byte of the IPv4 address in each of the 16-bit words of 557 the IID (as in e.g. 2001:db8::192:0:2:1). 559 Therefore, the search space for addresses following this pattern is 560 that of the corresponding IPv4 prefix (or twice the size of that 561 search space if both forms of "IPv4-based addresses" are to be 562 searched). 564 3.1.3.3. Service-port Addresses 566 Address following this pattern include the service port (e.g. 80 for 567 HTTP) in the lowest-order byte of the IID, and set the rest of the 568 IID to zero. There are a number of variants for this address 569 pattern: 571 o The lowest-order 16-bit word (from right to left) may contain the 572 service port, and the second lowest-order 16-bit word (from right 573 to left) may be set to a number in the range 0-255 (as in e.g. 574 2001:db8::1:80). 576 o The lowest-order 16-bit word (from right to left) may be set to a 577 value in the range 0-255, while the second lowest-order 16-bit 578 word (from right to left) may contain the service port (as in e.g. 579 2001:db8::80:1). 581 o The service port itself might be encoded in decimal or in 582 hexadecimal notation (e.g., an address embedding the HTTP port 583 might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding 584 the service port as a decimal number being more common. 586 Considering a maximum of 20 popular service ports, the search space 587 for addresses following this pattern is, in the worst-case scenario, 588 20 * 2^10. 590 3.1.3.4. Wordy Addresses 592 Since IPv6 address notation allows for a number of hexadecimal 593 digits, it is not difficult to encode words into IPv6 addresses (as 594 in, e.g., 2001:db8::dead:beef). 596 Addresses following this pattern are likely to be explored by means 597 of "dictionary attacks", and therefore computing the corresponding 598 search-space is not straight-forward. 600 3.1.4. IPv6 Addresses Corresponding to Transition/Co-existence 601 Technologies 603 Some transition/co-existence technologies might be leveraged to 604 reduce the target search space of remote address-scanning attacks, 605 since they specify how the corresponding IPv6 address must be 606 generated. For example, in the case of Teredo [RFC4380], the 64-bit 607 interface identifier is generated from the IPv4 address observed at a 608 Teredo server along with a UDP port number. 610 3.1.5. IPv6 Address Assignment in Real-world Network Scenarios 612 Table 2, Table 3 and Table 4 provide a summary of the results 613 obtained by [Gont-LACSEC2013] for web servers, nameservers, and 614 mailservers, respectively. Table 5 provides a rough summary of the 615 results obtained by [Malone2008] for IPv6 routers. Table 6 provides 616 a summary of the results obtained by [Ford2013] for clients. 618 +---------------+------------+ 619 | Address type | Percentage | 620 +---------------+------------+ 621 | IEEE-based | 1.44% | 622 +---------------+------------+ 623 | Embedded-IPv4 | 25.41% | 624 +---------------+------------+ 625 | Embedded-Port | 3.06% | 626 +---------------+------------+ 627 | ISATAP | 0% | 628 +---------------+------------+ 629 | Low-byte | 56.88% | 630 +---------------+------------+ 631 | Byte-pattern | 6.97% | 632 +---------------+------------+ 633 | Randomized | 6.24% | 634 +---------------+------------+ 636 Table 2: Measured webserver addresses 637 +---------------+------------+ 638 | Address type | Percentage | 639 +---------------+------------+ 640 | IEEE-based | 0.67% | 641 +---------------+------------+ 642 | Embedded-IPv4 | 22.11% | 643 +---------------+------------+ 644 | Embedded-Port | 6.48% | 645 +---------------+------------+ 646 | ISATAP | 0% | 647 +---------------+------------+ 648 | Low-byte | 56.58% | 649 +---------------+------------+ 650 | Byte-pattern | 11.07% | 651 +---------------+------------+ 652 | Randomized | 3.09% | 653 +---------------+------------+ 655 Table 3: Measured nameserver addresses 657 +---------------+------------+ 658 | Address type | Percentage | 659 +---------------+------------+ 660 | IEEE-based | 0.48% | 661 +---------------+------------+ 662 | Embedded-IPv4 | 4.02% | 663 +---------------+------------+ 664 | Embedded-Port | 1.07% | 665 +---------------+------------+ 666 | ISATAP | 0% | 667 +---------------+------------+ 668 | Low-byte | 92.65% | 669 +---------------+------------+ 670 | Byte-pattern | 1.20% | 671 +---------------+------------+ 672 | Randomized | 0.59% | 673 +---------------+------------+ 675 Table 4: Measured mailserver addresses 676 +--------------+------------+ 677 | Address type | Percentage | 678 +--------------+------------+ 679 | Low-byte | 70% | 680 +--------------+------------+ 681 | IPv4-based | 5% | 682 +--------------+------------+ 683 | SLAAC | 1% | 684 +--------------+------------+ 685 | Wordy | <1% | 686 +--------------+------------+ 687 | Randomized | <1% | 688 +--------------+------------+ 689 | Teredo | <1% | 690 +--------------+------------+ 691 | Other | <1% | 692 +--------------+------------+ 694 Table 5: Measured router addresses 696 +---------------+------------+ 697 | Address type | Percentage | 698 +---------------+------------+ 699 | IEEE-based | 7.72% | 700 +---------------+------------+ 701 | Embedded-IPv4 | 14.31% | 702 +---------------+------------+ 703 | Embedded-Port | 0.21% | 704 +---------------+------------+ 705 | ISATAP | 1.06% | 706 +---------------+------------+ 707 | Randomized | 69.73% | 708 +---------------+------------+ 709 | Low-byte | 6.23% | 710 +---------------+------------+ 711 | Byte-pattern | 0.74% | 712 +---------------+------------+ 714 Table 6: Measured client addresses 716 It should be clear from these measurements that a very high 717 percentage of host and router addresses follow very specific 718 patterns. 720 Table 6 shows that while around 70% of clients observed in this 721 measurement appear to be using temporary addresses, there are still a 722 significant amount exposing IEEE-based addresses, and addresses using 723 embedded IPv4 (thus also revealing IPv4 addresses). 725 3.2. IPv6 Address Scanning of Remote Networks 727 While in IPv4 networks attackers have been able to get away with 728 "brute force" scanning attacks (thanks to the reduced search space), 729 successfully performing a brute-force scan of an entire /64 network 730 would be infeasible. As a result, it is expected that attackers will 731 leverage the IPv6 address patterns discussed in Section 3.1 to reduce 732 the IPv6 address search space. 734 IPv6 address scanning of remote area networks should consider an 735 additional factor not present for the IPv4 case: since the typical 736 IPv6 host subnet is a /64, scanning an entire /64 could, in theory, 737 lead to the creation of 2^64 entries in the Neighbor Cache of the 738 last-hop router. Unfortunately, a number of IPv6 implementations 739 have been found to be unable to properly handle large number of 740 entries in the Neighbor Cache, and hence these address-scan attacks 741 may have the side effect of resulting in a Denial of Service (DoS) 742 attack [CPNI-IPv6] [RFC6583]. 744 [RFC7421] discusses the "default" /64 boundary for host subnets, and 745 the assumptions surrounding it. While there are reports of a handful 746 of sites implementing host subnets of size /112 or smaller to reduce 747 concerns about the above attack, such smaller subnets are likely to 748 make address-based scanning more feasible, in addition to 749 encountering the issues with non-/64 host subnets discussed in the 750 above draft. 752 3.2.1. Reducing the subnet ID search space 754 When scanning a remote network, consideration is required to select 755 which subnet IDs to choose. A typical site might have a /48 756 allocation, which would mean up to 65,000 or so host /64 subnets to 757 be scanned. 759 However, in the same way the search space for the IID can be reduced, 760 we may also be able to reduce the subnet ID space in a number of 761 ways, by guessing likely address plan schemes, or using any 762 complementary clues that might exist from other sources or 763 observations. For example there are a number of documents available 764 online (e.g. [RFC5375]) that provide recommendations for allocation 765 of address space, which address various operational considerations, 766 including: RIR assignment policy, ability to delegate reverse DNS 767 zones to different servers, ability to aggregate routes efficiently, 768 address space preservation, ability to delegate address assignment 769 within the organization, ability to add allocate new sites/prefixes 770 to existing entities without updating ACLs, and ability to de- 771 aggregate and advertise sub-spaces via various AS interfaces. 773 Address plans might include use of subnets which: 775 o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64, 776 etc. 778 o Use building numbers, in hex or decimal form. 780 o Use VLAN numbers. 782 o Use IPv4 subnet number in a dual-stack target, e.g. a site with a 783 /16 for IPv4 might use /24 subnets, and the IPv6 address plan may 784 re-use the third byte as the IPv6 subnet ID. 786 o Use the service "colour", as defined for service-based prefix 787 colouring, or semantic prefixes. For example, a site using a 788 specific colouring for a specific service such as VoIP may reduce 789 the subnet ID search space for those devices. 791 The net effect is that the address space of an organization may be 792 highly structured, and allocations of individual elements within this 793 structure may be predictable once other elements are known. 795 In general, any subnet ID address plan may convey information, or be 796 based on known information, which may in turn be of advantage to an 797 attacker. 799 3.3. IPv6 Address Scanning of Local Networks 801 IPv6 address scanning in Local Area Networks could be considered, to 802 some extent, a completely different problem than that of scanning a 803 remote IPv6 network. The main difference is that use of link-local 804 multicast addresses can relieve the attacker of searching for unicast 805 addresses in a large IPv6 address space. 807 While a number of other network reconnaissance vectors (such as 808 network snooping, leveraging Neighbor Discovery traffic, etc.) are 809 available when scanning a local network, this section focuses only 810 on address-scanning attacks (a la "ping sweep"). 812 An attacker can simply send probe packets to the all-nodes link-local 813 multicast address (ff02::1), such that responses are elicited from 814 all local nodes. 816 Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo 817 Request messages sent to multicast addresses, IPv6 address-scanning 818 tools typically employ a number of additional probe packets to elicit 819 responses from all the local nodes. For example, unrecognized IPv6 820 options of type 10xxxxxx elicit ICMPv6 Parameter Problem, code 2, 821 error messages. 823 Many address-scanning tools discover only IPv6 link-local addresses 824 (rather than e.g. the global addresses of the target systems): since 825 the probe packets are typically sent with the attacker's IPv6 link- 826 local address, the "victim" nodes send the response packets using the 827 IPv6 link-local address of the corresponding network interface (as 828 specified by the IPv6 address selection rules [RFC6724]). However, 829 sending multiple probe packets, with each packet employing addresses 830 from different prefixes, typically helps to overcome this limitation. 832 This technique is employed by the scan6 tool of the IPv6 Toolkit 833 package [IPv6-Toolkit]. 835 3.4. Existing IPv6 Address Scanning Tools 837 3.4.1. Remote IPv6 Network Scanners 839 IPv4 address scanning tools have traditionally carried out their task 840 for probing an entire address range (usually the entire range of a 841 target subnetwork). One might argue that the reason for which we 842 have been able to get away with such somewhat "rudimentary" 843 techniques is that the scale or challenge of the task is so small in 844 the IPv4 world, that a "brute-force" attack is "good enough". 845 However, the scale of the "address scanning" task is so large in 846 IPv6, that attackers must be very creative to be "good enough". 847 Simply sweeping an entire /64 IPv6 subnet would just not be feasible. 849 Many address scanning tools such as nmap [nmap2012] do not even 850 support sweeping an IPv6 address range. On the other hand, the 851 alive6 tool from [THC-IPV6] supports sweeping address ranges, thus 852 being able to leverage some patterns found in IPv6 addresses, such as 853 the incremental addresses resulting from some DHCPv6 setups. 854 Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address 855 ranges, and can also leverage all the address patterns described in 856 Section 3.1 of this document. 858 Clearly, a limitation of many of the currently-available tools for 859 IPv6 address scanning is that they lack of an appropriately tuned 860 "heuristics engine" that can help reduce the search space, such that 861 the problem of IPv6 address scanning becomes tractable. 863 It should be noted that IPv6 network monitoring and management tools 864 also need to build and maintain information about the hosts in their 865 network. Such systems can no longer scan internal systems in a 866 reasonable time to build a database of connected systems. Rather, 867 such systems will need more efficient approaches, e.g. by polling 868 network devices for data held about observed IP addresses, MAC 869 addresses, physical ports used, etc. Such an approach can also 870 enhance address accountability, by mapping IPv4 and IPv6 addresses to 871 observed MAC addresses. This of course implies that any access 872 control mechanisms for querying such network devices, e.g. community 873 strings for SNMP, should be set appropriately to avoid an attacker 874 being able to gather address information remotely. 876 3.4.2. Local IPv6 Network Scanners 878 There are a variety of publicly-available local IPv6 network 879 scanners: 881 o Current versions of nmap [nmap2012] implement this functionality. 883 o THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool (alive6) that 884 implements this functionality. 886 o SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) 887 that implements this functionality. 889 3.5. Mitigations 891 IPv6 address-scanning attacks can be mitigated in a number of ways. 892 A non-exhaustive list of the possible mitigations includes: 894 o Employing [RFC7217] (stable, semantically opaque IIDs) in 895 replacement of addresses based on IEEE identifiers, such that any 896 address patterns are eliminated. 898 o Employing Intrusion Prevention Systems (IPS) at the perimeter, 899 such that address scanning attacks can be mitigated. 901 o Enforce IPv6 packet filtering where applicable (see e.g. 902 [RFC4890]). 904 o If virtual machines are employed, and "resistance" to address 905 scanning attacks is deemed as desirable, manually-configured MAC 906 addresses can be employed, such that even if the virtual machines 907 employ IEEE-derived IIDs, they are generated from non-predictable 908 MAC addresses. 910 o When using DHCPv6, avoid use of sequential addresses. Ideally, 911 the DHCPv6 server would allocate random addresses from a large 912 pool. 914 o Use the "default" /64 size IPv6 subnet prefixes. 916 o In general, avoid being predictable in the way addresses are 917 assigned. 919 It should be noted that some of the aforementioned mitigations are 920 operational, while others depend on the availability of specific 921 protocol features (such as [RFC7217]) on the corresponding nodes. 923 Additionally, while some resistance to address scanning attacks is 924 generally desirable (particularly when lightweight mitigations are 925 available), there are scenarios in which mitigation of some address- 926 scanning vectors is unlikely to be a high-priority (if at all 927 possible). And one should always remember that security by obscurity 928 is not a reasonable defence in itself; it may only be one (relatively 929 small) layer in a broader security environment. 931 Two of the techniques discussed in this document for local address- 932 scanning attacks are those that employ multicasted ICMPv6 Echo 933 Requests and multicasted IPv6 packets containing unsupported options 934 of type 10xxxxxx. These two vectors could be easily mitigated by 935 configuring nodes to not respond to multicasted ICMPv6 Echo Request 936 (default on Windows systems), and by updating the IPv6 specifications 937 (and/or possibly configuring local nodes) such that multicasted 938 packets never elicit ICMPv6 error messages (even if they contain 939 unsupported options of type 10xxxxxx). 941 [I-D.gont-6man-ipv6-smurf-amplifier] proposes such update to the 942 IPv6 specifications. 944 In any case, when it comes to local networks, there are a variety of 945 network reconnaissance vectors. Therefore, even if address-scanning 946 vectors are mitigated, an attacker could still rely on e.g. protocols 947 employed for the so-called "opportunistic networking" (such as mDNS 948 [RFC6762]), or eventually rely on network snooping as last resort for 949 network reconnaissance. There is ongoing work in the IETF on 950 extending mDNS, or at least DNS-based service discovery, to work 951 across a whole site, rather than in just a single subnet, which will 952 have associated security implications. 954 4. Leveraging the Domain Name System (DNS) for Network Reconnaissance 956 4.1. DNS Advertised Hosts 958 Any systems that are "published" in the DNS, e.g. MX mail relays, or 959 web servers, will remain open to probing from the very fact that 960 their IPv6 addresses are publicly available. It is worth noting that 961 where the addresses used at a site follow specific patterns, 962 publishing just one address may lead to a threat upon the other 963 hosts. 965 Additionally, we note that publication of IPv6 addresses in the DNS 966 should not discourage the elimination of IPv6 address patterns: if 967 any address patterns are eliminated from addresses published in the 968 DNS, an attacker may have to rely on performing dictionary-based DNS 969 lookups in order to find all systems in a target network (which is 970 generally less reliable and more time/traffic consuming than mapping 971 nodes with predictable IPv6 addresses). 973 4.2. DNS Zone Transfers 975 A DNS zone transfer can readily provide information about potential 976 attack targets. Restricting zone transfers is thus probably more 977 important for IPv6, even if it is already good practice to restrict 978 them in the IPv4 world. 980 4.3. DNS Brute Forcing 982 Attackers may employ DNS brute-forcing techniques by testing for the 983 presence of DNS AAAA records against commonly used host names. 985 4.4. DNS Reverse Mappings 987 [van-Dijk] describes an interesting technique that employs DNS 988 reverse mappings for network reconnaissance. Essentially, the 989 attacker walks through the "ip6.arpa" zone looking up PTR records, in 990 the hopes of learning the IPv6 addresses of hosts in a given target 991 network (assuming that the reverse mappings have been configured, of 992 course). What is most interesting about this technique is that it 993 can greatly reduce the IPv6 address search space. 995 Basically, an attacker would walk the ip6.arpa zone corresponding to 996 a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for 997 "2001:db8:80::/48"), issuing queries for PTR records corresponding to 998 the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", 999 "1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR 1000 records for any hosts "starting" with the domain name 1001 "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name 1002 corresponding to the IPv6 address 2001:db8:80::1), the response would 1003 contain an RCODE of 0 (no error). Otherwise, the response would 1004 contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this 1005 technique allows for a tremendous reduction in the "IPv6 address" 1006 search space. 1008 [I-D.howard-isp-ip6rdns] analyzes different approaches and 1009 considerations for ISPs in managing the ip6.arpa zone for IPv6 1010 address space assigned to many customers, which may affect the 1011 technique described in this section. 1013 5. Leveraging Local Name Resolution and Service Discovery Services 1015 A number of protocols allow for unmanaged local name resolution and 1016 service. For example, multicast DNS (mDNS) [RFC6762] and DNS Service 1017 Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution 1018 (LLMNR) [RFC4795], are examples of such protocols. 1020 Besides the Graphical User Interfaces (GUIs) included in products 1021 supporting such protocols, command-line tools such as mdns-scan 1022 [mdns-scan] and mzclient can help discover IPv6 hosts employing 1023 mDNS/DNS-SD. 1025 6. Public Archives 1027 Public mailing-list archives or Usenet news messages archives may 1028 prove a useful channel for an attacker, since hostnames and/or IPv6 1029 addresses could be easily obtained by inspection of the (many) 1030 "Received from:" or other header lines in the archived email or 1031 Usenet news messages. 1033 7. Application Participation 1035 Peer-to-peer applications often include some centralized server which 1036 coordinates the transfer of data between peers. For example, 1037 BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks 1038 of files, with a tracker passing information about peers with 1039 available chunks of data between the peers. Such applications may 1040 offer an attacker a source of peer addresses to probe. 1042 8. Inspection of the IPv6 Neighbor Cache and Routing Table 1044 Information about other systems connected to the local network might 1045 be readily available from the Neighbor Cache [RFC4861] and/or the 1046 routing table of any system connected to such network. SAVI 1047 [RFC6620] also builds a cache of IPv6 and link-layer addresses 1048 (without actively participating in the Neighbor Discovery packet 1049 exchange), and hence is another source of similar information. 1051 These data structures could be inspected either via "login" access or 1052 via SNMP. While this requirement may limit the applicability of this 1053 technique, there are a number of scenarios in which this technique 1054 might be of use. For example, security audit tools might be provided 1055 with the necessary credentials such that the Neighbor Cache and the 1056 routing table of all systems for which the tool has "login" or SNMP 1057 access can be automatically gleaned. On the other hand, IPv6 worms 1058 [V6-WORMS] could leverage this technique for the purpose of spreading 1059 on the local network, since they will typically have access to the 1060 Neighbor Cache and routing table of an infected system. 1062 Section 2.5.1.4 of [I-D.ietf-opsec-v6] discusses additional 1063 considerations for the inspection of the IPv6 Neighbor Cache. 1065 9. Inspection of System Configuration and Log Files 1067 Nodes are generally configured with the addresses of other important 1068 local computers, such as email servers, local file servers, web proxy 1069 servers, recursive DNS servers, etc. The /etc/hosts file in UNIX, 1070 SSH known_hosts files, or the Microsoft Windows registry are just 1071 some examples of places where interesting information about such 1072 systems might be found. 1074 Additionally, system log files (including web server logs, etc.) may 1075 also prove a useful channel for an attacker. 1077 While the required credentials to access the aforementioned 1078 configuration and log files may limit the applicability of this 1079 technique, there are a number of scenarios in which this technique 1080 might be of use. For example, security audit tools might be provided 1081 with the necessary credentials such that these files can be 1082 automatically accessed. On the other hand, IPv6 worms could leverage 1083 this technique for the purpose of spreading on the local network, 1084 since they will typically have access to these files on an infected 1085 system [V6-WORMS]. 1087 10. Gleaning Information from Routing Protocols 1089 Some organizational IPv6 networks employ routing protocols to 1090 dynamically maintain routing information. In such an environment, a 1091 local attacker could become a passive listener of the routing 1092 protocol, to determine other valid subnets/prefixes and some router 1093 addresses within that organization [V6-WORMS]. 1095 11. Gleaning Information from IP Flow Information Export (IPFIX) 1097 IPFIX [RFC7012] can aggregate the flows by source addresses, and 1098 hence may be leveraged for obtaining a list of "active" IPv6 1099 addresses. Additional discussion of IPFIX can be found in 1100 Section 2.5.1.2 of [I-D.ietf-opsec-v6]. 1102 12. Obtaining Network Information with traceroute6 1104 IPv6 traceroute [traceroute6] can be employed to find router 1105 addresses and valid network prefixes. 1107 13. Gleaning Information from Network Devices Using SNMP 1109 SNMP can be leveraged to obtain information from a number of data 1110 structures such as the Neighbor Cache [RFC4861], the routing table, 1111 and the SAVI [RFC6620] cache of IPv6 and link-layer addresses. SNMP 1112 access should be secured, such that unauthorized access to the 1113 aforementioned information is prevented. 1115 14. Obtaining Network Information via Traffic Snooping 1117 Snooping network traffic can help in discovering active nodes in a 1118 number of ways. Firstly, each captured packet will reveal the source 1119 and destination of the packet. Secondly, the captured traffic may 1120 correspond to network protocols that transfer information such as 1121 host or router addresses, network topology information, etc. 1123 15. Conclusions 1125 In this document we have discussed issues around host-based scanning 1126 of IPv6 networks. We have shown why a /64 host subnet may be more 1127 vulnerable to address-based scanning that might intuitively be 1128 thought, and how an attacker might reduce the target search space 1129 when scanning. 1131 We have described a number of mitigations against host-based 1132 scanning, including the replacement of traditional SLAAC with stable 1133 semantically-opaque IIDs (which will require support from system 1134 vendors). We have also offered some practical guidance, around the 1135 principle of avoiding having predictability in host addressing 1136 schemes. Finally, examples of scanning approaches and tools are 1137 discussed in the Appendices. 1139 While most early IPv6-enabled networks remain dual-stack, they are 1140 more likely to be scanned and attacked over IPv4 transport, and one 1141 may argue that the IPv6-specific considerations discussed here are 1142 not of an immediate concern. However, an early IPv6 deployment 1143 within a dual-stack network may be seen by an attacker as a 1144 potentially "easier" target, if the implementation of security 1145 policies are not as strict for IPv6 (for whatever reason). As and 1146 when IPv6-only networks become more common, the considerations in 1147 this document will be of much greater importance. 1149 16. IANA Considerations 1151 There are no IANA registries within this document. The RFC-Editor 1152 can remove this section before publication of this document as an 1153 RFC. 1155 17. Security Considerations 1157 This document explores the topic of Network Reconnaissance in IPv6 1158 networks. It analyzes the feasibility of address-scan attacks in 1159 IPv6 networks, and showing that the search space for such attacks is 1160 typically much smaller than the one traditionally assumed (64 bits). 1161 Additionally, it explores a plethora of other network reconnaissance 1162 techniques, ranging from inspecting the IPv6 Network Cache of an 1163 attacker-controlled system, to gleaning information about IPv6 1164 addresses from public mailing-list archives or Peer-To-Peer (P2P) 1165 protocols. 1167 We expect traditional address-scanning attacks to become more and 1168 more elaborated (i.e., less "brute force"), and other network 1169 reconnaissance techniques to be actively explored, as global 1170 deployment of IPv6 increases and. more specifically, as more 1171 IPv6-only devices are deployed. 1173 18. Acknowledgements 1175 The authors would like to thank Ray Hunter, who provided valuable 1176 text that was readily incorporated into Section 3.2.1 of this 1177 document. 1179 The authors would like to thank (in alphabetical order) Alissa 1180 Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc Heuse, 1181 Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki 1182 Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke, for providing 1183 valuable comments on earlier versions of this document. 1185 Part of the contents of this document are based on the results of the 1186 project "Security Assessment of the Internet Protocol version 6 1187 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK 1188 Centre for the Protection of National Infrastructure (CPNI). 1190 19. References 1192 19.1. Normative References 1194 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1195 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1196 December 1998, . 1198 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1199 C., and M. Carney, "Dynamic Host Configuration Protocol 1200 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1201 2003, . 1203 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1204 SAVI: First-Come, First-Served Source Address Validation 1205 Improvement for Locally Assigned IPv6 Addresses", 1206 RFC 6620, DOI 10.17487/RFC6620, May 2012, 1207 . 1209 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1210 "Default Address Selection for Internet Protocol Version 6 1211 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1212 . 1214 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1215 Network Address Translations (NATs)", RFC 4380, 1216 DOI 10.17487/RFC4380, February 2006, 1217 . 1219 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1220 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1221 DOI 10.17487/RFC4861, September 2007, 1222 . 1224 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1225 Address Autoconfiguration", RFC 4862, 1226 DOI 10.17487/RFC4862, September 2007, 1227 . 1229 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1230 Extensions for Stateless Address Autoconfiguration in 1231 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1232 . 1234 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1235 for IP Flow Information Export (IPFIX)", RFC 7012, 1236 DOI 10.17487/RFC7012, September 2013, 1237 . 1239 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1240 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 1241 February 2014, . 1243 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1244 Interface Identifiers with IPv6 Stateless Address 1245 Autoconfiguration (SLAAC)", RFC 7217, 1246 DOI 10.17487/RFC7217, April 2014, 1247 . 1249 19.2. Informative References 1251 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1252 Multicast Name Resolution (LLMNR)", RFC 4795, 1253 DOI 10.17487/RFC4795, January 2007, 1254 . 1256 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1257 ICMPv6 Messages in Firewalls", RFC 4890, 1258 DOI 10.17487/RFC4890, May 2007, 1259 . 1261 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1262 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1263 . 1265 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1266 and C. Hahn, "IPv6 Unicast Address Assignment 1267 Considerations", RFC 5375, DOI 10.17487/RFC5375, December 1268 2008, . 1270 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1271 Neighbor Discovery Problems", RFC 6583, 1272 DOI 10.17487/RFC6583, March 2012, 1273 . 1275 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1276 DOI 10.17487/RFC6762, February 2013, 1277 . 1279 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1280 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1281 . 1283 [I-D.gont-6man-ipv6-smurf-amplifier] 1284 Gont, F. and W. Liu, "Security Implications of IPv6 1285 Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- 1286 amplifier-03 (work in progress), March 2013. 1288 [I-D.howard-isp-ip6rdns] 1289 Howard, L., "Reverse DNS in IPv6 for Internet Service 1290 Providers", draft-howard-isp-ip6rdns-08 (work in 1291 progress), May 2015. 1293 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 1294 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 1295 Boundary in IPv6 Addressing", RFC 7421, 1296 DOI 10.17487/RFC7421, January 2015, 1297 . 1299 [I-D.ietf-6man-default-iids] 1300 Gont, F., Cooper, A., Thaler, D., and S. LIU, 1301 "Recommendation on Stable IPv6 Interface Identifiers", 1302 draft-ietf-6man-default-iids-07 (work in progress), August 1303 2015. 1305 [I-D.ietf-6man-ipv6-address-generation-privacy] 1306 Cooper, A., Gont, F., and D. Thaler, "Privacy 1307 Considerations for IPv6 Address Generation Mechanisms", 1308 draft-ietf-6man-ipv6-address-generation-privacy-07 (work 1309 in progress), June 2015. 1311 [I-D.ietf-dhc-stable-privacy-addresses] 1312 Gont, F. and S. LIU, "A Method for Generating Semantically 1313 Opaque Interface Identifiers with Dynamic Host 1314 Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- 1315 stable-privacy-addresses-02 (work in progress), April 1316 2015. 1318 [I-D.ietf-opsec-v6] 1319 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 1320 Security Considerations for IPv6 Networks", draft-ietf- 1321 opsec-v6-06 (work in progress), March 2015. 1323 [CPNI-IPv6] 1324 Gont, F., "Security Assessment of the Internet Protocol 1325 version 6 (IPv6)", UK Centre for the Protection of 1326 National Infrastructure, (available on request). 1328 [V6-WORMS] 1329 Bellovin, S., Cheswick, B., and A. Keromytis, "Worm 1330 propagation strategies in an IPv6 Internet", ;login:, 1331 pages 70-76, February 2006, 1332 . 1334 [Malone2008] 1335 Malone, D., "Observations of IPv6 Addresses", Passive and 1336 Active Measurement Conference (PAM 2008, LNCS 4979), April 1337 2008, 1338 . 1340 [mdns-scan] 1341 Poettering, L., "mdns-scan(1) manual page", 2012, 1342 . 1345 [nmap2012] 1346 Fyodor, , "nmap - Network exploration tool and security / 1347 port scanner", 2012, . 1349 [VBox2011] 1350 VirtualBox, , "Oracle VM VirtualBox User Manual, version 1351 4.1.2", August 2011, . 1353 [vmesx2011] 1354 vmware, , "Setting a static MAC address for a virtual 1355 NIC", vmware Knowledge Base, August 2011, 1356 . 1359 [vSphere] vmware, , "vSphere Networking", 2014, 1360 . 1364 [traceroute6] 1365 FreeBSD, , "FreeBSD System Manager's Manual: 1366 traceroute6(8) manual page", 2009, 1367 . 1369 [Gont-DEEPSEC2011] 1370 Gont, F., "Results of a Security Assessment of the 1371 Internet Protocol version 6 (IPv6)", DEEPSEC 2011 1372 Conference, Vienna, Austria, November 2011, 2011, 1373 . 1376 [Gont-LACSEC2013] 1377 Gont, F., "IPv6 Network Reconnaissance: Theory & 1378 Practice", LACSEC 2013 Conference, Medellin, Colombia, 1379 May 2013, 2013, 1380 . 1383 [Ford2013] 1384 Ford, M., "IPv6 Address Analysis - Privacy In, Transition 1385 Out", 2013, . 1388 [THC-IPV6] 1389 "THC-IPV6", . 1391 [IPv6-Toolkit] 1392 "SI6 Networks' IPv6 Toolkit", 1393 . 1395 [BitTorrent] 1396 "BitTorrent", . 1398 [van-Dijk] 1399 van Dijk, P., "Finding v6 hosts by efficiently mapping 1400 ip6.arpa", 2012, . 1403 Appendix A. Implementation of a full-fledged IPv6 address-scanning tool 1405 This section describes the implementation of a full-fledged IPv6 1406 address scanning tool. Appendix A.1 discusses the selection of host 1407 probes. Appendix A.2 describes the implementation of an IPv6 address 1408 scanner for local area networks. Appendix A.3 outlines ongoing work 1409 on the implementation of a general (i.e., non-local) IPv6 host 1410 scanner. 1412 A.1. Host-probing considerations 1414 A number of factors should be considered when selecting the probe 1415 types and the probing-rate for an IPv6 address scanning tool. 1417 Firstly, some hosts (or border firewalls) might be configured to 1418 block or rate-limit some specific packet types. For example, it is 1419 usual for host and router implementations to rate-limit ICMPv6 error 1420 traffic. Additionally, some firewalls might be configured to block 1421 or rate-limit incoming ICMPv6 echo request packets (see e.g. 1422 [RFC4890]). 1424 As noted earlier in this document, Windows systems simply do not 1425 respond to ICMPv6 echo requests sent to multicast IPv6 addresses. 1427 Among the possible probe types are: 1429 o ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies), 1431 o TCP SYN segments (meant to elicit SYN/ACK or RST segments), 1433 o TCP segments that do not contain the ACK bit set (meant to elicit 1434 RST segments), 1436 o UDP datagrams (meant to elicit a UDP application response or an 1437 ICMPv6 Port Unreachable), 1439 o IPv6 packets containing any suitable payload and an unrecognized 1440 extension header (meant to elicit ICMPv6 Parameter Problem error 1441 messages), or, 1443 o IPv6 packets containing any suitable payload and an unrecognized 1444 option of type 10xxxxxx (such that a ICMPv6 Parameter Problem 1445 error message is elicited) 1447 Selecting an appropriate probe packet might help conceal the ongoing 1448 attack, but may also be actually necessary if host or network 1449 configuration causes certain probe packets to be dropped. In some 1450 cases, it might be desirable to insert some IPv6 extension headers 1451 before the actual payload, such that some filtering policies can be 1452 circumvented. 1454 Another factor to consider is the host-probing rate. Clearly, the 1455 higher the rate, the smaller the amount of time required to perform 1456 the attack. However, the probing-rate should not be too high, or 1457 else: 1459 1. the attack might cause network congestion, thus resulting in 1460 packet loss 1462 2. the attack might hit rate-limiting, thus resulting in packet loss 1464 3. the attack might reveal underlying problems in the Neighbor 1465 Discovery implementation, thus leading to packet loss and 1466 possibly even Denial of Service 1468 Packet-loss is undesirable, since it would mean that an "alive" node 1469 might remain undetected as a result of a lost probe or response. 1470 Such losses could be the result of congestion (in case the attacker 1471 is scanning a target network at a rate higher than the target network 1472 can handle), or may be the result of rate-limiting as it would be 1473 typically the case if ICMPv6 is employed for the probe packets. 1474 Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router 1475 implementations have been found to be unable to perform decent 1476 resource management when faced with Neighbor Discovery traffic 1477 involving a large number of local nodes. This essentially means that 1478 regardless of the type of probe packets, an address scanning attack 1479 might result in a Denial of Service (DoS) of the target network, with 1480 the same (or worse) effects as that of network congestion or rate- 1481 limiting. 1483 The specific rates at which each of these issues may come into play 1484 vary from one scenario to another, and depend on the type of deployed 1485 routers/firewalls, configuration parameters, etc. 1487 A.2. Implementation of an IPv6 local address-scanning tool 1489 scan6 [IPv6-Toolkit] is prototype IPv6 local address scanning tool, 1490 which has proven to be effective and efficient for the discovery of 1491 IPv6 hosts on a local network. 1493 The scan6 tool operates (roughly) as follows: 1495 1. The tool learns the local prefixes used for auto-configuration, 1496 an generates/configures one address for each local prefix (in 1497 addition to a link-local address). 1499 2. An ICMPv6 Echo Request message destined to the all-nodes on-link 1500 multicast address (ff02::1) is sent with each of the addresses 1501 "configured" in the previous step. Because of the different 1502 Source Addresses, each probe causes the victim nodes to use 1503 different Source Addresses for the response packets (this allows 1504 the tool to learn virtually all the addresses in use in the local 1505 network segment). 1507 3. The same procedure of the previous bullet is performed, but this 1508 time with ICMPv6 packets that contain an unrecognized option of 1509 type 10xxxxxx, such that ICMPv6 Parameter Problem error messages 1510 are elicited. This allows the tool to discover e.g. Windows 1511 nodes, which otherwise do not respond to multicasted ICMPv6 Echo 1512 Request messages. 1514 4. Each time a new "alive" address is discovered, the corresponding 1515 Interface-ID is combined with all the local prefixes, and the 1516 resulting addresses are probed (with unicasted packets). This 1517 can help to discover other addresses in use on the local network 1518 segment, since the same Interface ID is typically used with all 1519 the available prefixes for the local network. 1521 The aforementioned scheme can fail to discover some addresses for 1522 some implementation. For example, Mac OS X employs IPv6 addresses 1523 embedding IEEE-identifiers (rather than "temporary addresses") 1524 when responding to packets destined to a link-local multicast 1525 address, sourced from an on-link prefix. 1527 A.3. Implementation of a IPv6 remote address-scanning tool 1529 An IPv6 remote address scanning tool, could be implemented with the 1530 following features: 1532 o The tool can be instructed to target specific address ranges (e.g. 1533 2001:db8::0-10:0-1000) 1535 o The tool can be instructed to scan for SLAAC addresses of a 1536 specific vendor, such that only addresses embedding the 1537 corresponding IEEE OUIs are probed. 1539 o The tool can be instructed to scan for SLAAC addresses that employ 1540 a specific IEEE OUI. 1542 o The tool can be instructed to discover virtual machines, such that 1543 a given IPv6 prefix is only scanned for the address patterns 1544 resulting from virtual machines. 1546 o The tool can be instructed to scan for low-byte addresses. 1548 o The tool can be instructed to scan for wordy-addresses, in which 1549 case the tool selects addresses based on a local dictionary. 1551 o The tool can be instructed to scan for IPv6 addresses embedding 1552 TCP/UDP service ports, in which case the tool selects addresses 1553 based on a list of well-known service ports. 1555 o The tool can be specified an IPv4 address range in use at the 1556 target network, such that only IPv4-based IPv6 addresses are 1557 scanned. 1559 The scan6 tool of [IPv6-Toolkit] implements all these techniques/ 1560 features. 1562 Authors' Addresses 1564 Fernando Gont 1565 Huawei Technologies 1566 Evaristo Carriego 2644 1567 Haedo, Provincia de Buenos Aires 1706 1568 Argentina 1570 Phone: +54 11 4650 8472 1571 Email: fgont@si6networks.com 1572 URI: http://www.si6networks.com 1573 Tim Chown 1574 University of Southampton 1575 Highfield 1576 Southampton , Hampshire SO17 1BJ 1577 United Kingdom 1579 Email: tjc@ecs.soton.ac.uk