RFC 5157

IPv6 Implications for Network Scanning

📅 published March 2008, from ietf

RFC 5157: IPv6 Implications for Network Scanning 🎀

Okay bestie, this one is RFC 5157, called IPv6 Implications for Network Scanning 🦋 It came from the Network Working Group and was written by T. Chown at the University of Southampton ✨ It's marked as Informational 📚 and dated March 2008 🌸 It doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Table of Contents 📋

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Target Address Space for Network Scanning  . . . . . . . . . .  4
     2.1.  IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Reducing the IPv6 Search Space . . . . . . . . . . . . . .  4
     2.4.  Dual-Stack Networks  . . . . . . . . . . . . . . . . . . .  5
     2.5.  Defensive Scanning . . . . . . . . . . . . . . . . . . . .  5
   3.  Alternatives for Attackers: Off-Link . . . . . . . . . . . . .  5
     3.1.  Gleaning IPv6 Prefix Information . . . . . . . . . . . . .  5
     3.2.  DNS Advertised Hosts . . . . . . . . . . . . . . . . . . .  6
     3.3.  DNS Zone Transfers . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Log File Analysis  . . . . . . . . . . . . . . . . . . . .  6
     3.5.  Application Participation  . . . . . . . . . . . . . . . .  6
     3.6.  Multicast Group Addresses  . . . . . . . . . . . . . . . .  7
     3.7.  Transition Methods . . . . . . . . . . . . . . . . . . . .  7
   4.  Alternatives for Attackers: On-Link  . . . . . . . . . . . . .  7
     4.1.  General On-Link Methods  . . . . . . . . . . . . . . . . .  7
     4.2.  Intra-Site Multicast or Other Service Discovery  . . . . .  8
   5.  Tools to Mitigate Scanning Attacks . . . . . . . . . . . . . .  8
     5.1.  IPv6 Privacy Addresses . . . . . . . . . . . . . . . . . .  9
     5.2.  Cryptographically Generated Addresses (CGAs) . . . . . . .  9
     5.3.  Non-Use of MAC Addresses in EUI-64 Format  . . . . . . . . 10
     5.4.  DHCP Service Configuration Options . . . . . . . . . . . . 10
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 11

Status of This Memo 📝

This memo is here to give info to the Internet community 💜 It does not specify an Internet standard of any kind, so don't go treating it like one 🙈 Distribution of this memo is unlimited, so share it with everyone 🌈

Abstract ✨

Okay so IPv6 has a way bigger default 64-bit subnet address space, and in theory that makes the old-school network (port) scanning that some worms and scanning tools rely on way less effective 💅 But here's the tea: traditional scanning probes (whether a person runs them or a worm does it automatically) might get less common, and attackers could switch to other ways of finding IPv6 addresses on a target network 👀 So admins should know those techniques exist and also know what measures they can use to shut them down 🫶 This doc talks through approaches admins can take when they plan their site address allocation and management strategies, as part of a defence-in-depth approach to network security 🛡️

1. Introduction ✨

Bestie, the biggest difference between IPv4 and IPv6 is how much bigger the IPv6 address space is, and that also means much larger subnets 🌸 That changes the game for TCP and UDP network scanning, where an automated process goes hunting for open ports (services) on systems that could then get attacked 😭 Loads of IPv4 sites get probed like this again and again today, and a big reason is how densely packed the active hosts are in any chunk of IPv4 address space 💀

The 128 bits of IPv6 [1] address space is way bigger than the 32 bits in IPv4 🔥 Specifically, IPv6 subnets that hosts attach to will by default have 64 bits of host address space [2] 👑 So the usual ways of scanning a host remotely over TCP or UDP to find open or running services could get a lot less doable, because the search space in the subnet is huge 🧚 Worms that rely on off-link network scanning to spread might also be more limited in impact 💖 This document digs into that property of IPv6 and lays out related stuff IPv6 site network admins should think about, which could be handy when planning site address allocation and management strategies 🦋

