RFC 7707

Network Reconnaissance in IPv6 Networks

📅 published March 2016, from ietf

RFC 7707: Network Reconnaissance in IPv6 Networks 🌈

Okay bestie, let's get into RFC 7707, Network Reconnaissance in IPv6 Networks 🦋. It was written by F. Gont of Huawei Technologies and T. Chown of Jisc, and it's Informational, so it's published for info and not as a Standards Track spec 📚. It came out in March 2016 with ISSN 2070-1721. The big news is that it formally obsoletes RFC 5157 💅. It doesn't list anything it updates in its header.

Abstract ✨

IPv6 has a MASSIVE address space compared to IPv4 😭. In theory a /64 subnet can fit about 1.844 * 10^19 hosts, so the host density (#hosts/#addresses) is way lower than in IPv4 networks, where a site usually has 65,000 or fewer unique addresses. Because of that, everyone assumed it would take a ridiculous amount of effort to run address-scanning attacks against IPv6 networks, so those attacks were considered unfeasible 🙈. This document formally obsoletes RFC 5157, which first talked about that assumption. It digs into how traditional address-scanning techniques apply to IPv6 and explores some extra techniques you can use for IPv6 network reconnaissance 🔍.

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for informational purposes 📖.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🧐.

For the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc7707 🔗.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these documents carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🎀.

Table of Contents 🧚

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements for the Applicability of Network Reconnaissance
       Techniques  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Address Configuration in IPv6 . . . . . . . . . . . . . .   6
       4.1.1.  Stateless Address Autoconfiguration (SLAAC) . . . . .   6
       4.1.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)  11
       4.1.3.  Manually Configured Addresses . . . . . . . . . . . .  12
       4.1.4.  IPv6 Addresses Corresponding to
               Transition/Coexistence Technologies . . . . . . . . .  14
       4.1.5.  IPv6 Address Assignment in Real-World Network
               Scenarios . . . . . . . . . . . . . . . . . . . . . .  14
     4.2.  IPv6 Address Scanning of Remote Networks  . . . . . . . .  17
       4.2.1.  Reducing the Subnet ID Search Space . . . . . . . . .  18
     4.3.  IPv6 Address Scanning of Local Networks . . . . . . . . .  19
     4.4.  Existing IPv6 Address-Scanning Tools  . . . . . . . . . .  20
       4.4.1.  Remote IPv6 Network Address Scanners  . . . . . . . .  20
       4.4.2.  Local IPv6 Network Address Scanners . . . . . . . . .  21
     4.5.  Mitigations . . . . . . . . . . . . . . . . . . . . . . .  21
     4.6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . .  22
   5.  Alternative Methods to Glean IPv6 Addresses . . . . . . . . .  23
     5.1.  Leveraging the Domain Name System (DNS) for Network
           Reconnaissance  . . . . . . . . . . . . . . . . . . . . .  23
       5.1.1.  DNS Advertised Hosts  . . . . . . . . . . . . . . . .  23
       5.1.2.  DNS Zone Transfers  . . . . . . . . . . . . . . . . .  23
       5.1.3.  DNS Brute Forcing . . . . . . . . . . . . . . . . . .  23
       5.1.4.  DNS Reverse Mappings  . . . . . . . . . . . . . . . .  24
     5.2.  Leveraging Local Name Resolution and Service Discovery
           Services  . . . . . . . . . . . . . . . . . . . . . . . .  24
     5.3.  Public Archives . . . . . . . . . . . . . . . . . . . . .  25
     5.4.  Application Participation . . . . . . . . . . . . . . . .  25
     5.5.  Inspection of the IPv6 Neighbor Cache and Routing Table .  25
     5.6.  Inspection of System Configuration and Log Files  . . . .  26
     5.7.  Gleaning Information from Routing Protocols . . . . . . .  26
     5.8.  Gleaning Information from IP Flow Information Export
           (IPFIX) . . . . . . . . . . . . . . . . . . . . . . . . .  26
     5.9.  Obtaining Network Information with traceroute6  . . . . .  26
     5.10. Gleaning Information from Network Devices Using SNMP  . .  27
     5.11. Obtaining Network Information via Traffic Snooping  . . .  27
   6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  27
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  28
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  29
   Appendix A.  Implementation of a Full-Fledged IPv6 Address-
                Scanning Tool  . . . . . . . . . . . . . . . . . . .  34
     A.1.  Host-Probing Considerations . . . . . . . . . . . . . . .  34
     A.2.  Implementation of an IPv6 Local Address-Scanning Tool . .  35
     A.3.  Implementation of an IPv6 Remote Address-Scanning Tool  .  36
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

1. Introduction ✨

The main driver for IPv6 deployment is its larger address space, which is covered in [CPNI-IPv6]. That bigger space [RFC2460] doesn't just mean more connected devices. It also brings a bunch of subtle changes to how networks work 🌈. One of those changes is the reduced host density (the number of hosts divided by the number of addresses) of typical IPv6 subnetworks, compared to their IPv4 counterparts. [RFC5157] explains how this much lower IPv6 host density makes classic network address-scanning attacks less feasible, because even with various heuristics, the address space you'd need to scan is still HUGE 😵‍💫. RFC 5157 also describes some alternative ways attackers can glean active IPv6 addresses, and it gives some guidance for administrators and implementors, e.g., not using sequential addresses with DHCPv6 🛡️.

With more than five years of extra IPv6 deployment experience behind it, this document formally obsoletes RFC 5157 💖. It stresses that while address-scanning attacks are less feasible, they may still be possible with appropriate heuristics 👀. When RFC 5157 was written, observed address-scanning attacks were typically across ports on the addresses of discovered servers. Since then, evidence shows that some classic address scanning is happening too 😬. So this text updates the analysis on how feasible address-scanning attacks are in IPv6 networks, and it explores a number of additional techniques for IPv6 network reconnaissance. You'll also find practical examples and guidance in the appendices 🧁.

On one hand, raising awareness about IPv6 network reconnaissance techniques may let network and security administrators prevent or detect these attempts in some cases 🕵️‍♀️. On the other hand, network reconnaissance is essential for the so-called "penetration tests" that are typically run to assess the security of production networks 💪. That's why we think a thorough discussion of IPv6 network reconnaissance has two big benefits 🎀.

Section 4 analyzes how feasible address-scanning attacks (e.g., ping sweeps) are in IPv6 networks, and it explores a number of possible improvements to those techniques 🔥. Appendix A shows how that analysis can be used to build address-scanning tools (e.g., for penetration testing) 🛠️. Finally, the rest of this document covers a bunch of miscellaneous techniques that could be used for IPv6 network reconnaissance 🦋.

2. Conventions 🍓

Throughout this document, bits are numbered from left to right, starting at 0, and bytes are numbered from left to right, starting at 0 🔢.

3. Requirements for the Applicability of Network Reconnaissance Techniques 🕵️‍♀️

okay so throughout this doc we're talking about a bunch of network recon techniques, and bestie, each one asks for different stuff from the person doing it. like, do you need local access to the target network? do you need login access (or similar credentials) to the system where you run it? 👀 that's the whole vibe here.

the table below is basically your cheat sheet 📋 it sums up those requirements and doubles as a cross index to the matching sections 💅

