IPv6 Implications for Network Scanning
RFC 5157
| Document | Type |
RFC - Informational
(March 2008; No errata)
Obsoleted by RFC 7707
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text