For example, lots of worms, like Slammer, depend on address scanning to spread, whether they pick subnets numerically (and so probably topologically) close to the current victim, or subnets in random remote networks 🪱 The way these worms work might change if detecting target hosts between sites or subnets gets harder with traditional methods 😤 But other worms spread through things like email, and the methods in this text don't apply to those 📧

Here's the important bit: the defence of a network must not rely solely on the unpredictable sparseness of the host addresses on that network 🚨 That sparseness is only one measure in a set of measures that might be applied 💅 This document covers various measures a site can use to mitigate attacks as part of an overall strategy 💜 Some of them cost less to deploy than others ✨ For example, if you're numbering hosts on a subnet, it may be just as cheap to number them without any predictable pattern as it is to number them sequentially 🎀 On the flip side, using IPv6 privacy extensions [3] may complicate network management, because it gets harder to figure out which hosts use which addresses 🙈

This document complements the transition-centric discussion of issues in Appendix A of "IPv6 Transition/ Co-existence Security Considerations" [12], which takes a broad view of security issues for transitioning networks 🌈 The reader is also pointed to a recent paper by Bellovin on network worm propagation strategies in IPv6 networks [13] 📄 That paper covers some of the issues in this document too, just from a slightly different angle 🫶

2. Target Address Space for Network Scanning 🔍

Okay so the considerations for whether brute-force scanning is doable are significantly different for plain IPv4 and IPv6 address scanning 💅

2.1. IPv4

A typical IPv4 subnet may have 8 bits reserved for host addressing 🍓 In that case, a remote attacker only needs to probe at most 256 addresses to find out if a particular service is running publicly on a host in that subnet 😌 Even at just one probe per second, the scan would finish in under 5 minutes 🏃‍♀️💨

2.2. IPv6

A typical IPv6 subnet will have 64 bits reserved for host addressing 🌌 In that case, a remote attacker in principle needs to probe 2^64 addresses to find out if a particular open service is running on a host in that subnet 😵 At a very conservative one probe per second, the scan may take some 5 billion years to finish 💀 Even a faster probe is still going to take (effectively) infinite time to cover the whole address space 🫠 BUT, there are ways for the attacker to shrink the address search space they scan within the target subnet, and we'll get into those below 👀

2.3. Reducing the IPv6 Search Space

The IPv6 host address space an attacker might search through can be reduced in at least two ways 🧩

First, the attacker might count on the admin conveniently numbering their hosts from [prefix]::1 upward 🙄 That makes scanning trivial, so it should be avoided unless the host's address is easy to get from other sources (for example, it's the site's published primary DNS or email Mail Exchange (MX) server) 📬 Also, if hosts are numbered sequentially, or using any regular scheme, knowing one address could expose other available addresses to scan 😬

Second, if hosts are statelessly autoconfiguring [1], the host part of the address will usually follow a well-known format that includes the Ethernet vendor prefix and the fffe stuffing 🎯 For those hosts, the search space can be reduced to 48 bits 📉 And if the Ethernet vendor is also known, the search space may drop to 24 bits, and a one-probe-per-second scan then takes a less daunting 194 days 🥹 Even when the exact vendor isn't known, using a set of common vendor prefixes can cut the search down 🪄 Plus, lots of nodes on a site network may be bought in batches, so they can have sequential or near-sequential Media Access Control (MAC) addresses 📦 If one node's autoconfigured address is known, scanning around that address might pay off for the attacker 🎁 Again, any form of sequential host addressing should be avoided if possible 🙅‍♀️

2.4. Dual-Stack Networks

Full advantage of the bigger IPv6 address space for resilience against network scanning might not show up until IPv6-only networks and devices become more common 🌱 That's because most IPv6 hosts are currently dual stack, with (more easily scannable) IPv4 connectivity 🧃 But lots of applications or services (e.g., new peer-to-peer applications) on those dual-stack hosts may pop up that are only reachable over IPv6, which means they can only be discovered by IPv6 address scanning 🕵️‍♀️✨

2.5. Defensive Scanning

The problem the attacker has on an IPv6 network is also a problem for a site admin who's looking for vulnerabilities in their own network's systems 🪞 The admin should have the advantage of being on-link for scanning purposes though 💪