+---------------------------------------------+----------+----------+
|                  Technique                  |  Local   |  Login   |
|                                             |  access  |  access  |
+---------------------------------------------+----------+----------+
|    Remote Address Scanning (Section 4.2)    |    No    |    No    |
+---------------------------------------------+----------+----------+
|     Local Address Scanning (Section 4.3)    |   Yes    |    No    |
+---------------------------------------------+----------+----------+
|     DNS Advertised Hosts (Section 5.1.1)    |    No    |    No    |
+---------------------------------------------+----------+----------+
|      DNS Zone Transfers (Section 5.1.2)     |    No    |    No    |
+---------------------------------------------+----------+----------+
|      DNS Brute Forcing (Section 5.1.3)      |    No    |    No    |
+---------------------------------------------+----------+----------+
|     DNS Reverse Mappings (Section 5.1.4)    |    No    |    No    |
+---------------------------------------------+----------+----------+
|     Leveraging Local Name Resolution and    |   Yes    |    No    |
|   Service Discovery Services (Section 5.2)  |          |          |
+---------------------------------------------+----------+----------+
|        Public Archives (Section 5.3)        |    No    |    No    |
+---------------------------------------------+----------+----------+
|   Application Participation (Section 5.4)   |    No    |    No    |
+---------------------------------------------+----------+----------+
|  Inspection of the IPv6 Neighbor Cache and  |    No    |   Yes    |
|         Routing Table (Section 5.5)         |          |          |
+---------------------------------------------+----------+----------+
|   Inspecting System Configuration and Log   |    No    |   Yes    |
|             Files (Section 5.6)             |          |          |
+---------------------------------------------+----------+----------+
| Gleaning Information from Routing Protocols |   Yes    |    No    |
|                (Section 5.7)                |          |          |
+---------------------------------------------+----------+----------+
|      Gleaning Information from IP Flow      |    No    |   Yes    |
|   Information Export (IPFIX) (Section 5.8)  |          |          |
+---------------------------------------------+----------+----------+
|      Obtaining Network Information with     |    No    |    No    |
|          traceroute6 (Section 5.9)          |          |          |
+---------------------------------------------+----------+----------+
|  Gleaning Information from Network Devices  |    No    |   Yes    |
|          Using SNMP (Section 5.10)          |          |          |
+---------------------------------------------+----------+----------+
|  Obtaining Network Information via Traffic  |   Yes    |    No    |
|           Snooping (Section 5.11)           |          |          |
+---------------------------------------------+----------+----------+

              Table 1: Requirements for the Applicability of
                     Network Reconnaissance Techniques

4. IPv6 Address Scanning 🦋

this section looks at how the classic address-scanning moves (think "ping sweeps" 🧹) apply to IPv6 networks. Section 4.1 is the essential breakdown of how addresses get configured in IPv6, and it spots patterns that can be used to shrink the IPv6 address search space when someone runs IPv6 address-scanning attacks. Section 4.2 covers scanning remote networks, Section 4.3 covers scanning local networks, and Section 4.4 goes over existing IPv6 address-scanning tools. Section 4.5 gives advice on how to mitigate IPv6 address-scanning attacks. Last but not least, Appendix A explains how the insights from the following subsections can be folded into a fully fledged IPv6 address-scanning tool ✨

4.1. Address Configuration in IPv6 🌸

IPv6 has two automatic address-configuration mechanisms: Stateless Address Autoconfiguration (SLAAC) [RFC4862] and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. SLAAC support is mandatory, while DHCPv6 support is optional. lowkey though, most current general-purpose operating systems support both 💜 Hosts (typically servers) may also use manual configuration, where the host or network administrator types all the necessary information into configuration files at the host itself 🛠️

The following subsections describe each of the possible configuration mechanisms/approaches in more detail.

4.1.1. Stateless Address Autoconfiguration (SLAAC) 🧚

the basic idea behind SLAAC is that every host joining a network sends a multicasted solicitation asking for network configuration info, and local routers reply with the info it needs 📡 SLAAC uses two ICMPv6 message types: ICMPv6 Router Solicitation and ICMPv6 Router Advertisement. hosts send Router Solicitation messages to ask local routers for configuration info, and local routers send Router Advertisement messages to share it.

Router Advertisement messages carry a whole pile of network configuration info, including the IPv6 prefix that should be used for configuring IPv6 addresses on the local network 🍓 for each local prefix learned from a Router Advertisement message, an IPv6 address is configured by appending a locally generated Interface Identifier (IID) to that prefix. it's giving building blocks 🧱

The following subsections describe currently deployed policies for generating the IIDs used with SLAAC.

4.1.1.1. Interface Identifiers Embedding IEEE Identifiers 🔥

the traditional SLAAC IIDs are based on the link-layer address of the network interface card. for Ethernet addresses, the IIDs get built like this:

  1. The "Universal" bit (bit 6, from left to right) of the address is set to 1.
  2. The word 0xfffe is inserted between the Organizationally Unique Identifier (OUI) and the rest of the Ethernet address.

For example, the Media Access Control (MAC) address 00:1b:38:83:88:3c leads to the IID 021b:38ff:fe83:883c 🎀

a few things to clock about these identifiers 👀 First, one 16-bit word (bytes 3-4) of the resulting address always has a fixed value (0xfffe), which shrinks the IID search space. Second, the high-order three bytes of the IID correspond to the OUI of the network interface card vendor. not every possible OUI has been assigned, so that narrows things down even more. Also, many of the assigned OUIs could be regarded as corresponding to legacy devices, so they're unlikely to show up on Internet-connected IPv6-enabled systems, which narrows it again 😭 And finally, in some scenarios it could be possible to infer the OUI used by the target network devices, which narrows the possible IIDs even further.

NOTE: For example, an organization known for being provisioned by vendor X is likely to have most of the nodes in its organizational network with OUIs corresponding to vendor X.

so these considerations mean that in some scenarios, the original 64-bit IID search space may be effectively reduced to 2^24 or n * 2^24 (where "n" is the number of different OUIs assigned to the target vendor) 🫶

also, if just one host address is detected or known within a subnet, it's not unlikely that, if systems were ordered in a batch, they may have sequential MAC addresses. and given a MAC address observed in one subnet, sequential or nearby MAC addresses may show up in other subnets in the same site 🦋

NOTE: [RFC7136] notes that all bits of an IID should be treated as "opaque" bits. Furthermore, [DEFAULT-IIDS] is currently in the process of changing the default IID generation scheme to align with [RFC7217] (as described below in Section 4.1.1.5), such that IIDs are semantically opaque and do not follow any patterns. Therefore, the traditional IIDs based on link-layer addresses are expected to become less common over time 💅

4.1.1.2. Interface Identifiers of Virtualization Technologies 💻

IIDs from virtualization technologies can be considered a specific subcase of IIDs embedding IEEE identifiers (please see Section 4.1.1.1). they use IEEE identifiers, but part of the IID has specific patterns. the following subsections describe the IIDs of some popular virtualization technologies.

4.1.1.2.1. VirtualBox 📦

all automatically generated MAC addresses in VirtualBox virtual machines use the OUI 08:00:27 [VBox2011]. this means all addresses resulting from traditional SLAAC will have an IID of the form a00:27ff:feXX:XXXX, which effectively reduces the IID search space from 64 bits to 24 bits 🙈

4.1.1.2.2. VMware ESX Server 🌈

the VMware ESX server (versions 1.0 to 2.5) is an even more interesting example 👑 automatically generated MAC addresses follow this pattern [vmesx2011]:

  1. The OUI is set to 00:05:69.
  2. The next 16 bits of the MAC address are set to the same value as the last 16 bits of the console operating system's primary IPv4 address.
  3. The final 8 bits of the MAC address are set to a hash value based on the name of the virtual machine's configuration file.

so, assuming the console operating system's primary IPv4 address is known, the IID search space is reduced from 64 bits to 8 bits 😱

on the other hand, manually configured MAC addresses in the VMware ESX server use the OUI 00:50:56, with the low-order three bytes of the MAC address in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware products). so even with manually configured MAC addresses, the IID search space is reduced from 64 bits to 22 bits and that's the tea 🫖💖

4.1.1.2.3. VMware vSphere 🌸

okay so VMware vSphere [vSphere] has these default MAC address generation algorithms 💅:

  • Generated addresses
    • Assigned by the vCenter server
    • Assigned by the ESXi host
  • Manually configured addresses

so by default, MAC addresses assigned by the vCenter server use the OUI 00:50:56 and look like 00:50:56:XX:YY:ZZ, where XX is calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)), and XX and YY are random two-digit hexadecimal numbers. that makes the possible IID range 00:50:56:80:00:00-00:50:56:BF:FF:FF, so the search space for the resulting SLAAC addresses is 22 bits 🙈

MAC addresses generated by the ESXi host use the OUI 00:0C:29 and look like 00:0C:29:XX:YY:ZZ. here XX, YY, and ZZ are the last three octets in hexadecimal format of the virtual machine Universally Unique Identifier (UUID) (based on a hash calculated with the UUID of the ESXi physical machine and the path to a configuration file) 🔥. so the MAC addresses land in the range 00:0C:29:00:00:00-00:0C:29:FF:FF:FF, and the search space for the resulting SLAAC addresses is 24 bits.

