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