Okay so if IPv6 hosts in subnets get allocated addresses 'randomly', and IPv6 network scanning becomes pretty much infeasible as a result, attackers will have to find new ways to identify IPv6 addresses for later scanning 😤 In this section we go through some possible paths attackers might take 🛤️ In these cases, the attacker will try to identify specific IPv6 addresses for later targeted probes 🎯

3.1. Gleaning IPv6 Prefix Information

Note that in IPv6, an attacker can't search across the entire IPv6 address space the way they might in IPv4 🙃 They can, however, learn general prefixes to focus their efforts on by looking at route view information (e.g., from public looking-glass services) or information on allocated address space from Regional Internet Registries (RIRs) 🗺️ In general, this only yields information at most at the /48 prefix granularity, though some specific /64 prefixes may be spotted from route views on some parts of some networks 👁️

3.2. DNS Advertised Hosts

Any servers that are DNS listed, e.g., MX mail relays or web servers, will stay open to probing just because their IPv6 addresses are published in the DNS 📢

Servers are pretty easy to find since they're DNS-published, but any systems that aren't DNS-published will be a lot harder to locate with traditional scanning than they would be on IPv4 networks 🫣 It's also worth noting that where a site uses sequential host numbering, publishing just one address may lead to a threat against the other hosts 🚩

Good work getting through part 1 🌈💖

3.3. DNS Zone Transfers 🗺️

Okay bestie, in the IPv6 world a DNS zone transfer is way more likely to narrow down the number of hosts an attacker needs to target 💀. This implies that restricting zone transfers is (more) important for IPv6, even if it is already good practice to restrict them in the IPv4 world. So yes, lock those down even harder 🔒

There are some projects that provide Internet mapping data from access to such transfers. Administrators may of course agree to provide such transfers where they choose to do so ✨

3.4. Log File Analysis 📜

IPv6 addresses can get harvested from recorded logs, like web site logs 👀 Anywhere else where IPv6 addresses are explicitly recorded may prove a useful channel for an attacker, e.g., by inspection of the (many) Received from: or other header lines in archived email or Usenet news messages. Those old archives are giving treasure chest energy 🧚

3.5. Application Participation 🤝

More recent peer-to-peer applications often include some centralised server that coordinates the transfer of data between peers. The BitTorrent application builds swarms of nodes that exchange chunks of files, with a tracker passing information about peers with available chunks of data between the peers. Such applications may offer an attacker a source of peer IP addresses to probe 🫣

3.6. Multicast Group Addresses 📡

Where an Embedded Rendezvous Point (RP) [7] multicast group address is known, the unicast address of the RP is implied by the group address. Where unicast-prefix-based multicast group addresses [5] are used, specific /64 link prefixes may also be disclosed in traffic that goes off-site. An administrator may thus choose to put aside /64 bit prefixes for multicast group addresses that are not in use for normal unicast routing and addressing. Alternatively, a site may simply use their non-specific /48 site prefix allocation to generate RFC3306 multicast group addresses 🌸

3.7. Transition Methods 🦋

Specific knowledge of the target network may be gleaned if that attacker knows it is using 6to4 [4], ISATAP [10], Teredo [11], or other techniques that derive low-order bits from IPv4 addresses (though in this case, unless they are using IPv4 NAT, the IPv4 addresses may be probed anyway). Not ideal 😭

For example, the current Microsoft 6to4 implementation uses the address 2002:V4ADDR::V4ADDR while older Linux and FreeBSD implementations default to 2002:V4ADDR::1. This leads to specific knowledge of specific hosts in the network. Given one host in the network is observed as using a given transition technique, it is likely that there are more 🕵️‍♀️

In the case of Teredo, the 64-bit node identifier is generated from the IPv4 address observed at a Teredo server along with a UDP port number. The Teredo specification also allows for discovery of other Teredo clients on the same IPv4 subnet via a well-known IPv4 multicast address (see Section 2.17 of RFC 4380 [11]). The way that it just hands out clues like that 💀