and finally, manually configured MAC addresses use the OUI 00:50:56, with the low-order three bytes in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware products) ✨. so the resulting MAC addresses are in the range 00:50:56:00:00:00-00:50:56:3F:FF:FF, and the search space for the corresponding SLAAC addresses is 22 bits.

4.1.1.3. Temporary Addresses 🦋

okay, privacy concerns [Gont-DEEPSEC2011] [RFC7721] about IIDs that embed IEEE identifiers led to "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941], also known as "temporary addresses" or "privacy addresses" 🧚. basically, "temporary addresses" make random addresses by attaching a random identifier to the autoconfiguration IPv6 prefix advertised in a Router Advertisement message.

NOTE: In addition to their unpredictability, these addresses are typically short-lived, such that even if an attacker were to learn of one of these addresses, they would be of use for a limited period of time. A typical implementation may keep a temporary address preferred for 24 hours, and configured but deprecated for seven days. 💀

it's important to know that "temporary addresses" are generated in addition to the stable addresses [RFC7721] (like the traditional SLAAC addresses based on IEEE identifiers) 🫶. stable SLAAC addresses are meant for "server-like" inbound communications, while "temporary addresses" are meant for "client-like" outbound communications. this means that using "temporary addresses" does not stop an attacker from taking advantage of the predictability of stable SLAAC addresses, since "temporary addresses" are added on top of the stable SLAAC addresses (like the ones derived from IEEE identifiers) rather than replacing them 😭.

the benefit of temporary addresses here is that they reduce how much of the host's addresses are exposed to third parties who might watch traffic from a host where temporary addresses are enabled and used by default. but, without firewall protection for the host, its stable SLAAC address is still open to being scanned from off-site 🙈.

4.1.1.4. Constant, Semantically Opaque IIDs 🎀

to fix the security problems that come with predictable IPv6 addresses derived from IEEE identifiers, Microsoft Windows came up with a different scheme for generating "stable addresses" (replacing the ones that embed IEEE identifiers) 💜. this scheme is believed to be an implementation of RFC 4941 [RFC4941], just without regenerating the addresses over time. the resulting IIDs stay constant across system bootstraps, and they also stay constant across networks.

assuming there are no flaws in that algorithm, this scheme would remove any patterns from the SLAAC addresses 🌈.

NOTE: however, since the resulting IIDs are constant across networks, these addresses may still be used for host-tracking purposes [RFC7217] [RFC7721]. 👀

so the benefit of this scheme is that a host may be harder to spot by applying heuristics to an address-scanning attack 🦋. but, unless temporary addresses are used at the same time, the host can still be tracked across the networks it visits.

4.1.1.5. Stable, Semantically Opaque IIDs ⭐

because of the predictability issues in Section 4.1.1.1 and the privacy issues in [RFC7721], the IETF standardized a method (in [RFC7217]) for generating IPv6 IIDs for use with IPv6 SLAAC 👑. addresses made this way are stable within each subnet, but the IIDs change when a host moves from one subnet to another. the idea is that you get the benefits of stable addresses without sacrificing user privacy 🫶.

using this method (instead of IIDs based on IEEE identifiers) gets rid of any patterns in the IID, which helps user privacy and makes addresses harder to scan 🔥.

4.1.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 💅

DHCPv6 can be used as a stateful address configuration mechanism, where a server (the DHCPv6 server) leases IPv6 addresses to IPv6 hosts 🌸. just like with its IPv4 counterpart, addresses are assigned according to a configuration-defined address range and policy, and some DHCPv6 servers assign addresses sequentially from a specific range. when that happens, addresses tend to be predictable 🙈.

NOTE: For example, if the prefix 2001:db8::/64 is used for assigning addresses on the local network, the DHCPv6 server might (sequentially) assign addresses from the range 2001:db8::1 - 2001:db8::100. 🧚

in most common scenarios, this means the IID search space shrinks from the original 64 bits to 8 or 16 bits 😭. [RFC5157] recommended that DHCPv6 instead issue addresses randomly from a large pool, and that advice is repeated here 🌈. [IIDS-DHCPv6] specifies an algorithm that DHCPv6 servers can use to produce stable addresses that don't follow any specific pattern, which gives an IID search space of 64 bits 👑.

4.1.3. Manually Configured Addresses 🍓

sometimes node addresses are configured by hand 🛠️. this is typically the case for IPv6 addresses assigned to routers (since routers don't use automatic address configuration), and also for servers (since a stable address that doesn't depend on the underlying link-layer address is usually really nice to have) 💖.

while network admins are mostly free to pick the IID from any value in the range 1 - 2^64, for the sake of simplicity (aka ease of remembering) they tend to go with one of these patterns ✨:

  • low-byte addresses: in which most of the bytes of the IID are set to 0 (except for the least significant byte)
  • IPv4-based addresses: in which the IID embeds the IPv4 address of the network interface (as in 2001:db8::192.0.2.1)
  • service port addresses: in which the IID embeds the TCP/UDP service port of the main service running on that node (as in 2001:db8::80 or 2001:db8::25)
  • wordy addresses: which encode words (as in 2001:db8::bad:cafe)

each of these patterns gets a closer look in the following subsections 🔍.

4.1.3.1. Low-Byte Addresses 🌷

the most common form of low-byte addresses is the one where all the bytes of the IID (except the least significant bytes) are set to zero (as in 2001:db8::1, 2001:db8::2, etc.). but it's also common to find similar addresses where the two lowest-order 16-bit words (from right to left) are set to small numbers (as in 2001::db8::1:10, 2001:db8::2:10, etc.) 💕. and it's not unusual to find IPv6 addresses where the second lowest-order 16-bit word (from right to left) is set to a small value in the range 0x0000:0x00ff, while the lowest-order 16-bit word (from right to left) varies across 0x0000:0xffff. 😤 it's worth noting that all of these address patterns are generally called "low-byte addresses," even when, strictly speaking, it's not only the lowest-order byte of the IPv6 address that changes from one address to another.

in the worst-case scenario, the search space for this pattern is 2^24 (although most systems can be found by searching 2^16 or even 2^8 addresses) 🧠.

4.1.3.2. IPv4-Based Addresses 🌍

the most common form of these addresses is the one where an IPv4 address is encoded in the lowest-order 32 bits of the IPv6 address (usually as a result of notation like 2001:db8::192.0.2.1). but admins also often encode each byte of the IPv4 address into each of the 16-bit words of the IID (as in, e.g., 2001:db8::192:0:2:1) 🎀.

so the search space for addresses following this pattern is that of the corresponding IPv4 prefix (or twice that size if both forms of "IPv4-based addresses" are being searched) 🦋.

4.1.3.3. Service-Port Addresses 🔌

