IPv6 Implications for Network Scanning
RFC 5157
Document | Type |
RFC - Informational
(March 2008; No errata)
Obsoleted by RFC 7707
|
|
---|---|---|---|
Author | Tim Chown | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5157 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ron Bonica | ||
Send notices to | (None) |
Network Working Group T. Chown Request for Comments: 5157 University of Southampton Category: Informational March 2008 IPv6 Implications for Network Scanning Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. Chown Informational [Page 1] RFC 5157 IPv6 Network Scanning March 2008 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 Chown Informational [Page 2] RFC 5157 IPv6 Network Scanning March 2008 1. Introduction One of the key differences between IPv4 and IPv6 is the much larger address space for IPv6, which also goes hand-in-hand with much larger subnet sizes. This change has a significant impact on the feasibility of TCP and UDP network scanning, whereby an automated process is run to detect open ports (services) on systems that may then be subject to a subsequent attack. Today many IPv4 sites are subjected to such probing on a recurring basis. Such probing is common in part due to the relatively dense population of active hosts in any given chunk of IPv4 address space. The 128 bits of IPv6 [1] address space is considerably bigger than the 32 bits of address space in IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space [2]. As a result, traditional methods of remote TCP or UDP network scanning to discover open or running services on a host will potentially become less feasible, due to the larger search space in the subnet. Similarly, worms that rely on off-link network scanning to propagate may also potentially be more limited in impact. This document discusses this property of IPv6 and describes related issues for IPv6 site network administrators to consider, which may be useful when planning site address allocation and management strategies. For example, many worms, like Slammer, rely on such address scanningShow full document text