The main thrust of this text is considerations for off-link attackers or probing of a network. In general, once one host on a link is compromised, others on the link can be very readily discovered. Main character attacker energy, and not in a good way 😤

If the attacker already has access to a system on the current subnet, then traffic on that subnet, be it Neighbour Discovery or application-based traffic, can invariably be observed, and active node addresses within the local subnet learnt.

In addition to making observations of traffic on the link, IPv6-enabled hosts on local subnets may be discovered through probing the "all hosts" link-local multicast address. Likewise, any routers on the subnet may be found via the "all routers" link-local multicast address. An attacker may choose to probe in a slightly more obfuscated way by probing the solicited node multicast address of a potential target host 🥷

Where a host has already been compromised, its Neighbour Discovery cache is also likely to include information about active nodes on the current subnet, just as an ARP cache would do for IPv4 🍓

Also, depending on the node, traffic to or from other nodes (in particular, server systems) is likely to show up if an attacker can gain a presence on a node in any one subnet in a site's network. Literally everything is connected, bestie 🫠

4.2. Intra-Site Multicast or Other Service Discovery 🧭

A site may also have site- or organisational-scope multicast configured, in which case application traffic, or service discovery, may be exposed site wide. An attacker may also choose to use any other service discovery methods supported by the site. Lowkey a lot of doors left unlocked 🚪

5. Tools to Mitigate Scanning Attacks 🛠️

There are some tools that site administrators can apply to make the task for IPv6 network scanning attackers harder. These methods arise from the considerations in the previous section. Okay, so here's the fix era 💪

The author notes that at his current (university) site, there is no evidence of general network scanning running across subnets. However, there is network scanning over IPv6 connections to systems whose IPv6 addresses are advertised (DNS servers, MX relays, web servers, etc.), which are presumably looking for other open ports on these hosts to probe further. At the time of writing, DHCPv6 [6] is not yet in use at the author's site, and clients use stateless autoconfiguration. Therefore, the author's site does not yet have sequentially numbered client hosts deployed as may typically be seen in today's IPv4 DHCP-served networks 🎀

5.1. IPv6 Privacy Addresses 🕶️

Hosts in a network using IPv6 privacy extensions [3] will typically only connect to external systems using their current (temporary) privacy address. The precise behaviour of a host with a stable global address and one or more dynamic privacy address(es) when selecting a source address to use may be operating-system-specific, or configurable, but typical behaviour when initiating a connection is use of a privacy address when available. Privacy addresses really be doing the most 💅

While an attacker may be able to port scan a privacy address, if they do so quickly upon observing or otherwise learning of the address, the threat or risk is reduced due to the time-constrained value of the address. One implementation of RFC 4941 already deployed has privacy addresses active (used by the node) for one day, with such addresses reachable for seven days. Short-lived addresses are giving "gone before you can blink" vibes ⏳

Note that an RFC 4941 host will usually also have a separate static global IPv6 address by which it can also be reached, and that may be DNS-advertised if an externally reachable service is running on it. DHCPv6 can be used to serve normal global addresses and IPv6 privacy addresses 🌈

The implication is that while privacy addresses can mitigate the long-term value of harvested addresses, an attacker creating an IPv6 application server to which clients connect will still be able to probe the clients by their privacy address when they visit that server. The duration for which privacy addresses are valid will impact the usefulness of such observed addresses to an external attacker. For example, a worm that may spread using such observed addresses may be less effective if it relies on harvested privacy addresses. The frequency with which such address get recycled could be increased, though this may increase the complexity of local network management for the administrator, since doing so will cause more addresses to be used over time in the site. So it's a tradeoff, babe ⚖️

A further option here may be to consider using different addresses for specific applications, or even each new application instance, which may reduce exposure to other services running on the same host when such an address is observed externally. Compartmentalise your addresses, queen 👑

5.2. Cryptographically Generated Addresses (CGAs) 🔐

The use of Cryptographically Generated Addresses (CGAs) [9] may also cause the search space to be increased from that presented by default use of stateless autoconfiguration. Such addresses would be seen where Secure Neighbour Discovery (SEND) [8] is in use. Bigger search space, harder life for scanners 🧠