addresses following this pattern include the service port (e.g., 80 for HTTP) in the lowest-order byte of the IID, and the rest of the bytes of the IID are set to zero 🫧. there are a few variants of this pattern:

  • The lowest-order 16-bit word (from right to left) may contain the service port, and the second lowest-order 16-bit word (from right to left) may be set to a number in the range 0x0000-0x00ff (as in, e.g., 2001:db8::1:80).
  • The lowest-order 16-bit word (from right to left) may be set to a value in the range 0x0000-0x00ff, while the second lowest-order 16-bit word (from right to left) may contain the service port (as in, e.g., 2001:db8::80:1).
  • The service port itself might be encoded in decimal or in hexadecimal notation (e.g., an address embedding the HTTP port might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding the service port as a decimal number being more common 🍭.

considering a maximum of 20 popular service ports, the search space for addresses following this pattern is, in the worst-case scenario, 10 * 2^11 💫.

4.1.3.4. Wordy Addresses 📖

since the IPv6 address notation allows a bunch of hexadecimal digits, it's not hard to encode words into IPv6 addresses (as in, e.g., 2001:db8::bad:cafe) 🍪.

addresses following this pattern are likely to be explored with "dictionary attacks," so figuring out the corresponding search space isn't straightforward 🕵️‍♀️.

4.1.4. IPv6 Addresses Corresponding to Transition/Coexistence Technologies 🦋

some transition/coexistence technologies might be used to shrink the target search space of remote address-scanning attacks, since they spell out exactly how the matching IPv6 address has to be generated 🧩. for example, with Teredo [RFC4380], the 64-bit IID is generated from the IPv4 address observed at a Teredo server, along with a UDP port number 🌐.

for obvious reasons, the search space for these addresses depends on which specific transition/coexistence technology is being used ✨.

tbh this is where the interface-ID rabbit hole gets really wild 🌌

4.1.5. IPv6 Address Assignment in Real-World Network Scenarios ✨

okay bestie, so Figures 1, 2, and 3 are the receipts from [Gont-LACSEC2013] on the address patterns used by web servers, name servers, and mail servers. Figure 4 is the rough router tea from [Malone2008], and Figure 5 is the client glow-up from [Ford2013]. 💅

                      +---------------+------------+
                      |  Address type | Percentage |
                      +---------------+------------+
                      |   IEEE-based  |    1.44%   |
                      +---------------+------------+
                      | Embedded-IPv4 |   25.41%   |
                      +---------------+------------+
                      | Embedded-Port |    3.06%   |
                      +---------------+------------+
                      |     ISATAP    |    0.00%   |
                      +---------------+------------+
                      |    Low-byte   |   56.88%   |
                      +---------------+------------+
                      |  Byte-pattern |    6.97%   |
                      +---------------+------------+
                      |   Randomized  |    6.24%   |
                      +---------------+------------+

Figure 1: Measured Web Server Addresses 🌸

                      +---------------+------------+
                      |  Address type | Percentage |
                      +---------------+------------+
                      |   IEEE-based  |    0.67%   |
                      +---------------+------------+
                      | Embedded-IPv4 |   22.11%   |
                      +---------------+------------+
                      | Embedded-Port |    6.48%   |
                      +---------------+------------+
                      |     ISATAP    |    0.00%   |
                      +---------------+------------+
                      |    Low-byte   |   56.58%   |
                      +---------------+------------+
                      |  Byte-pattern |   11.07%   |
                      +---------------+------------+
                      |   Randomized  |    3.09%   |
                      +---------------+------------+

Figure 2: Measured Name Server Addresses 🌸

                      +---------------+------------+
                      |  Address type | Percentage |
                      +---------------+------------+
                      |   IEEE-based  |    0.48%   |
                      +---------------+------------+
                      | Embedded-IPv4 |    4.02%   |
                      +---------------+------------+
                      | Embedded-Port |    1.07%   |
                      +---------------+------------+
                      |     ISATAP    |    0.00%   |
                      +---------------+------------+
                      |    Low-byte   |   92.65%   |
                      +---------------+------------+
                      |  Byte-pattern |    1.20%   |
                      +---------------+------------+
                      |   Randomized  |    0.59%   |
                      +---------------+------------+

Figure 3: Measured Mail Server Addresses 🌸

                       +--------------+------------+
                       | Address type | Percentage |
                       +--------------+------------+
                       |   Low-byte   |   70.00%   |
                       +--------------+------------+
                       |  IPv4-based  |    5.00%   |
                       +--------------+------------+
                       |    SLAAC     |    1.00%   |
                       +--------------+------------+
                       |    Wordy     |   <1.00%   |
                       +--------------+------------+
                       |  Randomized  |   <1.00%   |
                       +--------------+------------+
                       |    Teredo    |   <1.00%   |
                       +--------------+------------+
                       |    Other     |   <1.00%   |
                       +--------------+------------+

Figure 4: Measured Router Addresses 🌸

                    +---------------+------------+
                    |  Address type | Percentage |
                    +---------------+------------+
                    |   IEEE-based  |    7.72%   |
                    +---------------+------------+
                    | Embedded-IPv4 |   14.31%   |
                    +---------------+------------+
                    | Embedded-Port |    0.21%   |
                    +---------------+------------+
                    |     ISATAP    |    1.06%   |
                    +---------------+------------+
                    |   Randomized  |   69.73%   |
                    +---------------+------------+
                    |    Low-byte   |    6.23%   |
                    +---------------+------------+
                    |  Byte-pattern |    0.74%   |
                    +---------------+------------+

Figure 5: Measured Client Addresses 🌸

NOTE: "ISATAP" stands for "Intra-Site Automatic Tunnel Addressing Protocol" [RFC5214]. 🦋

Honestly, the numbers make it super clear that a very high percentage of host and router addresses follow really specific patterns. It's giving predictable. 🔥

Figure 5 shows that around 70% of the clients in this measurement seem to be using temporary addresses. Still, a significant number of clients are exposing IEEE-based addresses and addresses with embedded IPv4 (which also reveal IPv4 addresses), so not everyone is hiding. 🙈 Also, as noted in Section 4.1.1.3, temporary addresses get used alongside stable IPv6 addresses. That means a host using a temporary address can still be the target of address-scanning attacks aimed at its stable address(es). Not me getting caught off guard by that. 😭

[ADDR-ANALYSIS] has a spatial and temporal analysis of IPv6 addresses for clients and routers, if you want to go deeper. 🧚

4.2. IPv6 Address Scanning of Remote Networks ✨

Attackers have gotten away with "brute-force" address-scanning attacks in IPv4 networks, thanks to the much smaller search space. But successfully brute-forcing an entire /64 network would be infeasible. So it's expected that attackers will lean on the IPv6 address patterns from Section 4.1 to shrink the IPv6 address search space. Main character planning, honestly. 👑

Scanning remote IPv6 networks has to think about one extra factor that IPv4 doesn't have. Since the typical IPv6 subnet is a /64, scanning an entire /64 could, in theory, lead to the creation of 2^64 entries in the Neighbor Cache of the last-hop router. Yikes. 💀 A number of IPv6 implementations have been found to be unable to handle a large number of Neighbor Cache entries properly, so these address-scanning attacks may end up causing a Denial-of-Service (DoS) attack as a side effect [CPNI-IPv6] [RFC6583].

[RFC7421] talks about the "default" /64 boundary for host subnets and the assumptions around it. There are reports of sites using IPv6 subnets of size /112 or smaller to ease worries about the attack above. But smaller subnets are likely to make address-scanning attacks more feasible, on top of running into the issues with non-/64 host subnets discussed in [RFC7421]. Smaller isn't always slay. 🙅‍♀️

4.2.1. Reducing the Subnet ID Search Space

When you're address scanning a remote network, you have to choose which subnet IDs to target. A typical site might have a /48 allocation, which would mean up to 65,000 or so IPv6 /64 subnets to scan. That's a lot of bestie, so let's narrow it down. 🌈

The same way the search space for the IID can be reduced, the subnet ID search space can also be reduced in a few ways: by guessing likely address plan schemes, or by using any complementary clues from other sources or observations. For example, there are plenty of documents online (e.g., [RFC5375]) that give recommendations for allocating address space. Those cover operational stuff like Regional Internet Registry (RIR) assignment policy, being able to delegate reverse DNS zones to different servers, aggregating routes efficiently, preserving address space, delegating address assignment inside the organization, adding or allocating new sites/prefixes to existing entities without updating Access Control Lists (ACLs), and de-aggregating and advertising subspaces through various Autonomous System (AS) interfaces. So many considerations, so many clues. 🧠

Address plans might use subnets that:

  • Run from low ID upwards, e.g., 2001:db8:0::/64, 2001:db8:1::/64, etc.
  • Use building numbers, in hexadecimal or decimal form.
  • Use Virtual Local Area Network (VLAN) numbers.
  • Use an IPv4 subnet number in a dual-stack target. For example, a site with a /16 for IPv4 might use /24 subnets, and the IPv6 address plan may reuse the third byte of the IPv4 address as the IPv6 subnet ID. Clever, right? 🎀
  • Use the service "color", as defined for service-based prefix coloring, or semantic prefixes. For example, a site with a specific coloring for a specific service such as Voice over IP (VoIP) may reduce the subnet ID search space for those devices. 🎧

The net effect is that an organization's address space may be super structured, and allocations of individual elements inside that structure may be predictable once other elements are known. It's like finding the group chat's pattern. 💜

In general, any subnet ID address plan may convey information, or be based on known information, and that can totally be an advantage for an attacker. Plans are tea, and attackers love tea. ☕

4.3. IPv6 Address Scanning of Local Networks

IPv6 address scanning in Local Area Networks (LANs) could be considered, to some extent, a completely different problem from scanning a remote IPv6 network. The big difference is that link-local multicast addresses can spare the attacker from searching a huge IPv6 address space for unicast addresses. Multicast does the heavy lifting. 📣

NOTE: Other network reconnaissance vectors (such as network snooping, leveraging Neighbor Discovery traffic, etc.) are available when scanning a local network. This section only focuses on address-scanning attacks (a la "ping sweep"). 🙃

An attacker can just send probe packets to the all-nodes link-local multicast address (ff02::1), so responses come back from all the local nodes. Easy peasy. 🍓

Windows systems (Vista, 7, etc.) don't respond to ICMPv6 Echo Request messages sent to multicast addresses, so IPv6 address-scanning tools usually send a bunch of additional probe packets to get responses from all the local nodes. For example, unrecognized IPv6 options of type 10xxxxxx trigger Internet Control Message Protocol version 6 (ICMPv6) Parameter Problem, code 2, error messages. Sneaky. 🕵️‍♀️

Lots of address-scanning tools only discover IPv6 link-local addresses, rather than, e.g., the global addresses of the target systems. The probe packets are typically sent from the attacker's IPv6 link-local address, so the "victim" nodes reply using the IPv6 link-local address of the matching network interface (as picked by the IPv6 address-selection rules [RFC6724]). The fix? Sending multiple probe packets, with each packet using source addresses from different prefixes, usually helps get past that limit. 🦋

4.4. Existing IPv6 Address-Scanning Tools ✨

4.4.1. Remote IPv6 Network Address Scanners ✨

okay so IPv4 address-scanning tools have traditionally just probed the whole address range, usually the entire target subnet 💅 one could argue they got away with such "rudimentary" moves because the task is so small in IPv4 that brute force is "good enough" 🙄 but the scale of the address-scanning task is SO big in IPv6 that attackers have to be extremely creative to be "good enough" 🧚 literally, sweeping an entire /64 IPv6 subnet would just not be feasible 💀

many address-scanning tools don't even support sweeping an IPv6 address range 😬 the alive6 tool from [THC-IPV6] does support sweeping ranges, so it can leverage some patterns found in IPv6 addresses, like the incremental addresses that come out of some DHCPv6 setups 🍓 and the scan6 tool from [IPv6-Toolkit] supports sweeping ranges too, and it can also leverage all the address patterns described in Section 4.1 of this document 🔥

the vibe check here is that a big limitation of lots of current IPv6 scanning tools is that they lack a properly tuned "heuristics engine" to shrink the search space, so that the problem of IPv6 address scanning actually becomes tractable 🌸

it should be noted that IPv6 network monitoring and management tools also need to build and maintain info about the hosts in their network 🫶 those systems can no longer scan internal systems in a reasonable time to build a database of connected systems 😭 so they'll need more efficient approaches, e.g., polling network devices for data they hold about observed IP addresses, MAC addresses, physical ports used, etc. ✨ this approach can also enhance address accountability by mapping IPv4 and IPv6 addresses to observed MAC addresses 🔍 and of course this means any access control mechanisms for querying those network devices, e.g., community strings for SNMP, should be set appropriately so an attacker can't gather address info remotely 🔒

4.4.2. Local IPv6 Network Address Scanners 🏠

there are a bunch of publicly available local IPv6 network address scanners, bestie 🧚

  • Current versions of nmap [nmap2015] implement this functionality.
  • The Hacker's Choice (THC) IPv6 Attack Toolkit [THC-IPV6] includes a tool (alive6) that implements this functionality.
  • SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) that implements this functionality.

