IPv6 Implications for Network Scanning
RFC 5157

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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 scanning