5.3. Non-Use of MAC Addresses in EUI-64 Format 🙈

The EUI-64 identifier format does not require the use of MAC addresses for identifier construction. At least one well known operating system currently defaults to generation of the 64-bit interface identifier by use of random bits, and thus does not embed the MAC address. Where such a method exists, an administrator may wish to consider using that option 🫶

5.4. DHCP Service Configuration Options ⚙️

One option open to an administrator is to configure DHCPv6, if possible, so that the first addresses allocated from the pool begins much higher in the address space than at [prefix]::1. Further, it is desirable that allocated addresses are not sequential and do not have any predictable pattern to them. Unpredictable sparseness in the allocated addresses is a desirable property. DHCPv6 implementers could reduce the cost for administrators to deploy such 'random' addressing by supporting configuration options to allow such behaviour 🎲

DHCPv6 also includes an option to use privacy extension [3] addresses, i.e., temporary addresses, as described in Section 12 of the DHCPv6 [6] specification 💖

6. Conclusions 🎀

Due to the much larger size of IPv6 subnets in comparison to IPv4, it will become less feasible for traditional network scanning methods to detect open services for subsequent attacks, assuming the attackers are off-site and services are not listed in the DNS. If administrators number their IPv6 subnets in 'random', non-predictable ways, attackers, whether they be in the form of automated network scanners or dynamic worm propagation, will need to make wider use of new methods to determine IPv6 host addresses to target (e.g., looking to obtain logs of activity from a site and scanning addresses around the ones observed). Such numbering schemes may be very low cost to deploy in comparison to conventional sequential numbering, and thus, a useful part of an overall defence-in-depth strategy. Of course, if those systems are dual-stack, and have open IPv4 services running, they will remain exposed to traditional probes over IPv4 transport. Scanners gotta work harder, but IPv4 is still a loophole 🙃

7. Security Considerations 🚨

There are no specific security considerations in this document outside of the topic of discussion itself. However, it must be noted that the 'security through obscurity' discussions and commentary within this text must be noted in their proper context. Relying purely on obscurity of a node address is not prudent, rather the advice here should be considered as part of a 'defence-in-depth' approach to security for a site or network.

Bestie, hear me out: relying purely on obscurity of a node address is not prudent. Hiding an address is not a security plan on its own, so treat everything here as one layer in a 'defence-in-depth' approach for the whole site or network 🛡️

This also implies that these measures require coordination between network administrators and those who maintain DNS services, though this is common in most scenarios 🤝

8. Acknowledgements 💜

Thanks are due to people in the 6NET project (www.6net.org) for discussion of this topic, including Pekka Savola, Christian Strauf, and Martin Dunmore, as well as other contributors from the IETF v6ops and other mailing lists, including Tony Finch, David Malone, Bernie Volz, Fred Baker, Andrew Sullivan, Tony Hain, Dave Thaler, and Alex Petrescu. Thanks are also due for editorial feedback from Brian Carpenter, Lars Eggert, and Jonne Soininen amongst others. Shoutout to this whole squad 🌟

9. Informative References ✨

okay bestie, here's the reading list 📚 every one of these is a real RFC or paper, so if you want the receipts, this is where they live 💅

  • [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 🧚
  • [2] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 🌸
  • [3] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. 🙈
  • [4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. ☁️
  • [5] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. 📡
  • [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 🎀
  • [7] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. 🦋
  • [8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 🔐
  • [9] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. 🔑
  • [10] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. 🚇
  • [11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. 🕳️
  • [12] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007. 🛡️
  • [13] Bellovin, S., et al, "Worm Propagation Strategies in an IPv6 Internet", as published in ;login:, February 2006, <http://www.cs.columbia.edu/~smb/papers/v6worms.pdf>. 🐛

Author's Address 🎀

Tim Chown University of Southampton Southampton, Hampshire SO17 1BJ United Kingdom

EMail: tjc@ecs.soton.ac.uk

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🌈

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Intellectual Property 🔥

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 🧾

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🫶

📦 where this page comes from