4.5. Mitigations 🛡️

IPv6 address-scanning attacks can be mitigated in a bunch of ways 💖 here's a non-exhaustive list of the possible mitigations:

  • Employing [RFC7217] (stable, semantically opaque IIDs) in replacement of addresses based on IEEE identifiers, so that any address patterns are eliminated ✨
  • Employing Intrusion Prevention Systems (IPSs) at the perimeter 🧱
  • Enforcing IPv6 packet filtering where applicable (see, e.g., [RFC4890]) 🚧
  • Employing manually configured MAC addresses if virtual machines are employed and "resistance" to address-scanning attacks is deemed desirable, so that even if the virtual machines use IEEE-derived IIDs, those IIDs are generated from non-predictable MAC addresses 🤖
  • Avoiding use of sequential addresses when using DHCPv6 💅 ideally, the DHCPv6 server would allocate random addresses from a large pool (see, e.g., [IIDS-DHCPv6]) 🎲
  • Using the "default" /64 size IPv6 subnet prefixes 🌈
  • In general, avoiding being predictable in the way addresses are assigned 🦋

some of these mitigations are operational, while others depend on the availability of specific protocol features (such as [RFC7217]) on the corresponding nodes 🧚

also, while some resistance to address-scanning attacks is generally desirable (especially when lightweight mitigations are available), there are scenarios where mitigating some address-scanning vectors is unlikely to be a high priority (if it's possible at all) 🙈 and one should always remember that security by obscurity is not a reasonable defense in itself 😤 it may only be one (relatively small) layer in a broader security environment 🌸

Two of the techniques discussed in this document for local address-scanning attacks are those that employ multicasted ICMPv6 Echo Requests and multicasted IPv6 packets containing unsupported options of type 10xxxxxx. These two vectors could be easily mitigated by configuring nodes to not respond to multicasted ICMPv6 Echo Requests (the default on Windows systems), and by updating the IPv6 specifications (and/or possibly configuring local nodes) so that multicasted packets never elicit ICMPv6 error messages (even if they contain unsupported options of type 10xxxxxx).

NOTE: [SMURF-AMPLIFIER] proposed such an update to the IPv6 specifications. 👀

in any case, when it comes to local networks, there are a variety of network reconnaissance vectors 😩 so even if address-scanning vectors were mitigated, an attacker could still rely on, e.g., protocols used for the so-called "service discovery protocols" (see Section 5.2), or eventually fall back on network snooping as a last resort 🕵️‍♀️ there's ongoing IETF work on extending mDNS, or at least DNS-based service discovery, to work across a whole site rather than just a single subnet, and that will have associated security implications ⚠️

4.6. Conclusions 🎀

in the previous subsections we showed why a /64 host subnet may be more vulnerable to address-based scanning than you'd intuitively think 🤯 and how an attacker might reduce the target search space when performing an address-scanning attack 🧠

we described a bunch of mitigations against address-scanning attacks, including replacing traditional SLAAC with stable semantically opaque IIDs (which requires support from system vendors) 💜 we also offered some practical guidance on the principle of avoiding predictability in host addressing schemes 🌟 and finally, examples of address-scanning approaches and tools are discussed in the appendices 📚

while most early IPv6-enabled networks remain dual stack, they're more likely to be scanned and attacked over IPv4 transport 😮 one could argue the IPv6-specific considerations here aren't of immediate concern 🙃 but an early IPv6 deployment inside a dual-stack network may look like an "easier" target to an attacker if security policies aren't as strict for IPv6 (for whatever reason) 🎯 as IPv6-only networks become more common, these considerations will matter a LOT more 🔥💅

5. Alternative Methods to Glean IPv6 Addresses 🕵️‍♀️

the following subsections describe alternative methods an attacker might use to glean IPv6 addresses for later probing 👀

5.1. Leveraging the Domain Name System (DNS) for Network Reconnaissance 🌐

5.1.1. DNS Advertised Hosts 📣

any systems that are "published" in the DNS, e.g., Mail Exchange (MX) relays or web servers, will stay open to probing just because their IPv6 addresses are publicly available 😬 it's worth noting that where the addresses used at a site follow specific patterns, publishing just one address may lead to an attack on the other nodes 🍓

also, publishing IPv6 addresses in the DNS shouldn't discourage getting rid of IPv6 address patterns 💡 if any address patterns are eliminated from addresses published in the DNS, an attacker may have to rely on dictionary-based DNS lookups to find all the systems in a target network 🙈 (which is generally less reliable and more time- and traffic-consuming than mapping nodes with predictable IPv6 addresses 😌)

5.1.2. DNS Zone Transfers 🗂️

a DNS zone transfer (DNS query type "AXFR") [RFC1034] [RFC1035] can readily hand over info about potential attack targets 😱 restricting zone transfers is thus probably more important for IPv6, even though it's already good practice to restrict them in the IPv4 world 🔒

5.1.3. DNS Brute Forcing 🔨

attackers may use DNS brute-forcing techniques by testing for the presence of DNS AAAA records against commonly used host names 🫣

5.1.4. DNS Reverse Mappings 🔄

[van-Dijk] describes an interesting technique that uses DNS reverse mappings for network reconnaissance ✨ basically, the attacker walks through the "ip6.arpa" zone looking up PTR records, hoping to learn the IPv6 addresses of hosts in a given target network (assuming the reverse mappings have been configured, of course) 🧩 what's most interesting here is that it can greatly reduce the IPv6 address search space 🤯

so an attacker would walk the ip6.arpa zone corresponding to a target network (e.g., 0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa. for 2001:db8:80::/48), issuing queries for PTR records corresponding to the domain names 0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa., 1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa., and so on 🎀 if, say, there were PTR records for any hosts "starting" with the domain name 0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa. (e.g., the ip6.arpa domain name for the IPv6 address 2001:db8:80::1), the response would contain an RCODE of 0 (no error) 🌟 otherwise, the response would contain an RCODE of 4 (NXDOMAIN) ❌ as noted in [van-Dijk], this technique allows for a tremendous reduction in the "IPv6 address" search space 🚀

NOTE: Some name servers, incorrectly implementing the DNS protocol, reply NXDOMAIN instead of NODATA (NOERROR=0 and ANSWER=0) when encountering a domain without any resource records but that has child domains. This is very common in ip6.arpa (these domains are called ENT for Empty Non-Terminals; see [RFC7719]). When scanning ip6.arpa, this behavior may slow down or completely prevent exploration of ip6.arpa. Nevertheless, since such behavior is wrong (see [NXDOMAIN-DEF]), one cannot rely on it to "secure" ip6.arpa against tree walking 🙅‍♀️ [IPv6-RDNS] analyzes different approaches and considerations for ISPs managing the ip6.arpa zone for IPv6 address space assigned to many customers, which may affect the technique described in this section 🧐

5.2. Leveraging Local Name Resolution and Service Discovery Services 📡

a bunch of protocols allow for unmanaged local name resolution and service discovery 🏘️ for example, mDNS [RFC6762] and DNS Service Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution (LLMNR) [RFC4795], are examples of such protocols 🦋

NOTE: Besides the Graphical User Interfaces (GUIs) included in products supporting such protocols, command-line tools such as mdns-scan [mdns-scan] and mzclient [mzclient] can help discover IPv6 hosts using mDNS/DNS-SD 🛠️

5.3. Public Archives 📬

public mailing-list archives or Usenet news message archives may be a super useful channel for an attacker 👀 since hostnames and/or IPv6 addresses could be easily obtained by inspecting the (many) "Received from:" or other header lines in archived email or Usenet news messages 💀

5.4. Application Participation 🎈

okay so peer-to-peer apps usually have some centralized server that coordinates the transfer of data between peers, bestie 🫶 For example, BitTorrent [BitTorrent] builds swarms of nodes that swap chunks of files, while a tracker passes info about which peers have which chunks. ngl, that means these apps can hand an attacker a source of peer addresses to probe 👀

5.5. Inspection of the IPv6 Neighbor Cache and Routing Table 🗺️

Info about other systems on the local network might be readily available from the Neighbor Cache [RFC4861] and/or the routing table of any system connected to that network. Source Address Validation Improvement (SAVI) [RFC6620] also builds a cache of IPv6 and link-layer addresses (without actively taking part in the Neighbor Discovery packet exchange), so it's another source of similar info 💅

These data structures could be inspected via either "login" access or SNMP. Yes, this requirement may limit how useful the technique is, but there are still plenty of scenarios where it's giving real value 🙈 For example, security audit tools might be given the necessary credentials, so the Neighbor Cache and routing table of every system the tool has "login" or SNMP access to can be gleaned automatically. On the other hand, IPv6 worms [V6-WORMS] could use this technique to spread across the local network, since they'll typically have access to the Neighbor Cache and routing table of an infected system. Not me getting chills 💀

Section 2.5.1.4 of [OPSEC-IPv6] discusses additional considerations for the inspection of the IPv6 Neighbor Cache 📚

5.6. Inspection of System Configuration and Log Files 📁

Nodes are generally configured with the addresses of other important local computers, like email servers, local file servers, web proxy servers, recursive DNS servers, and so on 🧚 The /etc/hosts file on UNIX-like systems, Secure Shell (SSH) known_hosts files, and the Microsoft Windows registry are just a few places where juicy info about those systems might be hiding 👑

System log files (including web server logs, etc.) can also be a super useful source for an attacker 🍓

Yes, the credentials needed to get at these configuration and log files may limit how often this works, but there are still a bunch of scenarios where it's relevant. For example, security audit tools might be given the necessary credentials so these files can be accessed automatically. On the other hand, IPv6 worms could use this technique to spread across the local network, since they'll typically have access to these files on an infected system [V6-WORMS] 😭

5.7. Gleaning Information from Routing Protocols 🛰️

Some organizational IPv6 networks use routing protocols to dynamically maintain routing information. In that kind of environment, a local attacker could just sit back as a passive listener on the routing protocol and figure out other valid subnets/prefixes and some router addresses inside that organization [V6-WORMS] 🦋

5.8. Gleaning Information from IP Flow Information Export (IPFIX) 🌊

IPFIX [RFC7012] can aggregate flows by source address, so it may be leveraged to get a list of "active" IPv6 addresses ✨ More discussion of IPFIX can be found in Section 2.5.1.2 of [OPSEC-IPv6].

5.9. Obtaining Network Information with traceroute6 🛤️

IPv6 traceroute [traceroute6] and similar tools (such as path6 from [IPv6-Toolkit]) can be used to find router addresses and valid network prefixes 🧭

5.10. Gleaning Information from Network Devices Using SNMP 📡

SNMP can be leveraged to pull info from a bunch of data structures, like the Neighbor Cache [RFC4861], the routing table, and the SAVI [RFC6620] cache of IPv6 and link-layer addresses 💜 SNMP access should be secured, so that unauthorized access to all that info is prevented. Lock it down, babe 🔒

5.11. Obtaining Network Information via Traffic Snooping 👂

Snooping network traffic can help discover active nodes in a few different ways 🕵️‍♀️ Firstly, every captured packet reveals the source and destination of that packet. Secondly, the captured traffic may correspond to network protocols that transfer info like host or router addresses, network topology information, and more 🌈

6. Conclusions 👑

This document explores the topic of network reconnaissance in IPv6 networks. It analyzes how feasible address-scanning attacks are in IPv6 networks and shows that the search space for such attacks is typically much smaller than the one traditionally assumed (64 bits) 🔥

On top of that, this document explores a plethora of other network reconnaissance techniques, ranging from inspecting the IPv6 Network Cache of an attacker-controlled system to gleaning info about IPv6 addresses from public mailing-list archives or Peer-to-Peer (P2P) protocols 🧚

We expect traditional address-scanning attacks to become more and more elaborated (i.e., less "brute force"), and other network reconnaissance techniques to be actively explored, as global deployment of IPv6 increases and, more specifically, as more IPv6-only devices are deployed. It's giving main character era for IPv6 🦋✨

7. Security Considerations 🚨

This document reviews methods by which addresses of hosts within IPv6 subnets can be determined. As such, it raises no new security concerns. Serious, but honestly reassuring 🫶

8. References 📚

8.1. Normative References

[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
           <http://www.rfc-editor.org/info/rfc1034>.

[RFC1035]  Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
           November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
           December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
           C., and M. Carney, "Dynamic Host Configuration Protocol
           for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
           2003, <http://www.rfc-editor.org/info/rfc3315>.

[RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
           Network Address Translations (NATs)", RFC 4380,
           DOI 10.17487/RFC4380, February 2006,
           <http://www.rfc-editor.org/info/rfc4380>.

[RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
           "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
           DOI 10.17487/RFC4861, September 2007,
           <http://www.rfc-editor.org/info/rfc4861>.

[RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
           Address Autoconfiguration", RFC 4862,
           DOI 10.17487/RFC4862, September 2007,
           <http://www.rfc-editor.org/info/rfc4862>.

[RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
           Extensions for Stateless Address Autoconfiguration in
           IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
           <http://www.rfc-editor.org/info/rfc4941>.

[RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
           Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
           DOI 10.17487/RFC5214, March 2008,
           <http://www.rfc-editor.org/info/rfc5214>.

[RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
           SAVI: First-Come, First-Served Source Address Validation
           Improvement for Locally Assigned IPv6 Addresses",
           RFC 6620, DOI 10.17487/RFC6620, May 2012,
           <http://www.rfc-editor.org/info/rfc6620>.

[RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
           "Default Address Selection for Internet Protocol Version 6
           (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
           <http://www.rfc-editor.org/info/rfc6724>.

[RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
           for IP Flow Information Export (IPFIX)", RFC 7012,
           DOI 10.17487/RFC7012, September 2013,
           <http://www.rfc-editor.org/info/rfc7012>.

[RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
           Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
           February 2014, <http://www.rfc-editor.org/info/rfc7136>.

[RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
           Interface Identifiers with IPv6 Stateless Address
           Autoconfiguration (SLAAC)", RFC 7217,
           DOI 10.17487/RFC7217, April 2014,
           <http://www.rfc-editor.org/info/rfc7217>.

8.2. Informative References ✨

okay so this is the big ol' reading list 📚🎀 these are the extra sources the spec points at without making them mandatory, and they're giving "receipts everywhere" energy 💅

[ADDR-ANALYSIS]
           Plonka, D. and A. Berger, "Temporal and Spatial
           Classification of Active IPv6 Addresses", ACM Internet
           Measurement Conference (IMC), Tokyo, Japan, Pages 509-522,
           DOI 10.1145/2815675.2815678, October 2015,
           <http://conferences2.sigcomm.org/imc/2015/papers/
           p509.pdf>.

[BitTorrent]
           Wikipedia, "BitTorrent", November 2015,
           <https://en.wikipedia.org/w/
           index.php?title=BitTorrent&oldid=690381343>.

[CPNI-IPv6]
           Gont, F., "Security Assessment of the Internet Protocol
           version 6 (IPv6)", UK Centre for the Protection of
           National Infrastructure, (available on request).

[DEFAULT-IIDS]
           Gont, F., Cooper, A., Thaler, D., and W. Liu,
           "Recommendation on Stable IPv6 Interface Identifiers",
           Work in Progress, draft-ietf-6man-default-iids-10,
           February 2016.

[Ford2013] Ford, M., "IPv6 Address Analysis - Privacy In, Transition
           Out", May 2013,
           <http://www.internetsociety.org/blog/2013/05/
           ipv6-address-analysis-privacy-transition-out>.

[Gont-DEEPSEC2011]
           Gont, F., "Results of a Security Assessment of the
           Internet Protocol version 6 (IPv6)", DEEPSEC
           Conference, Vienna, Austria, November 2011,
           <http://www.si6networks.com/presentations/deepsec2011/
           fgont-deepsec2011-ipv6-security.pdf>.

[Gont-LACSEC2013]
           Gont, F., "IPv6 Network Reconnaissance: Theory &
           Practice", LACSEC Conference, Medellin, Colombia, May
           2013, <http://www.si6networks.com/presentations/lacnic19/
           lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.

[IIDS-DHCPv6]
           Gont, F. and W. Liu, "A Method for Generating Semantically
           Opaque Interface Identifiers with Dynamic Host
           Configuration Protocol for IPv6 (DHCPv6)", Work in
           Progress, draft-ietf-dhc-stable-privacy-addresses-02,
           April 2015.

[IPV6-EXT-HEADERS]
           Gont, F., Linkova, J., Chown, T., and W. Liu,
           "Observations on the Dropping of Packets with IPv6
           Extension Headers in the Real World", Work in Progress,
           draft-ietf-v6ops-ipv6-ehs-in-real-world-02, December 2015.

[IPv6-RDNS]
           Howard, L., "Reverse DNS in IPv6 for Internet Service
           Providers", Work in Progress, draft-ietf-dnsop-isp-
           ip6rdns-00, October 2015.

[IPv6-Toolkit]
           SI6 Networks, "SI6 Networks' IPv6 Toolkit",
           <http://www.si6networks.com/tools/ipv6toolkit>.

[Malone2008]
           Malone, D., "Observations of IPv6 Addresses", Passive and
           Active Network Measurement (PAM 2008, LNCS 4979),
           DOI 10.1007/978-3-540-79232-1_3, April 2008,
           <http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.

[mdns-scan]
           Poettering, L., "mdns-scan(1) Manual Page",
           <http://manpages.ubuntu.com/manpages/precise/man1/
           mdns-scan.1.html>.

[mzclient] Bockover, A., "Mono Zeroconf Project -- mzclient command-
           line tool",
           <http://www.mono-project.com/archived/monozeroconf/>.

[nmap2015] Lyon, Gordon "Fyodor", "Nmap 7.00", November 2015,
           <http://insecure.org>.

[NXDOMAIN-DEF]
           Bortzmeyer, S. and S. Huque, "NXDOMAIN really means there
           is nothing underneath", Work in Progress, draft-ietf-
           dnsop-nxdomain-cut-00, December 2015.

[OPSEC-IPv6]
           Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
           Security Considerations for IPv6 Networks", Work in
           Progress, draft-ietf-opsec-v6-07, September 2015.

[RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local
           Multicast Name Resolution (LLMNR)", RFC 4795,
           DOI 10.17487/RFC4795, January 2007,
           <http://www.rfc-editor.org/info/rfc4795>.

[RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
           ICMPv6 Messages in Firewalls", RFC 4890,
           DOI 10.17487/RFC4890, May 2007,
           <http://www.rfc-editor.org/info/rfc4890>.

[RFC5157]  Chown, T., "IPv6 Implications for Network Scanning",
           RFC 5157, DOI 10.17487/RFC5157, March 2008,
           <http://www.rfc-editor.org/info/rfc5157>.

[RFC5375]  Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
           and C. Hahn, "IPv6 Unicast Address Assignment
           Considerations", RFC 5375, DOI 10.17487/RFC5375, December
           2008, <http://www.rfc-editor.org/info/rfc5375>.

[RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
           Neighbor Discovery Problems", RFC 6583,
           DOI 10.17487/RFC6583, March 2012,
           <http://www.rfc-editor.org/info/rfc6583>.

[RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
           DOI 10.17487/RFC6762, February 2013,
           <http://www.rfc-editor.org/info/rfc6762>.

[RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
           Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
           <http://www.rfc-editor.org/info/rfc6763>.

[RFC7421]  Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
           Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
           Boundary in IPv6 Addressing", RFC 7421,
           DOI 10.17487/RFC7421, January 2015,
           <http://www.rfc-editor.org/info/rfc7421>.

[RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
           Terminology", RFC 7719, DOI 10.17487/RFC7719, December
           2015, <http://www.rfc-editor.org/info/rfc7719>.

[RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
           Considerations for IPv6 Address Generation Mechanisms",
           RFC 7721, DOI 10.17487/RFC7721, March 2016,
           <http://www.rfc-editor.org/info/rfc7721>.

[SMURF-AMPLIFIER]
           Gont, F. and W. Liu, "Security Implications of IPv6
           Options of Type 10xxxxxx", Work in Progress, draft-gont-
           6man-ipv6-smurf-amplifier-03, March 2013.

[THC-IPV6] "THC-IPV6", <http://www.thc.org/thc-ipv6/>.

[traceroute6]
           FreeBSD, "FreeBSD System Manager's Manual: traceroute6(8)
           manual page", August 2009, <https://www.freebsd.org/cgi/
           man.cgi?query=traceroute6>.

[V6-WORMS] Bellovin, S., Cheswick, B., and A. Keromytis, "Worm
           propagation strategies in an IPv6 Internet", Vol. 31, No.
           1, pp. 70-76, February 2006,
           <https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>.

[van-Dijk] van Dijk, P., "Finding v6 hosts by efficiently mapping
           ip6.arpa", March 2012, <http://7bits.nl/blog/2012/03/26/
           finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.

[VBox2011] VirtualBox, "Oracle VM VirtualBox User Manual",
           Version 4.1.2, August 2011, <http://www.virtualbox.org>.

[vmesx2011]
           VMware, "Setting a static MAC address for a virtual NIC
           (219)", VMware Knowledge Base, August 2011,
           <http://kb.vmware.com/selfservice/microsites/
           search.do?language=en_US&cmd=displayKC&externalId=219>.

[vSphere]  VMware, "vSphere Networking", vSphere 5.5, Update 2,
           September 2014, <http://pubs.vmware.com/
           vsphere-55/topic/com.vmware.ICbase/PDF/
           vsphere-esxi-vcenter-server-552-networking-guide.pdf>.

Appendix A. Implementation of a Full-Fledged IPv6 Address-Scanning Tool 🧚

okay this appendix is where we actually build the big scanning tool 🔥 it's split into three bits: A.1 is about picking your probes, A.2 covers scanners for local area networks, and A.3 is the general, not-just-local version 💜

A.1. Host-Probing Considerations 🌸

okay so there are a bunch of factors you need to think about when picking the probe packet types and the probing rate for an IPv6 address-scanning tool 👀

first up, some hosts (or border firewalls) might be set up to block or rate limit certain packet types. for example, it's super usual for host and router implementations to rate-limit ICMPv6 error traffic 🙈 also, some firewalls might be configured to block or rate limit incoming ICMPv6 echo request packets (see, e.g., [RFC4890]).

NOTE: As noted earlier in this document, Windows systems simply do not respond to ICMPv6 echo requests sent to multicast IPv6 addresses. 💀

these are the probe types on the table:

  • ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies),
  • TCP SYN segments (meant to elicit SYN/ACK or RST segments),
  • TCP segments that do not contain the ACK bit set (meant to elicit RST segments),
  • UDP datagrams (meant to elicit a UDP application response or an ICMPv6 Port Unreachable),
  • IPv6 packets containing any suitable payload and an unrecognized extension header (meant to elicit ICMPv6 Parameter Problem error messages), or
  • IPv6 packets containing any suitable payload and an unrecognized option of type 10xxxxxx (meant to elicit an ICMPv6 Parameter Problem error message).

picking the right probe packet might help hide the ongoing attack 🕵️‍♀️ but it may also be actually necessary if host or network configuration causes certain probe packets to get dropped.

some address-scanning tools (such as scan6 of [IPv6-Toolkit]) have support for IPv6 extension headers baked in ✨ in some cases, slipping some IPv6 extension headers into the probe packet may let certain filtering policies or monitoring devices get circumvented. however, it may also end up with the probe packets getting dropped, because IPv6 packets that use extension headers are being dropped all over the place (see [IPV6-EXT-HEADERS]) 😭

another thing to keep in mind is the address-probing rate 🏃‍♀️ obviously, the higher the rate, the less time the whole thing takes. but the probing rate should not be too high, or else:

  1. the attack might cause network congestion, thus resulting in packet loss.
  2. the attack might hit rate limiting, thus resulting in packet loss.
  3. the attack might reveal underlying problems in Neighbor Discovery implementations, thus leading to packet loss and possibly even Denial of Service.

packet loss is seriously undesirable 💔 because an "alive" node might stay undetected just because a probe or response got lost. those losses could come from congestion (if the attacker is scanning a target network faster than that network can handle) or from rate limiting (which is typically what happens if ICMPv6 is used for the probe packets). finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router implementations have been found to be unable to manage resources decently when they're faced with Neighbor Discovery traffic from a large number of local nodes 🫠 this basically means that no matter what type of probe packets you use, an address-scanning attack might end up as a DoS of the target network, with the same (or worse) effects as congestion or rate limiting.

the exact rates where these issues start to kick in are different from one scenario to another, and they depend on the type of routers/firewalls deployed, configuration parameters, and so on 🎀

A.2. Implementation of an IPv6 Local Address-Scanning Tool 💖

okay so scan6 (cited as [IPv6-Toolkit]) is a full-fledged IPv6 local address-scanner, and it's been proven to be effective and efficient at finding IPv6 hosts on a local network. iconic 🔥

The scan6 tool operates (roughly) as follows:

  1. The tool learns the local prefixes used for autoconfiguration and generates/configures one address for each local prefix (in addition to a link-local address). 🦋
  2. An ICMPv6 Echo Request message destined to the all-nodes on-link multicast address (ff02::1) is sent from each of the addresses "configured" in the previous step. Because of the different source addresses, each probe packet causes the victim nodes to use different source addresses for the response packets (this allows the tool to learn virtually all the addresses in use in the local network segment). ✨
  3. The same procedure of the previous bullet is performed, but this time with ICMPv6 packets that contain an unrecognized option of type 10xxxxxx, such that ICMPv6 Parameter Problem error messages are elicited. This allows the tool to discover, e.g., Windows nodes, which otherwise do not respond to multicasted ICMPv6 Echo Request messages. 🪟💅
  4. Each time a new "alive" address is discovered, the corresponding IID is combined with all the local prefixes, and the resulting addresses are probed (with unicasted packets). This can help to discover other addresses in use on the local network segment, since the same IID is typically used with all the available prefixes for the local network. 🧚
NOTE: The aforementioned scheme can fail to discover some addresses for some implementations. For example, Mac OS X employs IPv6 addresses embedding IEEE identifiers (rather than "temporary addresses") when responding to packets destined to a link-local multicast address, sourced from an on-link prefix. 🙈

A.3. Implementation of an IPv6 Remote Address-Scanning Tool 🌍

bestie, an IPv6 remote address-scanning tool could be implemented with the following features:

  • The tool can be instructed to target specific address ranges (e.g., 2001:db8::0-10:0-1000). 🎯
  • The tool can be instructed to scan for SLAAC addresses of a specific vendor, such that only addresses embedding the corresponding IEEE OUIs are probed. 🍓
  • The tool can be instructed to scan for SLAAC addresses that employ a specific IEEE OUI or set of OUIs corresponding to a specific vector. 🌸
  • The tool can be instructed to discover virtual machines, such that a given IPv6 prefix is only scanned for the address patterns resulting from virtual machines. 💻
  • The tool can be instructed to scan for low-byte addresses. 🫶
  • The tool can be instructed to scan for wordy addresses, in which case the tool selects addresses based on a local dictionary. 📖
  • The tool can be instructed to scan for IPv6 addresses embedding TCP/UDP service ports, in which case the tool selects addresses based on a list of well-known service ports. 🔌
  • The tool can be specified to scan an IPv4 address range in use at the target network, such that only IPv4-based IPv6 addresses are scanned. 🌈

The scan6 tool of [IPv6-Toolkit] implements all these techniques/features. Furthermore, when given a target domain name or sample IPv6 address for a given prefix, the tool will try to infer the address pattern in use at the target network, and reduce the address search space accordingly. It's giving smart, not just brute force 👑

Acknowledgements ✨

The authors would like to thank Ray Hunter, who provided valuable text that was readily incorporated into Section 4.2.1 of this document. 💜

The authors would like to thank (in alphabetical order) Ivan Arce, Alissa Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc Heuse, Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke for providing valuable comments on earlier draft versions of this document. The whole squad showed up 🫶🫶

Fernando Gont would like to thank Jan Zorz of Go6 Lab <http://go6lab.si/> and Jared Mauch of NTT America for providing access to systems and networks that were employed to perform experiments and measurements that helped to improve this document. Additionally, he would like to thank SixXS <https://www.sixxs.net> for providing IPv6 connectivity. 🙌

Part of the contents of this document are based on the results of the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). 🔐

Fernando Gont would like to thank Daniel Bellomo (UNRC) for his continued support. 🦋

Authors' Addresses 📮

Fernando Gont
Huawei Technologies
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI:   http://www.si6networks.com


Tim Chown
Jisc
Lumen House, Library Avenue
Harwell Oxford, Didcot. OX11 0SG
United Kingdom

Email: tim.chown@jisc.ac.uk

And that's the whole doc, bestie! 🌈💅 Period.

📦 where this page comes from