draft-ietf-opsec-ipv6-host-scanning-01.txt   draft-ietf-opsec-ipv6-host-scanning-02.txt 
Operational Security Capabilities for F. Gont Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) Huawei Technologies IP Network Infrastructure (opsec) Huawei Technologies
Internet-Draft T. Chown Internet-Draft T. Chown
Obsoletes: 5157 (if approved) University of Southampton Obsoletes: 5157 (if approved) University of Southampton
Intended status: Informational April 30, 2013 Intended status: Informational July 15, 2013
Expires: November 1, 2013 Expires: January 16, 2014
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-01 draft-ietf-opsec-ipv6-host-scanning-02
Abstract Abstract
IPv6 offers a much larger address space than that of its IPv4 IPv6 offers a much larger address space than that of its IPv4
counterpart. The standard /64 IPv6 subnets can (in theory) counterpart. The standard /64 IPv6 subnets can (in theory)
accommodate approximately 1.844 * 10^19 hosts, thus resulting in a accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
much lower host density (#hosts/#addresses) than their IPv4 much lower host density (#hosts/#addresses) than is typical in IPv4
counterparts. As a result, it is widely assumed that it would take a networks, where a site typically has 65,000 or less unique addresses.
tremendous effort to perform address scanning attacks against IPv6 As a result, it is widely assumed that it would take a tremendous
networks, and therefore IPv6 address scanning attacks have long been effort to perform address scanning attacks against IPv6 networks, and
considered unfeasible. This document analyzes how traditional therefore classic IPv6 address scanning attacks have been considered
address scanning techniques apply to IPv6 networks, and also explores unfeasible. This document updates RFC 5157 by providing further
a number of other techniques that can be employed for IPv6 network analysis on how traditional address scanning techniques apply to IPv6
reconnaissance. Additionally, this document formally obsoletes RFC networks, and exploring some additional techniques that can be
5157. employed for IPv6 network reconnaissance. In doing so, this document
formally obsoletes RFC 5157.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 1, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for the Applicability of Network 2. Requirements for the Applicability of Network
Reconnaissance Techniques . . . . . . . . . . . . . . . . . . 4 Reconnaissance Techniques . . . . . . . . . . . . . . . . . . 4
3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5
3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 5 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 5
3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . . 12 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . . 14
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 12 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 15
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . . 13 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . . 15
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 16
4. Leveraging the Domain Name System (DNS) for Network 4. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . 16 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 16 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 18
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 16 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 18
4.3. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . . 16 4.3. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . . 18
5. Leveraging Local Name Resolution and Service Discovery 5. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 19 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21
7. Application Participation . . . . . . . . . . . . . . . . . . 20 7. Application Participation . . . . . . . . . . . . . . . . . . 22
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 21 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 23
9. Inspection of System Configuration and Log Files . . . . . . . 22 9. Inspection of System Configuration and Log Files . . . . . . . 24
10. Gleaning Information from Routing Protocols . . . . . . . . . 23 10. Gleaning Information from Routing Protocols . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29
14.2. Informative References . . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Implementation of a full-fledged IPv6 Appendix A. Implementation of a full-fledged IPv6
address-scanning tool . . . . . . . . . . . . . . . . 30 address-scanning tool . . . . . . . . . . . . . . . . 32
A.1. Host-probing considerations . . . . . . . . . . . . . . . 30 A.1. Host-probing considerations . . . . . . . . . . . . . . . 32
A.2. Implementation of an IPv6 local address-scanning tool . . 31 A.2. Implementation of an IPv6 local address-scanning tool . . 33
A.3. Implementation of a IPv6 remote address-scanning tool . . 32 A.3. Implementation of a IPv6 remote address-scanning tool . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The main driver for IPv6 [RFC2460] deployment is its larger address The main driver for IPv6 [RFC2460] deployment is its larger address
space [CPNI-IPv6]. This larger address space not only allows for an space [CPNI-IPv6]. This larger address space not only allows for an
increased number of connected devices, but also introduces a number increased number of connected devices, but also introduces a number
of subtle changes in several aspects of the resulting networks. One of subtle changes in several aspects of the resulting networks. One
of such changes is the reduced host density (Nr. of addresses/Nr. of of these changes is the reduced host density (the number of addresses
hosts) of typical IPv6 subnetworks: with default IPv6 subnets of /64, divided by the number of hosts) of typical IPv6 subnetworks: with
each subnet comprises more than 1.844 * 10^19 addresses; however, the default IPv6 subnets of /64, each subnet comprises more than 1.844 *
actual number of nodes in each subnet is likely to remain similar to 10^19 available addresses; however, the actual number of nodes in
that of IPv4 subnetworks (at most a few hundred nodes per subnet). each subnet is likely to remain similar to that of IPv4 subnetworks
This lower host-density has lead to the widely-established myth that (typically a few hundred nodes per subnet). [RFC5157] describes how
IPv6 address-scanning attacks are unfeasible, since they would this significantly lower IPv6 host-density is likely to make classic
require a ridiculously long time (along with a tremendous amount of network address scans less feasible, since even by applying various
traffic) to be successfully performed. heuristics, the address space to be scanned remains very large. RFC
5157 goes on to describe some alternative methods for attackers to
glean active IPv6 addresses, and provides some guidance for
administrators and implementors, e.g. not using sequential addresses
with DHCPv6.
This document analyzes the feasibility of "traditional" address- With the benefit of five years of additional IPv6 deployment
scanning attacks in IPv6 networks. Namely, it performs a thorough experience, this document formally updates (and obsoletes RFC 5157).
analysis of how IPv6 addresses are generated, and sheds some light on It emphasises that while scanning attacks are less feasible, they
the real size of the search space for IPv6 address scanning attacks may, with appropriate heuristics, remain possible. At the time that
(e.g., "ping sweeps") thus dismantling the myth that such IPv6 RFC 5157 was written, observed scans were typically across ports on
address scanning attacks are unfeasible. Additionally, this document discovered servers; since then, evidence that some classic address
explores a number of other techniques that can be employed for IPv6 scanning is being witnessed. This text thus updates the analysis on
network reconnaissance, and formally obsoletes [RFC5157]. the feasibility of "traditional" address-scanning attacks in IPv6
networks, and it explores a number of additional techniques that can
be employed for IPv6 network reconnaissance. Practical examples and
guidance are also included.
On one hand, raising awareness about IPv6 network reconnaissance On one hand, raising awareness about IPv6 network reconnaissance
techniques may allow (in some cases) network and security techniques may allow (in some cases) network and security
administrators to prevent or detect such attempts. On the other administrators to prevent or detect such attempts. On the other
hand, network reconnaissance is essential for the so-called hand, network reconnaissance is essential for the so-called
"penetration tests" typically performed to assess the security of "penetration tests" typically performed to assess the security of
production networks. As a result, we believe the benefits of a production networks. As a result, we believe the benefits of a
thorough discussion of IPv6 network reconnaissance are two-fold. thorough discussion of IPv6 network reconnaissance are two-fold.
Section 3 analyzes the feasibility of traditional address-scanning Section 3 analyzes the feasibility of traditional address-scanning
attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of
possible improvements to such techniques. [van-Dijk] describes a possible improvements to such techniques. [van-Dijk] describes a
recently-disclosed technique for leveraging DNS reverse mappings for recently-disclosed technique for leveraging DNS reverse mappings for
discovering IPv6 nodes. Finally, Appendix A describes how the discovering IPv6 nodes. Finally, Appendix A describes how the
analysis carried out throughout this document can be leveraged to analysis carried out throughout this document can be leveraged to
produce an address-scanning tools (e.g. for penetration testing produce address-scanning tools (e.g. for penetration testing
purposes). purposes).
2. Requirements for the Applicability of Network Reconnaissance 2. Requirements for the Applicability of Network Reconnaissance
Techniques Techniques
Throughout this document, a number of network reconnaissance Throughout this document, a number of network reconnaissance
techniques are discussed. Each of these techniques have different techniques are discussed. Each of these techniques have different
requirements on the side of the practitioner, with respect to whether requirements on the side of the practitioner, with respect to whether
they require local access to the target network, and whether they they require local access to the target network, and whether they
require login access to the system on which the technique is applied. require login access to the system on which the technique is applied.
The following table tries to summarize the aforementioned The following table tries to summarize the aforementioned
requirements, and serve as a cross index to the corresponding requirements, and serves as a cross index to the corresponding
sections. sections.
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Technique | Local | Login | | Technique | Local | Login |
| | access | access | | | access | access |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Local address scans (Section 3.3) | Yes | No | | Local address scans (Section 3.3) | Yes | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Remote Address scans (Section 3.2) | No | No | | Remote Address scans (Section 3.2) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
skipping to change at page 5, line 13 skipping to change at page 5, line 13
Techniques Techniques
3. IPv6 Address Scanning 3. IPv6 Address Scanning
This section discusses how traditional address scanning techniques This section discusses how traditional address scanning techniques
(e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an (e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an
essential analysis of how address configuration is performed in IPv6, essential analysis of how address configuration is performed in IPv6,
identifying patterns in IPv6 addresses that can be leveraged to identifying patterns in IPv6 addresses that can be leveraged to
reduce the IPv6 address search space when performing IPv6 address reduce the IPv6 address search space when performing IPv6 address
scans. Appendix A discusses how the insights obtained in the scans. Appendix A discusses how the insights obtained in the
previous sub-sections can be incorporated into into a full-fledged previous sub-sections can be incorporated into into a fully-fledged
IPv6 address scanning tool. Section 3.5 provides advice on how to IPv6 address scanning tool. Section 3.5 provides advice on how to
mitigate IPv6 address scans. mitigate IPv6 address scans.
3.1. Address Configuration in IPv6 3.1. Address Configuration in IPv6
IPv6 incorporates two automatic address-configuration mechanisms: IPv6 incorporates two automatic address-configuration mechanisms:
SLAAC (StateLess Address Auto-Configuration) [RFC4862] and DHCPv6 SLAAC (StateLess Address Auto-Configuration) [RFC4862] and DHCPv6
(Dynamic Host Configuration Protocol version 6) [RFC3315]. SLAAC is (Dynamic Host Configuration Protocol version 6) [RFC3315]. SLAAC is
the mandatory mechanism for automatic address configuration, while the mandatory mechanism for automatic address configuration, while
DHCPv6 is optional - however, most current versions of general- DHCPv6 is optional - however, most current versions of general-
skipping to change at page 6, line 44 skipping to change at page 6, line 44
For example, an organization known for being provisioned by vendor For example, an organization known for being provisioned by vendor
X is likely to have most of the nodes in its organizational X is likely to have most of the nodes in its organizational
network with OUIs corresponding to vendor X. network with OUIs corresponding to vendor X.
These considerations mean that in some scenarios, the original IID These considerations mean that in some scenarios, the original IID
search space of 64 bits may be effectively reduced to 2^24 , or n * search space of 64 bits may be effectively reduced to 2^24 , or n *
2^24 (where "n" is the number of different OUIs assigned to the 2^24 (where "n" is the number of different OUIs assigned to the
target vendor). target vendor).
Further, if just one host address is detected or known within a
subnet, it is not unlikely that, if systems were ordered in a batch,
that they may have sequential MAC addresses. Additionally, given a
MAC address observed in one subnet, sequential or nearby MAC
addresses may be seen in other subnets in the same site.
Another interesting factor arises from the use of virtualization Another interesting factor arises from the use of virtualization
technologies, since they generally employ automatically-generated MAC technologies, since they generally employ automatically-generated MAC
addresses, with very specific patterns. For example, all addresses, with very specific patterns. For example, all
automatically-generated MAC addresses in VirtualBox virtual machines automatically-generated MAC addresses in VirtualBox virtual machines
employ the OUI 08:00:27 [VBox2011]. This means that all SLAAC- employ the OUI 08:00:27 [VBox2011]. This means that all SLAAC-
produced addresses will have an IID of the form a00:27ff:feXX:XXXX, produced addresses will have an IID of the form a00:27ff:feXX:XXXX,
thus effectively reducing the IID search space from 64 bits to 24 thus effectively reducing the IID search space from 64 bits to 24
bits. bits.
VMWare ESX server provides yet a more interesting example. VMWare ESX server provides yet a more interesting example.
skipping to change at page 8, line 5 skipping to change at page 8, line 11
addition to traditional SLAAC addresses (i.e., based on IEEE addition to traditional SLAAC addresses (i.e., based on IEEE
identifiers): traditional SLAAC addresses are employed for incoming identifiers): traditional SLAAC addresses are employed for incoming
(i.e. server-like) communications, while "privacy addresses" are (i.e. server-like) communications, while "privacy addresses" are
employed for outgoing (i.e., client-like) communications. This means employed for outgoing (i.e., client-like) communications. This means
that implementation/use of "privacy addresses" does not prevent an that implementation/use of "privacy addresses" does not prevent an
attacker from leveraging the predictability of traditional SLAAC attacker from leveraging the predictability of traditional SLAAC
addresses, since "privacy addresses" are generated in addition to addresses, since "privacy addresses" are generated in addition to
(rather than in replacement of) the traditional SLAAC addresses (rather than in replacement of) the traditional SLAAC addresses
derived from e.g. IEEE identifiers. derived from e.g. IEEE identifiers.
The benefit that privacy addresses offer in this context is that they
reduce the exposure of the SLAAC address to any third parties that
may observe that address in use. But, in the absence of firewall
protection for the host, the SLAAC address remains liable to be
scanned from offsite.
3.1.1.3. Randomized Stable Interface Identifiers 3.1.1.3. Randomized Stable Interface Identifiers
In order to mitigate the security implications arising from the In order to mitigate the security implications arising from the
predictable IPv6 addresses derived from IEEE identifiers, Microsoft predictable IPv6 addresses derived from IEEE identifiers, Microsoft
Windows produced an alternative scheme for generating "stable Windows produced an alternative scheme for generating "stable
addresses" (in replacement of the ones embedding IEEE identifiers). addresses" (in replacement of the ones embedding IEEE identifiers).
The aforementioned scheme is allegedly an implementation of RFC 4941 The aforementioned scheme is allegedly an implementation of RFC 4941
[RFC4941], but without regenerating the addresses over time. The [RFC4941], but without regenerating the addresses over time. The
resulting interface IDs are constant across system bootstraps, and resulting interface IDs are constant across system bootstraps, and
also constant across networks. also constant across networks.
Assuming no flaws in the aforementioned algorithm, this scheme would Assuming no flaws in the aforementioned algorithm, this scheme would
remove any patterns from the SLAAC addresses. remove any patterns from the SLAAC addresses.
However, since the resulting interface IDs are constant across However, since the resulting interface IDs are constant across
networks, these addresses may still be leveraged for host tracking networks, these addresses may still be leveraged for host tracking
purposes [I-D.ietf-6man-stable-privacy-addresses]. purposes [I-D.ietf-6man-stable-privacy-addresses].
The benefit of this scheme is thus that the host may be less readily
detected by applying heuristics to a scan, but, in the absence of
concurrent use of privacy addresses, the host is liable to be
tracked.
3.1.1.4. Stable Privacy-Enhanced Addresses 3.1.1.4. Stable Privacy-Enhanced Addresses
In response to the predictability issues discussed in Section 3.1.1.1 In response to the predictability issues discussed in Section 3.1.1.1
and the privacy issues discussed in , the IETF is currently and the privacy issues discussed in
[I-D.ietf-6man-stable-privacy-addresses], the IETF is currently
standardizing (in [I-D.ietf-6man-stable-privacy-addresses]) a method standardizing (in [I-D.ietf-6man-stable-privacy-addresses]) a method
for generating IPv6 Interface Identifiers to be used with IPv6 for generating IPv6 Interface Identifiers to be used with IPv6
Stateless Address Autoconfiguration (SLAAC), such that addresses Stateless Address Autoconfiguration (SLAAC), such that addresses
configured using this method are stable within each subnet, but the configured using this method are stable within each subnet, but the
Interface Identifier changes when hosts move from one network to Interface Identifier changes when hosts move from one network to
another. The aforementioned method is meant to be an alternative to another. The aforementioned method is meant to be an alternative to
generating Interface Identifiers based on IEEE identifiers, such that generating Interface Identifiers based on IEEE identifiers, such that
the benefits of stable addresses can be achieved without sacrificing the benefits of stable addresses can be achieved without sacrificing
the privacy of users. the privacy of users.
Implementation of this method (in replacement of Interface Implementation of this method (in replacement of Interface
Identifiers based on IEEE identifiers) would eliminate any patterns Identifiers based on IEEE identifiers) would eliminate any patterns
from the Interface ID. from the Interface ID, thus benefiting user privacy and reducing the
ease with which addresses can be scanned.
3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) 3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6)
DHCPv6 can be employed as a stateful address configuration mechanism, DHCPv6 can be employed as a stateful address configuration mechanism,
in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6
hosts. As with the IPv4 counterpart, addresses are assigned hosts. As with the IPv4 counterpart, addresses are assigned
according to a configuration-defined address range and policy, with according to a configuration-defined address range and policy, with
some DHCPv6 servers assigned addresses sequentially, from a specific some DHCPv6 servers assigned addresses sequentially, from a specific
range. In such cases, addresses tend to be predictable. range. In such cases, addresses tend to be predictable.
skipping to change at page 9, line 4 skipping to change at page 9, line 24
DHCPv6 can be employed as a stateful address configuration mechanism, DHCPv6 can be employed as a stateful address configuration mechanism,
in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6
hosts. As with the IPv4 counterpart, addresses are assigned hosts. As with the IPv4 counterpart, addresses are assigned
according to a configuration-defined address range and policy, with according to a configuration-defined address range and policy, with
some DHCPv6 servers assigned addresses sequentially, from a specific some DHCPv6 servers assigned addresses sequentially, from a specific
range. In such cases, addresses tend to be predictable. range. In such cases, addresses tend to be predictable.
For example, if the prefix 2001:db8::/64 is used for assigning For example, if the prefix 2001:db8::/64 is used for assigning
addresses on the local network, the DHCPv6 server might addresses on the local network, the DHCPv6 server might
(sequentially) assign addresses from the range 2001:db8::1 - 2001: (sequentially) assign addresses from the range 2001:db8::1 - 2001:
db8::100. db8::100.
In most common scenarios, this means that the IID search space will In most common scenarios, this means that the IID search space will
be reduced from the original 64 bits, to 8 or 16 bits. be reduced from the original 64 bits, to 8 or 16 bits. RFC 5157
recommended that DHCPv6 instead issue addresses randomly from a large
pool; that advice is repeated here.
3.1.3. Manually-configured Addresses 3.1.3. Manually-configured Addresses
In some scenarios, node addresses may be manually configured. This In some scenarios, node addresses may be manually configured. This
is typically the case for IPv6 addresses assigned to routers (since is typically the case for IPv6 addresses assigned to routers (since
routers do not employ automatic address configuration) but also for routers do not employ automatic address configuration) but also for
servers (since having a stable address that does not depend on the servers (since having a stable address that does not depend on the
underlying link-layer address is generally desirable). underlying link-layer address is generally desirable).
While network administrators are mostly free to select the IID from While network administrators are mostly free to select the IID from
skipping to change at page 10, line 25 skipping to change at page 10, line 47
encode one byte of the IPv4 address in each of the 16-bit words of encode one byte of the IPv4 address in each of the 16-bit words of
the IID (as in e.g. 2001:db8::192:0:2:1). the IID (as in e.g. 2001:db8::192:0:2:1).
For obvious reasons, the search space for addresses following this For obvious reasons, the search space for addresses following this
pattern is that of the corresponding IPv4 prefix (or twice the size pattern is that of the corresponding IPv4 prefix (or twice the size
of that search space if both forms of "IPv4-based addresses" are to of that search space if both forms of "IPv4-based addresses" are to
be searched). be searched).
3.1.3.3. Service-port Addresses 3.1.3.3. Service-port Addresses
Address following this pattern include the service port 8e.g., 80 for Address following this pattern include the service port, e.g., 80 for
HTTP) in the lowest-order byte of the IID, and set the rest of the HTTP, or perhaps 80a, 80b, etc where multiple HTTP servers live in
IID to zero. There are a number of variants for this address one subnet) in the lowest-order byte of the IID, and set the rest of
the IID to zero. There are a number of variants for this address
pattern: pattern:
o The lowest-order 16-bit word may contain the service port, and the o The lowest-order 16-bit word may contain the service port, and the
second lowest-order 16-bit word may be set to a number in the second lowest-order 16-bit word may be set to a number in the
range 0-255 (as in e.g. 2001:db8::1:80). range 0-255 (as in e.g. 2001:db8::1:80).
o The lowest-order 16-bit word may be set to a value in the range o The lowest-order 16-bit word may be set to a value in the range
0-255, while the second lowest-order 16-bit word may contain the 0-255, while the second lowest-order 16-bit word may contain the
service port (as in e.g. 2001:db8::80:1). service port (as in e.g. 2001:db8::80:1).
skipping to change at page 11, line 21 skipping to change at page 11, line 44
Some transition/co-existence technologies might be leveraged to Some transition/co-existence technologies might be leveraged to
reduce the target search space of remote address-scanning attacks, reduce the target search space of remote address-scanning attacks,
since they specify how the corresponding IPv6 address must be since they specify how the corresponding IPv6 address must be
generated. For example, in the case of Teredo [RFC4380], the 64-bit generated. For example, in the case of Teredo [RFC4380], the 64-bit
interface identifier is generated from the IPv4 address observed at a interface identifier is generated from the IPv4 address observed at a
Teredo server along with a UDP port number. Teredo server along with a UDP port number.
3.1.5. IPv6 Address Assignment in Real-world Network Scenarios 3.1.5. IPv6 Address Assignment in Real-world Network Scenarios
Table 2 and Table 3 provide a rough summary of the results obtained Table 2, Table 3 and Table 4 provide a summary of the results
by [Malone2008] for IPv6 clients and IPv6 routers, respectively. obtained by [Gont-LACSEC2013] for web servers, nameservers, and
These results are provided mainly for completeness-sake, since they mailservers, resectively. Table 5 provides a rough summary of the
are the most comprehensive address-measurement results that have so results obtained by [Malone2008] for IPv6 routers. Table 6 provides
far been made publicly available. a summary of the results obtained by [Ford2013] for clients.
We note, however, that evolution of IPv6 implementations, changes +---------------+------------+
in the IPv6 address selection policy, etc. since [Malone2008] was | Address type | Percentage |
published might limit (or even obsolete) the validity of these +---------------+------------+
results. | IEEE-based | 1.44% |
+---------------+------------+
| Embedded-IPv4 | 25.41% |
+---------------+------------+
| Embedded-Port | 3.06% |
+---------------+------------+
| ISATAP | 0% |
+---------------+------------+
| Low-byte | 56.88% |
+---------------+------------+
| Byte-pattern | 6.97% |
+---------------+------------+
| Randomized | 6.24% |
+---------------+------------+
+--------------+------------+ Table 2: Measured webserver addresses
| Address type | Percentage |
+--------------+------------+ +---------------+------------+
| SLAAC | 50% | | Address type | Percentage |
+--------------+------------+ +---------------+------------+
| IPv4-based | 20% | | IEEE-based | 0.67% |
+--------------+------------+ +---------------+------------+
| Teredo | 10% | | Embedded-IPv4 | 22.11% |
+--------------+------------+ +---------------+------------+
| Low-byte | 8% | | Embedded-Port | 6.48% |
+--------------+------------+ +---------------+------------+
| Privacy | 6% | | ISATAP | 0% |
+--------------+------------+ +---------------+------------+
| Wordy | <1% | | Low-byte | 56.58% |
+--------------+------------+ +---------------+------------+
| Other | <1% | | Byte-pattern | 11.07% |
+--------------+------------+ +---------------+------------+
| Randomized | 3.09% |
+---------------+------------+
Table 3: Measured nameserver addresses
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 0.48% |
+---------------+------------+
| Embedded-IPv4 | 4.02% |
+---------------+------------+
| Embedded-Port | 1.07% |
+---------------+------------+
| ISATAP | 0% |
+---------------+------------+
| Low-byte | 92.65% |
+---------------+------------+
| Byte-pattern | 1.20% |
+---------------+------------+
| Randomized | 0.59% |
+---------------+------------+
Table 4: Measured mailserver addresses
Table 2: Measured client addresses
+--------------+------------+ +--------------+------------+
| Address type | Percentage | | Address type | Percentage |
+--------------+------------+ +--------------+------------+
| Low-byte | 70% | | Low-byte | 70% |
+--------------+------------+ +--------------+------------+
| IPv4-based | 5% | | IPv4-based | 5% |
+--------------+------------+ +--------------+------------+
| SLAAC | 1% | | SLAAC | 1% |
+--------------+------------+ +--------------+------------+
| Wordy | <1% | | Wordy | <1% |
+--------------+------------+ +--------------+------------+
| Privacy | <1% | | Randomized | <1% |
+--------------+------------+ +--------------+------------+
| Teredo | <1% | | Teredo | <1% |
+--------------+------------+ +--------------+------------+
| Other | <1% | | Other | <1% |
+--------------+------------+ +--------------+------------+
Table 3: Measured router addresses Table 5: 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% |
+---------------+------------+
Table 6: Measured client addresses
It should be clear from these measurements that a very high It should be clear from these measurements that a very high
percentage of host and router addresses follow very specific percentage of host and router addresses follow very specific
patterns. patterns.
Table 6 shows that while around 70% of clients observed in this
measurement appear to be using privacy addresses, there are still a
significant amount exposing IEEE-based addresses, and addresses using
embedded IPv4 (thus also revealing IPv4 addresses).
3.2. IPv6 Address Scanning of Remote Networks 3.2. IPv6 Address Scanning of Remote Networks
While in IPv4 networks attackers have been able to get away with While in IPv4 networks attackers have been able to get away with
"brute force" scanning attacks (thanks to the reduced search space), "brute force" scanning attacks (thanks to the reduced search space),
successfully performing a brute-force scan of an entire /64 network successfully performing a brute-force scan of an entire /64 network
would be infeasible. As a result, it is expected that attackers will would be infeasible. As a result, it is expected that attackers will
leverage the IPv6 address patterns discussed in Section 3.1 to reduce leverage the IPv6 address patterns discussed in Section 3.1 to reduce
the IPv6 address search space. the IPv6 address search space.
IPv6 address scanning of remote area networks should consider an IPv6 address scanning of remote area networks should consider an
skipping to change at page 14, line 29 skipping to change at page 16, line 34
specific patterns). However, the aforementioned attempt probably specific patterns). However, the aforementioned attempt probably
still falls into the category of "rudimentary". still falls into the category of "rudimentary".
3.4.2. Local IPv6 Network Scanners 3.4.2. Local IPv6 Network Scanners
There are a variety of publicly-available local IPv6 network There are a variety of publicly-available local IPv6 network
scanners: scanners:
Current versions of nmap [nmap2012] implement this functionality Current versions of nmap [nmap2012] implement this functionality
THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool that THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool (alive6) that
implements this functionality implements this functionality
SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6)
that implements this functionality that implements this functionality
3.5. Mitigations 3.5. Mitigations
IPv6 address-scanning attacks can be mitigated in a number of ways. IPv6 address-scanning attacks can be mitigated in a number of ways.
A non-exhaustive list of the possible mitigations includes: A non-exhaustive list of the possible mitigations includes:
skipping to change at page 15, line 6 skipping to change at page 17, line 11
o Employing Intrusion Prevention Systems (IPS) at the perimeter, o Employing Intrusion Prevention Systems (IPS) at the perimeter,
such that address scanning attacks can be mitigated. such that address scanning attacks can be mitigated.
o If virtual machines are employed, and "resistance" to address o If virtual machines are employed, and "resistance" to address
scanning attacks is deemed as desirable, manually-configured MAC scanning attacks is deemed as desirable, manually-configured MAC
addresses can be employed, such that even if the virtual machines addresses can be employed, such that even if the virtual machines
employ IEEE-derived IIDs, they are generated from non-predictable employ IEEE-derived IIDs, they are generated from non-predictable
MAC addresses. MAC addresses.
o When using DHCPv6, avoid use of sequential addresses. Ideally,
the DHCPv6 server would allocate random addresses from a large
pool.
It should be noted that some of the aforementioned mitigations are It should be noted that some of the aforementioned mitigations are
operational, while others depend on the availability of specific operational, while others depend on the availability of specific
features (such as [I-D.ietf-6man-stable-privacy-addresses] on the features (such as [I-D.ietf-6man-stable-privacy-addresses] on the
corresponding nodes. corresponding nodes.
Additionally, while some resistance to address scanning attacks is Additionally, while some resistance to address scanning attacks is
generally desirable (particularly when lightweight mitigations are generally desirable (particularly when lightweight mitigations are
available), there are scenarios in which mitigation of some address- available), there are scenarios in which mitigation of some address-
scanning vectors is unlikely to be a high-priority (if at all scanning vectors is unlikely to be a high-priority (if at all
possible). possible).
skipping to change at page 16, line 31 skipping to change at page 18, line 31
generally less reliable and more time/traffic consuming than mapping generally less reliable and more time/traffic consuming than mapping
nodes with predictable IPv6 addresses). nodes with predictable IPv6 addresses).
4.2. DNS Zone Transfers 4.2. DNS Zone Transfers
A DNS zone transfer can readily provide information about potential A DNS zone transfer can readily provide information about potential
attack targets. Restricting zone transfers is thus probably more attack targets. Restricting zone transfers is thus probably more
important for IPv6, even if it is already good practice to restrict important for IPv6, even if it is already good practice to restrict
them in the IPv4 world. them in the IPv4 world.
4.2.1. DNS Brute Forcing
Attakers may employ DNS brute-forcing techniques by testing for the
presence of DNS AAAA records against commonly used host names.
4.3. DNS Reverse Mappings 4.3. DNS Reverse Mappings
An interesting technique that employs DNS reverse mappings for An interesting technique that employs DNS reverse mappings for
network reconnaissance has been recently disclosed [van-Dijk]. network reconnaissance has been recently disclosed [van-Dijk].
Essentially, the attacker walks through the "ip6.arpa" zone looking Essentially, the attacker walks through the "ip6.arpa" zone looking
up PTR records, in the hopes of learning the IPv6 addresses of hosts up PTR records, in the hopes of learning the IPv6 addresses of hosts
in a given target network (assuming that the reverse mappings have in a given target network (assuming that the reverse mappings have
been configured, of course). What is most interesting about this been configured, of course). What is most interesting about this
technique is that it can greatly reduce the IPv6 address search technique is that it can greatly reduce the IPv6 address search
space. space.
skipping to change at page 20, line 9 skipping to change at page 22, line 9
Public mailing-list archives or Usenet news messages archives may Public mailing-list archives or Usenet news messages archives may
prove a useful channel for an attacker, since hostnames and/or IPv6 prove a useful channel for an attacker, since hostnames and/or IPv6
addresses could be easily obtained by inspection of the (many) addresses could be easily obtained by inspection of the (many)
"Received from:" or other header lines in the archived email or "Received from:" or other header lines in the archived email or
Usenet news messages. Usenet news messages.
7. Application Participation 7. Application Participation
Peer-to-peer applications often include some centralized server which Peer-to-peer applications often include some centralized server which
coordinates the transfer of data between peers. For example, coordinates the transfer of data between peers. For example,
BitTorrent builds swarms of nodes that exchange chunks of files, with BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks
a tracker passing information about peers with available chunks of of files, with a tracker passing information about peers with
data between the peers. Such applications may offer an attacker a available chunks of data between the peers. Such applications may
source of peer addresses to probe. offer an attacker a source of peer addresses to probe.
8. Inspection of the IPv6 Neighbor Cache and Routing Table 8. Inspection of the IPv6 Neighbor Cache and Routing Table
Information about other systems connected to the local network might Information about other systems connected to the local network might
be readily available from the Neighbor Cache [RFC4861] and/or the be readily available from the Neighbor Cache [RFC4861] and/or the
routing table of any system connected to such network. routing table of any system connected to such network.
While the requirement of having "login" access to a system in the While the requirement of having "login" access to a system in the
target network may limit the applicability of this technique, there target network may limit the applicability of this technique, there
are a number of scenarios in which this technique might be of use. are a number of scenarios in which this technique might be of use.
skipping to change at page 27, line 39 skipping to change at page 29, line 39
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-06
(work in progress), April 2013.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
[I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-10
(work in progress), June 2013.
14.2. Informative References 14.2. Informative References
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008.
[I-D.gont-6man-ipv6-smurf-amplifier] [I-D.gont-6man-ipv6-smurf-amplifier]
Gont, F. and W. Liu, "Security Implications of IPv6 Gont, F. and W. Liu, "Security Implications of IPv6
Options of Type 10xxxxxx", Options of Type 10xxxxxx",
draft-gont-6man-ipv6-smurf-amplifier-03 (work in draft-gont-6man-ipv6-smurf-amplifier-03 (work in
progress), March 2013. progress), March 2013.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
[V6-WORMS] [V6-WORMS]
Bellovin, S., Cheswick, B., and A. Keromytis, "Worm Bellovin, S., Cheswick, B., and A. Keromytis, "Worm
propagation strategies in an IPv6 Internet", ;login:, propagation strategies in an IPv6 Internet", ;login:,
pages 70-76, February 2006, pages 70-76, February 2006,
<https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>. <https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>.
skipping to change at page 29, line 19 skipping to change at page 31, line 19
list, 2010, <http://mailman.nanog.org/pipermail/nanog/ list, 2010, <http://mailman.nanog.org/pipermail/nanog/
2010-September/025049.html>. 2010-September/025049.html>.
[Gont-DEEPSEC2011] [Gont-DEEPSEC2011]
Gont, "Results of a Security Assessment of the Internet Gont, "Results of a Security Assessment of the Internet
Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Protocol version 6 (IPv6)", DEEPSEC 2011 Conference,
Vienna, Austria, November 2011, <http:// Vienna, Austria, November 2011, <http://
www.si6networks.com/presentations/deepsec2011/ www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>. fgont-deepsec2011-ipv6-security.pdf>.
[Gont-LACSEC2013]
Gont, "IPv6 Network Reconnaissance: Theory & Practice",
LACSEC 2013 Conference, Medellin, Colombia, May 2013,
<http://www.si6networks.com/presentations/lacnic19/
lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.
[Ford2013]
Ford, "IPv6 Address Analysis - Privacy In, Transition
Out", 2013, <http://www.internetsociety.org/blog/2013/05/
ipv6-address-analysis-privacy-transition-out>.
[THC-IPV6] [THC-IPV6]
"THC-IPV6", <http://www.thc.org/thc-ipv6/>. "THC-IPV6", <http://www.thc.org/thc-ipv6/>.
[IPv6-Toolkit] [IPv6-Toolkit]
"SI6 Networks' IPv6 Toolkit", "SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[BitTorrent]
"BitTorrent", <http://en.wikipedia.org/wiki/BitTorrent>.
[van-Dijk] [van-Dijk]
van Dijk, P., "Finding v6 hosts by efficiently mapping van Dijk, P., "Finding v6 hosts by efficiently mapping
ip6.arpa", <http://7bits.nl/blog/2012/03/26/ ip6.arpa", <http://7bits.nl/blog/2012/03/26/
finding-v6-hosts-by-efficiently-mapping-ip6-arpa>. finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.
Appendix A. Implementation of a full-fledged IPv6 address-scanning tool Appendix A. Implementation of a full-fledged IPv6 address-scanning tool
This section describes the implementation of a full-fledged IPv6 This section describes the implementation of a full-fledged IPv6
address scanning tool. Appendix A.1 discusses the selection of host address scanning tool. Appendix A.1 discusses the selection of host
probes. Appendix A.2 describes the implementation of an IPv6 address probes. Appendix A.2 describes the implementation of an IPv6 address
 End of changes. 38 change blocks. 
108 lines changed or deleted 219 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/