draft-ietf-opsec-ipv6-host-scanning-08.txt   rfc7707.txt 
opsec F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft Huawei Technologies Request for Comments: 7707 Huawei Technologies
Obsoletes: 5157 (if approved) T. Chown Obsoletes: 5157 T. Chown
Intended status: Informational University of Southampton Category: Informational Jisc
Expires: February 29, 2016 August 28, 2015 ISSN: 2070-1721 March 2016
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-08
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. An IPv6 subnet of size /64 can (in theory) accommodate counterpart. An IPv6 subnet of size /64 can (in theory) accommodate
approximately 1.844 * 10^19 hosts, thus resulting in a much lower approximately 1.844 * 10^19 hosts, thus resulting in a much lower
host density (#hosts/#addresses) than is typical in IPv4 networks, host density (#hosts/#addresses) than is typical in IPv4 networks,
where a site typically has 65,000 or less unique addresses. As a where a site typically has 65,000 or fewer unique addresses. As a
result, it is widely assumed that it would take a tremendous effort result, it is widely assumed that it would take a tremendous effort
to perform address scanning attacks against IPv6 networks, and to perform address-scanning attacks against IPv6 networks; therefore,
therefore brute-force IPv6 address scanning attacks have been IPv6 address-scanning attacks have been considered unfeasible. This
considered unfeasible. This document formally obsoletes RFC 5157, document formally obsoletes RFC 5157, which first discussed this
which first discussed this assumption, by providing further analysis assumption, by providing further analysis on how traditional address-
on how traditional address scanning techniques apply to IPv6 scanning techniques apply to IPv6 networks and exploring some
networks, and exploring some additional techniques that can be additional techniques that can be employed for IPv6 network
employed for IPv6 network reconnaissance. reconnaissance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on February 29, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7707.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 Reconnaissance 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for the Applicability of Network Reconnaissance
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 4. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 6
3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6 4.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6
3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 4.1.1. Stateless Address Autoconfiguration (SLAAC) . . . . . 6
3.1.2. Dynamic Host Configuration Protocol version 6 4.1.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 11
(DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Manually Configured Addresses . . . . . . . . . . . . 12
3.1.3. Manually-configured Addresses . . . . . . . . . . . . 11 4.1.4. IPv6 Addresses Corresponding to
3.1.4. IPv6 Addresses Corresponding to Transition/Co- Transition/Coexistence Technologies . . . . . . . . . 14
existence Technologies . . . . . . . . . . . . . . . 14 4.1.5. IPv6 Address Assignment in Real-World Network
3.1.5. IPv6 Address Assignment in Real-world Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 14 Scenarios . . . . . . . . . . . . . . . . . . . . . . 14
3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17 4.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17
3.2.1. Reducing the subnet ID search space . . . . . . . . . 17 4.2.1. Reducing the Subnet ID Search Space . . . . . . . . . 18
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 18 4.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 19
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 19 4.4. Existing IPv6 Address-Scanning Tools . . . . . . . . . . 20
3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 19 4.4.1. Remote IPv6 Network Address Scanners . . . . . . . . 20
3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 20 4.4.2. Local IPv6 Network Address Scanners . . . . . . . . . 21
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 20 4.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 21
4. Leveraging the Domain Name System (DNS) for Network 4.6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 22
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 21 5. Alternative Methods to Glean IPv6 Addresses . . . . . . . . . 23
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 21 5.1. Leveraging the Domain Name System (DNS) for Network
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 22 Reconnaissance . . . . . . . . . . . . . . . . . . . . . 23
4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 22 5.1.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . 23
4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 22 5.1.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . 23
5. Leveraging Local Name Resolution and Service Discovery 5.1.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . 23
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . 24
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 23 5.2. Leveraging Local Name Resolution and Service Discovery
7. Application Participation . . . . . . . . . . . . . . . . . . 23 Services . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 23 5.3. Public Archives . . . . . . . . . . . . . . . . . . . . . 25
9. Inspection of System Configuration and Log Files . . . . . . 24 5.4. Application Participation . . . . . . . . . . . . . . . . 25
10. Gleaning Information from Routing Protocols . . . . . . . . . 24 5.5. Inspection of the IPv6 Neighbor Cache and Routing Table . 25
11. Gleaning Information from IP Flow Information Export (IPFIX) 24 5.6. Inspection of System Configuration and Log Files . . . . 26
12. Obtaining Network Information with traceroute6 . . . . . . . 24 5.7. Gleaning Information from Routing Protocols . . . . . . . 26
13. Gleaning Information from Network Devices Using SNMP . . . . 25 5.8. Gleaning Information from IP Flow Information Export
14. Obtaining Network Information via Traffic Snooping . . . . . 25 (IPFIX) . . . . . . . . . . . . . . . . . . . . . . . . . 26
15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.9. Obtaining Network Information with traceroute6 . . . . . 26
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5.10. Gleaning Information from Network Devices Using SNMP . . 27
17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.11. Obtaining Network Information via Traffic Snooping . . . 27
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
19.1. Normative References . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
19.2. Informative References . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Implementation of a full-fledged IPv6 address- 8.2. Informative References . . . . . . . . . . . . . . . . . 29
scanning tool . . . . . . . . . . . . . . . . . . . 31 Appendix A. Implementation of a Full-Fledged IPv6 Address-
A.1. Host-probing considerations . . . . . . . . . . . . . . . 31 Scanning Tool . . . . . . . . . . . . . . . . . . . 34
A.2. Implementation of an IPv6 local address-scanning tool . . 33 A.1. Host-Probing Considerations . . . . . . . . . . . . . . . 34
A.3. Implementation of a IPv6 remote address-scanning tool . . 34 A.2. Implementation of an IPv6 Local Address-Scanning Tool . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 A.3. Implementation of an IPv6 Remote Address-Scanning Tool . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
of subtle changes in several aspects of the resulting networks. One subtle changes in several aspects of the resulting networks. One of
of these changes is the reduced host density (the number of hosts these changes is the reduced host density (the number of hosts
divided by the number of addresses) of typical IPv6 subnetworks, when divided by the number of addresses) of typical IPv6 subnetworks, when
compared to their IPv4 counterparts. [RFC5157] describes how this compared to their IPv4 counterparts. [RFC5157] describes how this
significantly lower IPv6 host-density is likely to make classic significantly lower IPv6 host density is likely to make classic
network address scans less feasible, since even by applying various network address-scanning attacks less feasible, since even by
heuristics, the address space to be scanned remains very large. RFC applying various heuristics, the address space to be scanned remains
5157 goes on to describe some alternative methods for attackers to very large. RFC 5157 goes on to describe some alternative methods
glean active IPv6 addresses, and provides some guidance for for attackers to glean active IPv6 addresses and provides some
administrators and implementors, e.g. not using sequential addresses guidance for administrators and implementors, e.g., not using
with DHCPv6. sequential addresses with DHCPv6.
With the benefit of more than five years of additional IPv6 With the benefit of more than five years of additional IPv6
deployment experience, this document formally obsoletes RFC 5157. It deployment experience, this document formally obsoletes RFC 5157. It
emphasises that while scanning attacks are less feasible, they may, emphasizes that while address-scanning attacks are less feasible,
with appropriate heuristics, remain possible. At the time that RFC they may, with appropriate heuristics, remain possible. At the time
5157 was written, observed scans were typically across ports on the that RFC 5157 was written, observed address-scanning attacks were
addresses of discovered servers; since then, evidence that some typically across ports on the addresses of discovered servers; since
classic address scanning is occurring is being witnessed. This text then, evidence that some classic address scanning is occurring is
thus updates the analysis on the feasibility of "traditional" being witnessed. This text thus updates the analysis on the
address-scanning attacks in IPv6 networks, and it explores a number feasibility of address-scanning attacks in IPv6 networks, and it
of additional techniques that can be employed for IPv6 network explores a number of additional techniques that can be employed for
reconnaissance. Practical examples and guidance are also included in IPv6 network reconnaissance. Practical examples and guidance are
the Appendices. also included in the appendices.
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 twofold.
Section 3 analyzes the feasibility of traditional address-scanning Section 4 analyzes the feasibility of address-scanning attacks (e.g.,
attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of ping sweeps) in IPv6 networks and explores a number of possible
possible improvements to such techniques. Appendix A describes how improvements to such techniques. Appendix A describes how the
the aforementioned analysis can be leveraged to produce address- aforementioned analysis can be leveraged to produce address-scanning
scanning tools (e.g. for penetration testing purposes). Section 4 tools (e.g., for penetration testing purposes). Finally, the rest of
analyzes network reconnaissance techniques that leverage the Domain this document discusses a number of miscellaneous techniques that
Name System (DNS). Finally, the rest of this document discusses a could be leveraged for IPv6 network reconnaissance.
number of other miscellaneous techniques that could be leveraged for
IPv6 network reconnaissance.
2. Requirements for the Applicability of Network Reconnaissance 2. Conventions
Throughout this document, we consider that bits are numbered from
left to right, starting at 0, and that bytes are numbered from left
to right, starting at 0.
3. 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 has 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 (or similar access credentials) to the system on require login access (or similar access credentials) to the system on
which the technique is applied. which the technique is applied.
The following table tries to summarize the aforementioned The following table tries to summarize the aforementioned
requirements, and serves 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 | | Remote Address Scanning (Section 4.2) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Remote Address scans (Section 3.2) | No | No | | Local Address Scanning (Section 4.3) | Yes | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| DNS Advertised Hosts (Section 4.1) | No | No | | DNS Advertised Hosts (Section 5.1.1) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| DNS Zone Transfers (Section 4.2) | No | No | | DNS Zone Transfers (Section 5.1.2) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| DNS reverse mappings (Section 4.4) | No | No | | DNS Brute Forcing (Section 5.1.3) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Public archives (Section 6) | No | No | | DNS Reverse Mappings (Section 5.1.4) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Application Participation (Section 7) | No | No | | Leveraging Local Name Resolution and | Yes | No |
| Service Discovery Services (Section 5.2) | | |
+---------------------------------------------+----------+----------+
| Public Archives (Section 5.3) | No | No |
+---------------------------------------------+----------+----------+
| Application Participation (Section 5.4) | No | No |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Inspection of the IPv6 Neighbor Cache and | No | Yes | | Inspection of the IPv6 Neighbor Cache and | No | Yes |
| Routing Table (Section 8) | | | | Routing Table (Section 5.5) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Inspecting System Configuration and Log | No | Yes | | Inspecting System Configuration and Log | No | Yes |
| Files (Section 9) | | | | Files (Section 5.6) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning information from Routing Protocols | Yes | No | | Gleaning Information from Routing Protocols | Yes | No |
| (Section 10) | | | | (Section 5.7) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning Information from IP Flow | No | Yes | | Gleaning Information from IP Flow | No | Yes |
| Information Export (IPFIX) (Section 11) | | | | Information Export (IPFIX) (Section 5.8) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Obtaining Network Information with | No | No | | Obtaining Network Information with | No | No |
| traceroute6 (Section 12) | | | | traceroute6 (Section 5.9) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Gleaning Information from Network Devices | No | Yes | | Gleaning Information from Network Devices | No | Yes |
| Using SNMP | | | | Using SNMP (Section 5.10) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
| Obtaining Network Information via Traffic | Yes | No | | Obtaining Network Information via Traffic | Yes | No |
| Snooping | | | | Snooping (Section 5.11) | | |
+---------------------------------------------+----------+----------+ +---------------------------------------------+----------+----------+
Table 1: Requirements for the Applicability of Network Reconnaissance Table 1: Requirements for the Applicability of
Techniques Network Reconnaissance Techniques
3. IPv6 Address Scanning 4. 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 4.1 provides
essential analysis of how address configuration is performed in IPv6, an essential analysis of how address configuration is performed in
identifying patterns in IPv6 addresses that can be leveraged to IPv6, 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 scanning attacks. Section 4.2 discusses IPv6 address scanning of
previous sub-sections can be incorporated into into a fully-fledged remote networks. Section 4.3 discusses IPv6 address scanning of
IPv6 address scanning tool. Section 3.5 provides advice on how to local networks. Section 4.4 discusses existing IPv6 address-scanning
mitigate IPv6 address scans. tools. Section 4.5 provides advice on how to mitigate IPv6 address-
scanning attacks. Finally, Appendix A discusses how the insights
obtained in the following subsections can be incorporated into a
fully fledged IPv6 address-scanning tool.
3.1. Address Configuration in IPv6 4.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 Stateless Address Autoconfiguration (SLAAC) [RFC4862] and Dynamic
(Dynamic Host Configuration Protocol version 6) [RFC3315]. SLAAC is Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Support for
the mandatory mechanism for automatic address configuration, while SLAAC for automatic address configuration is mandatory, while support
DHCPv6 is optional - however, most current versions of general- for DHCPv6 is optional -- however, most current versions of general-
purpose operating systems support both. In addition to automatic purpose operating systems support both. In addition to automatic
address configuration, hosts, typically servers, may employ manual address configuration, hosts, typically servers, may employ manual
configuration, in which all the necessary information is manually configuration, in which all the necessary information is manually
entered by the host or network administrator into configuration files entered by the host or network administrator into configuration files
at the host. at the host.
The following subsections describe each of the possible configuration The following subsections describe each of the possible configuration
mechanisms/approaches in more detail. mechanisms/approaches in more detail.
3.1.1. StateLess Address Auto-Configuration (SLAAC) 4.1.1. Stateless Address Autoconfiguration (SLAAC)
The basic idea behind SLAAC is that every host joining a network will The basic idea behind SLAAC is that every host joining a network will
send a multicasted solicitation requesting network configuration send a multicasted solicitation requesting network configuration
information, and local routers will respond to the request providing information, and local routers will respond to the request providing
the necessary information. SLAAC employs two different ICMPv6 the necessary information. SLAAC employs two different ICMPv6
message types: ICMPv6 Router Solicitation and ICMPv6 Router message types: ICMPv6 Router Solicitation and ICMPv6 Router
Advertisement messages. Router Solicitation messages are employed by Advertisement messages. Router Solicitation messages are employed by
hosts to query local routers for configuration information, while hosts to query local routers for configuration information, while
Router Advertisement messages are employed by local routers to convey Router Advertisement messages are employed by local routers to convey
the requested information. the requested information.
Router Advertisement messages convey a plethora of network Router Advertisement messages convey a plethora of network
configuration information, including the IPv6 prefix that should be configuration information, including the IPv6 prefix that should be
used for configuring IPv6 addresses on the local network. For each used for configuring IPv6 addresses on the local network. For each
local prefix learned from a Router Advertisement message, an IPv6 local prefix learned from a Router Advertisement message, an IPv6
address is configured by appending a locally-generated Interface address is configured by appending a locally generated Interface
Identifier (IID) to the corresponding IPv6 prefix. Identifier (IID) to the corresponding IPv6 prefix.
The following subsections describe currently-deployed policies for The following subsections describe currently deployed policies for
generating the IIDs used with SLAAC. generating the IIDs used with SLAAC.
3.1.1.1. Interface-Identifiers Embedding IEEE Identifiers 4.1.1.1. Interface Identifiers Embedding IEEE Identifiers
The traditional SLAAC interface identifiers are based on the link- The traditional SLAAC IIDs are based on the link-layer address of the
layer address of the corresponding network interface card. For corresponding network interface card. For example, in the case of
example, in the case of Ethernet addresses, the IIDs are constructed Ethernet addresses, the IIDs are constructed as follows:
as follows:
1. The "Universal" bit (bit 6, from left to right) of the address is 1. The "Universal" bit (bit 6, from left to right) of the address is
set to 1 set to 1.
2. The word 0xfffe is inserted between the OUI (Organizationally
Unique Identifier) and the rest of the Ethernet address
For example, the MAC address 00:1b:38:83:88:3c would lead to the IID
021b:38ff:fe83:883c.
NOTE: 2. The word 0xfffe is inserted between the Organizationally Unique
[RFC7136] notes that all bits of an IID should be treated as Identifier (OUI) and the rest of the Ethernet address.
"opaque" bits. Furthermore, [I-D.ietf-6man-default-iids] is
currently in the process of changing the default IID generation
scheme to [RFC7217]. Therefore, the traditional IIDs based on
link-layer addresses are expected to become less common over time.
Throughout this document we consider that bits are numbered from For example, the Media Access Control (MAC) address 00:1b:38:83:88:3c
left to right, starting at 0, and that bytes are numbered from would lead to the IID 021b:38ff:fe83:883c.
left to right, starting at 0.
A number of considerations should be made about these identifiers. A number of considerations should be made about these identifiers.
Firstly, two bytes (bytes 3-4) of the resulting address always have a Firstly, one 16-bit word (bytes 3-4) of the resulting address always
fixed value (0xff, 0xfe), thus reducing the search space for the IID. has a fixed value (0xfffe), thus reducing the search space for the
Secondly, the first three bytes of these identifiers correspond to IID. Secondly, the high-order three bytes of the IID correspond to
the OUI of the network interface card vendor. Since not all possible the OUI of the network interface card vendor. Since not all possible
OUIs have been assigned, this further reduces the IID search space. OUIs have been assigned, this further reduces the IID search space.
Furthermore, of the assigned OUIs, many could be regarded as Furthermore, of the assigned OUIs, many could be regarded as
corresponding to legacy devices, and thus unlikely to be used for corresponding to legacy devices and thus are unlikely to be used for
Internet-connected IPv6-enabled systems, yet further reducing the IID Internet-connected IPv6-enabled systems, yet further reducing the IID
search space. Finally, in some scenarios it could be possible to search space. Finally, in some scenarios, it could be possible to
infer the OUI in use by the target network devices, yet narrowing infer the OUI in use by the target network devices, yet narrowing
down the possible IIDs even more. down the possible IIDs even more.
NOTE:
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 Furthermore, if just one host address is detected or known within a
subnet, it is not unlikely that, if systems were ordered in a batch, subnet, it is not unlikely that, if systems were ordered in a batch,
that they may have sequential MAC addresses. Additionally, given a they may have sequential MAC addresses. Additionally, given a MAC
MAC address observed in one subnet, sequential or nearby MAC address observed in one subnet, sequential or nearby MAC addresses
addresses may be seen in other subnets in the same site. may be seen in other subnets in the same site.
3.1.1.2. Interface-Identifiers of Virtualization Technologies NOTE:
[RFC7136] notes that all bits of an IID should be treated as
"opaque" bits. Furthermore, [DEFAULT-IIDS] is currently in the
process of changing the default IID generation scheme to align
with [RFC7217] (as described below in Section 4.1.1.5), such that
IIDs are semantically opaque and do not follow any patterns.
Therefore, the traditional IIDs based on link-layer addresses are
expected to become less common over time.
4.1.1.2. Interface Identifiers of Virtualization Technologies
IIDs resulting from virtualization technologies can be considered a IIDs resulting from virtualization technologies can be considered a
specific sub-case of IIDs embedding IEEE identifiers (please see specific subcase of IIDs embedding IEEE identifiers (please see
Section 3.1.1.1): they employ IEEE identifiers, but part of the lower Section 4.1.1.1): they employ IEEE identifiers, but part of the IID
half of the IID has specific patterns. The following subsections has specific patterns. The following subsections describe IIDs of
describe IIDs of some popular virtualization technologies. some popular virtualization technologies.
3.1.1.2.1. VirtualBox 4.1.1.2.1. VirtualBox
All automatically-generated MAC addresses in VirtualBox virtual All automatically generated MAC addresses in VirtualBox virtual
machines employ the OUI 08:00:27 [VBox2011]. This means that all machines employ the OUI 08:00:27 [VBox2011]. This means that all
SLAAC-produced addresses will have an IID of the form addresses resulting from traditional SLAAC will have an IID of the
a00:27ff:feXX:XXXX, thus effectively reducing the IID search space form a00:27ff:feXX:XXXX, thus effectively reducing the IID search
from 64 bits to 24 bits. space from 64 bits to 24 bits.
3.1.1.2.2. VMWare ESX server 4.1.1.2.2. VMware ESX Server
VMWare ESX server (versions 1.0 to 2.5) provides yet a more The VMware ESX server (versions 1.0 to 2.5) provides yet a more
interesting example. Automatically-generated MAC addresses have the interesting example. Automatically generated MAC addresses have the
following pattern [vmesx2011]: following pattern [vmesx2011]:
1. The OUI is set to 00:05:69 1. The OUI is set to 00:05:69.
2. The next 16 bits of the MAC address are set to the same value as 2. The next 16 bits of the MAC address are set to the same value as
the last 16 bits of the console operating system's primary IPv4 the last 16 bits of the console operating system's primary IPv4
address address.
3. The final 8 bits of the MAC address are set to a hash value based 3. The final 8 bits of the MAC address are set to a hash value based
on the name of the virtual machine's configuration file. on the name of the virtual machine's configuration file.
This means that, assuming the console operating system's primary IPv4 This means that, assuming the console operating system's primary IPv4
address is known, the IID search space is reduced from 64 bits to 8 address is known, the IID search space is reduced from 64 bits to 8
bits. bits.
On the other hand, manually-configured MAC addresses in VMWare ESX On the other hand, manually configured MAC addresses in the VMware
server employ the OUI 00:50:56, with the low-order three bytes being ESX server employ the OUI 00:50:56, with the low-order three bytes of
in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware the MAC address being in the range 00:00:00-3F:FF:FF (to avoid
products). Therefore, even in the case of manually-configured MAC conflicts with other VMware products). Therefore, even in the case
addresses, the IID search space is reduced from 64 bits to 22 bits. of manually configured MAC addresses, the IID search space is reduced
from 64 bits to 22 bits.
3.1.1.2.3. VMWare vSphere 4.1.1.2.3. VMware vSphere
VMWare vSphere [vSphere] supports these default MAC address VMware vSphere [vSphere] supports these default MAC address
generation algorithms: generation algorithms:
o Generated addresses o Generated addresses
* Assigned by vCenter Server * Assigned by the vCenter server
* Assigned by the ESXi host * Assigned by the ESXi host
o Manually-configured addresses o Manually configured addresses
By default, MAC addresses assigned by the vCenter server use the OUI By default, MAC addresses assigned by the vCenter server use the OUI
00:50:56, and have the format 00:50:56:XX:YY:ZZ, where XX is 00:50:56 and have the format 00:50:56:XX:YY:ZZ, where XX is
calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)), calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)),
and XX and YY are random two-digit hexadecimal numbers. Thus, the and XX and YY are random two-digit hexadecimal numbers. Thus, the
possible IID range is 00:50:56:80:00:00-00:50:56:BF:FF:FF, and possible IID range is 00:50:56:80:00:00-00:50:56:BF:FF:FF; therefore,
therefore the search space for the resulting SLAAC addresses will be the search space for the resulting SLAAC addresses will be 22 bits.
24 bits.
MAC addresses generated by the ESXi host use the OUI 00:0C:29, and MAC addresses generated by the ESXi host use the OUI 00:0C:29 and
have the format 00:0C:29:XX:YY:ZZ, where XX, YY, and ZZ are the have the format 00:0C:29:XX:YY:ZZ, where XX, YY, and ZZ are the last
lastthree octets in hexadecimal format of the virtual machine UUID three octets in hexadecimal format of the virtual machine Universally
(based on a hash calculated by using the UUID of the ESXi physical Unique Identifier (UUID) (based on a hash calculated with the UUID of
machine and the path to a configuration file). Thus, the MAC the ESXi physical machine and the path to a configuration file).
addresses will be in the range 00:0C:29:XX:YY:ZZ-00:0C:29:FF:FF:FF, Thus, the MAC addresses will be in the range
and therefore the search space for the resulting SLAAC addresses will 00:0C:29:00:00:00-00:0C:29:FF:FF:FF; therefore, the search space for
be 22 bits. the resulting SLAAC addresses will be 24 bits.
Finally, manually-configured MAC addresses employ the OUI 00:50:56, Finally, manually configured MAC addresses employ the OUI 00:50:56,
with the low-order three bytes being in the range 0x000000-0x3fffff with the low-order three bytes being in the range 00:00:00-3F:FF:FF
(to avoid conflicts with other VMware products). Therefore, (to avoid conflicts with other VMware products). Therefore, the
therefore the search space for the resulting SLAAC addresses will be resulting MAC addresses will be in the range
22 bits. 00:50:56:00:00:00-00:50:56:3F:FF:FF, and the search space for the
corresponding SLAAC addresses will be 22 bits.
3.1.1.3. Temporary Addresses 4.1.1.3. Temporary Addresses
Privacy concerns [Gont-DEEPSEC2011] Privacy concerns [Gont-DEEPSEC2011] [RFC7721] regarding IIDs
[I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface embedding IEEE identifiers led to the introduction of "Privacy
identifiers embedding IEEE identifiers led to the introduction of Extensions for Stateless Address Autoconfiguration in IPv6"
"Privacy Extensions for Stateless Address Auto-configuration in IPv6"
[RFC4941], also known as "temporary addresses" or "privacy [RFC4941], also known as "temporary addresses" or "privacy
addresses". Essentially, "temporary addresses" produce random addresses". Essentially, "temporary addresses" produce random
addresses by concatenating a random identifier to the auto- addresses by concatenating a random identifier to the
configuration IPv6 prefix advertised in a Router Advertisement. autoconfiguration IPv6 prefix advertised in a Router Advertisement
message.
NOTE:
In addition to their unpredictability, these addresses are In addition to their unpredictability, these addresses are
typically short-lived, such that even if an attacker were to learn typically short-lived, such that even if an attacker were to learn
one of these addresses, they would be of use for a limited period of one of these addresses, they would be of use for a limited
of time. A typical implementation may keep a temporary address period of time. A typical implementation may keep a temporary
preferred for 24 hours, and configured but deprecated for seven address preferred for 24 hours, and configured but deprecated for
days. seven days.
It is important to note that "temporary addresses" are generated in It is important to note that "temporary addresses" are generated in
addition to traditional SLAAC addresses (i.e., based on IEEE addition to the stable addresses [RFC7721] (such as the traditional
identifiers): traditional SLAAC addresses are meant to be employed SLAAC addresses based on IEEE identifiers): stable SLAAC addresses
for "server-like" inbound communications, while "temporary addresses" are meant to be employed for "server-like" inbound communications,
are meant to be employed for "client-like" outbound communications. while "temporary addresses" are meant to be employed for "client-
This means that implementation/use of "temporary addresses" does not like" outbound communications. This means that implementation/use of
prevent an attacker from leveraging the predictability of traditional "temporary addresses" does not prevent an attacker from leveraging
SLAAC addresses, since "temporary addresses" are generated in the predictability of stable SLAAC addresses, since "temporary
addition to (rather than as a replacement of) the traditional SLAAC addresses" are generated in addition to (rather than as a replacement
addresses derived from e.g. IEEE identifiers. of) the stable SLAAC addresses (such as those derived from IEEE
identifiers).
The benefit that temporary addresses offer in this context is that The benefit that temporary addresses offer in this context is that
they reduce the exposure of the SLAAC address to any third parties they reduce the exposure of the host addresses to any third parties
that may observe traffic sent from a host where temporary addresses that may observe traffic sent from a host where temporary addresses
are enabled and used by default. But, in the absence of firewall are enabled and used by default. But, in the absence of firewall
protection for the host, its SLAAC address remains liable to be protection for the host, its stable SLAAC address remains liable to
scanned from offsite. be scanned from off-site.
3.1.1.4. Constant, semantically opaque IIDs 4.1.1.4. Constant, Semantically Opaque IIDs
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 believed to be an implementation of RFC The aforementioned scheme is believed to be an implementation of RFC
4941 [RFC4941], but without regenerating the addresses over time. 4941 [RFC4941], but without regenerating the addresses over time.
The resulting interface IDs are constant across system bootstraps, The resulting IIDs are constant across system bootstraps, and also
and also constant across networks. 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 NOTE:
networks, these addresses may still be leveraged for host tracking However, since the resulting IIDs are constant across networks,
purposes [RFC7217] these addresses may still be leveraged for host-tracking purposes
[I-D.ietf-6man-ipv6-address-generation-privacy]. [RFC7217] [RFC7721].
The benefit of this scheme is thus that the host may be less readily 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 detected by applying heuristics to an address-scanning attack, but,
concurrent use of temporary addresses, the host is liable to be in the absence of concurrent use of temporary addresses, the host is
tracked across visited networks. liable to be tracked across visited networks.
3.1.1.5. Stable, semantically opaque IIDs 4.1.1.5. Stable, Semantically Opaque IIDs
In response to the predictability issues discussed in Section 3.1.1.1 In response to the predictability issues discussed in Section 4.1.1.1
and the privacy issues discussed in and the privacy issues discussed in [RFC7721], the IETF has
[I-D.ietf-6man-ipv6-address-generation-privacy], the IETF has standardized (in [RFC7217]) a method for generating IPv6 IIDs to be
standardized (in [RFC7217]) a method for generating IPv6 Interface used with IPv6 SLAAC, such that addresses configured using this
Identifiers to be used with IPv6 Stateless Address Autoconfiguration method are stable within each subnet, but the IIDs change when hosts
(SLAAC), such that addresses configured using this method are stable
within each subnet, but the Interface Identifier changes when hosts
move from one subnet to another. The aforementioned method is meant move from one subnet to another. The aforementioned method is meant
to be an alternative to generating Interface Identifiers based on to be an alternative to generating IIDs based on IEEE identifiers,
IEEE identifiers, such that the benefits of stable addresses can be such that the benefits of stable addresses can be achieved without
achieved without sacrificing the privacy of users. sacrificing the privacy of users.
Implementation of this method (in replacement of Interface Implementation of this method (in replacement of IIDs based on IEEE
Identifiers based on IEEE identifiers) would eliminate any patterns identifiers) eliminates any patterns from the IID, thus benefiting
from the Interface ID, thus benefiting user privacy and reducing the user privacy and reducing the ease with which addresses can be
ease with which addresses can be scanned. scanned.
3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) 4.1.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
DHC DHCPv6 can be employed as a stateful address configuration DHCPv6 can be employed as a stateful address configuration mechanism,
mechanism, in which a server (the DHCPv6 server) leases IPv6 in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6
addresses to IPv6 hosts. As with the IPv4 counterpart, addresses are hosts. As with the IPv4 counterpart, addresses are assigned
assigned according to a configuration-defined address range and according to a configuration-defined address range and policy, with
policy, with some DHCPv6 servers assigning addresses sequentially, some DHCPv6 servers assigning addresses sequentially, from a specific
from a specific range. In such cases, addresses tend to be range. In such cases, addresses tend to be predictable.
predictable.
NOTE:
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 - (sequentially) assign addresses from the range 2001:db8::1 -
2001:db8::100. 2001: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. RFC 5157 be reduced from the original 64 bits to 8 or 16 bits. [RFC5157]
recommended that DHCPv6 instead issue addresses randomly from a large recommended that DHCPv6 instead issue addresses randomly from a large
pool; that advice is repeated here. pool; that advice is repeated here. [IIDS-DHCPv6] specifies an
[I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that algorithm that can be employed by DHCPv6 servers to produce stable
can be employed by DHCPv6 servers to produce stable addresses which addresses that do not follow any specific pattern, thus resulting in
do not follow any specific pattern, thus resulting in an IID search an IID search space of 64 bits.
space of 64 bits.
3.1.3. Manually-configured Addresses 4.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
any value in the range 1 - 2^64, for the sake of simplicity (i.e., any value in the range 1 - 2^64, for the sake of simplicity (i.e.,
ease of remembering) they tend to select addresses with one of the ease of remembering), they tend to select addresses with one of the
following patterns: following patterns:
o "low-byte" addresses: in which most of the bytes of the IID are o low-byte addresses: in which most of the bytes of the IID are set
set to 0 (except for the least significant byte). to 0 (except for the least significant byte)
o IPv4-based addresses: in which the IID embeds the IPv4 address of o IPv4-based addresses: in which the IID embeds the IPv4 address of
the network interface (as in 2001:db8::192.0.2.1) the network interface (as in 2001:db8::192.0.2.1)
o "service port" addresses: in which the IID embeds the TCP/UDP o service port addresses: in which the IID embeds the TCP/UDP
service port of the main service running on that node (as in service port of the main service running on that node (as in
2001:db8::80 or 2001:db8::25) 2001:db8::80 or 2001:db8::25)
o wordy addresses: which encode words (as in 2001:db8::dead:beef) o wordy addresses: which encode words (as in 2001:db8::bad:cafe)
Each of these patterns is discussed in detail in the following Each of these patterns is discussed in detail in the following
subsections. subsections.
3.1.3.1. Low-byte Addresses 4.1.3.1. Low-Byte Addresses
The most common form of low-byte addresses is that in which all the The most common form of low-byte addresses is that in which all the
the bytes of the IID (except the least significant bytes) are set to bytes of the IID (except the least significant bytes) are set to zero
zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also common
common to find similar addresses in which the two lowest order 16-bit to find similar addresses in which the two lowest-order 16-bit words
words (from the right to left) are set to small numbers (as in (from the right to left) are set to small numbers (as in
2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to 2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to
find IPv6 addresses in which the second lowest-order 16-bit word find IPv6 addresses in which the second lowest-order 16-bit word
(from right to left) is set to a small value in the range 0-255, (from right to left) is set to a small value in the range
while the lowest-order 16-bit word (from right to left) varies in the 0x0000:0x00ff, while the lowest-order 16-bit word (from right to
range 0-65535. It should be noted that all of these address patterns left) varies in the range 0x0000:0xffff. It should be noted that all
are generally referred to as "low-byte addresses", even when, of these address patterns are generally referred to as "low-byte
strictly speaking, it is not only the lowest-order byte of the IPv6 addresses", even when, strictly speaking, it is not only the lowest-
address that varies from one address to another. order byte of the IPv6 address that varies from one address to
another.
In the worst-case scenario, the search space for this pattern is 2^24 In the worst-case scenario, the search space for this pattern is 2^24
(although most systems can be found by searching 2^16 or even 2^8 (although most systems can be found by searching 2^16 or even 2^8
addresses). addresses).
3.1.3.2. IPv4-based Addresses 4.1.3.2. IPv4-Based Addresses
The most common form of these addresses is that in which an IPv4 The most common form of these addresses is that in which an IPv4
address is encoded in the lowest-order 32 bits of the IPv6 address address is encoded in the lowest-order 32 bits of the IPv6 address
(usually as a result of the notation of addresses in the form (usually as a result of the address notation of the form
2001:db8::192.0.2.1). However, it is also common for administrators 2001:db8::192.0.2.1). However, it is also common for administrators
to encode one byte of the IPv4 address in each of the 16-bit words of to encode each of the bytes of the IPv4 address in each of the 16-bit
the IID (as in e.g. 2001:db8::192:0:2:1). words of the IID (as in, e.g., 2001:db8::192:0:2:1).
Therefore, the search space for addresses following this pattern is Therefore, the search space for addresses following this pattern is
that of the corresponding IPv4 prefix (or twice the size of that that of the corresponding IPv4 prefix (or twice the size of that
search space if both forms of "IPv4-based addresses" are to be search space if both forms of "IPv4-based addresses" are to be
searched). searched).
3.1.3.3. Service-port Addresses 4.1.3.3. Service-Port Addresses
Address following this pattern include the service port (e.g. 80 for Addresses following this pattern include the service port (e.g., 80
HTTP) in the lowest-order byte of the IID, and set the rest of the for HTTP) in the lowest-order byte of the IID and have the rest of
IID to zero. There are a number of variants for this address the bytes of the IID set to zero. There are a number of variants for
pattern: this address pattern:
o The lowest-order 16-bit word (from right to left) may contain the o The lowest-order 16-bit word (from right to left) may contain the
service port, and the second lowest-order 16-bit word (from right service port, and the second lowest-order 16-bit word (from right
to left) may be set to a number in the range 0-255 (as in e.g. to left) may be set to a number in the range 0x0000-0x00ff (as in,
2001:db8::1:80). e.g., 2001:db8::1:80).
o The lowest-order 16-bit word (from right to left) may be set to a o The lowest-order 16-bit word (from right to left) may be set to a
value in the range 0-255, while the second lowest-order 16-bit value in the range 0x0000-0x00ff, while the second lowest-order
word (from right to left) may contain the service port (as in e.g. 16-bit word (from right to left) may contain the service port (as
2001:db8::80:1). in, e.g., 2001:db8::80:1).
o The service port itself might be encoded in decimal or in o The service port itself might be encoded in decimal or in
hexadecimal notation (e.g., an address embedding the HTTP port hexadecimal notation (e.g., an address embedding the HTTP port
might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding
the service port as a decimal number being more common. the service port as a decimal number being more common.
Considering a maximum of 20 popular service ports, the search space Considering a maximum of 20 popular service ports, the search space
for addresses following this pattern is, in the worst-case scenario, for addresses following this pattern is, in the worst-case scenario,
20 * 2^10. 10 * 2^11.
3.1.3.4. Wordy Addresses 4.1.3.4. Wordy Addresses
Since IPv6 address notation allows for a number of hexadecimal Since the IPv6 address notation allows for a number of hexadecimal
digits, it is not difficult to encode words into IPv6 addresses (as digits, it is not difficult to encode words into IPv6 addresses (as
in, e.g., 2001:db8::dead:beef). in, e.g., 2001:db8::bad:cafe).
Addresses following this pattern are likely to be explored by means Addresses following this pattern are likely to be explored by means
of "dictionary attacks", and therefore computing the corresponding of "dictionary attacks"; therefore, computing the corresponding
search-space is not straight-forward. search space is not straightforward.
3.1.4. IPv6 Addresses Corresponding to Transition/Co-existence 4.1.4. IPv6 Addresses Corresponding to Transition/Coexistence
Technologies Technologies
Some transition/co-existence technologies might be leveraged to Some transition/coexistence technologies might be leveraged to reduce
reduce the target search space of remote address-scanning attacks, the target search space of remote address-scanning attacks, since
since they specify how the corresponding IPv6 address must be they specify how the corresponding IPv6 address must be generated.
generated. For example, in the case of Teredo [RFC4380], the 64-bit For example, in the case of Teredo [RFC4380], the 64-bit IID is
interface identifier is generated from the IPv4 address observed at a generated from the IPv4 address observed at a Teredo server along
Teredo server along with a UDP port number. with a UDP port number.
3.1.5. IPv6 Address Assignment in Real-world Network Scenarios For obvious reasons, the search space for these addresses will depend
on the specific transition/coexistence technology being employed.
Table 2, Table 3 and Table 4 provide a summary of the results 4.1.5. IPv6 Address Assignment in Real-World Network Scenarios
obtained by [Gont-LACSEC2013] for web servers, nameservers, and
mailservers, respectively. Table 5 provides a rough summary of the Figures 1, 2, and 3 provide a summary of the results obtained by
results obtained by [Malone2008] for IPv6 routers. Table 6 provides [Gont-LACSEC2013] when measuring the address patterns employed by web
a summary of the results obtained by [Ford2013] for clients. servers, name servers, and mail servers, respectively. Figure 4
provides a rough summary of the results obtained by [Malone2008] for
IPv6 routers. Figure 5 provides a summary of the results obtained by
[Ford2013] for clients.
+---------------+------------+ +---------------+------------+
| Address type | Percentage | | Address type | Percentage |
+---------------+------------+ +---------------+------------+
| IEEE-based | 1.44% | | IEEE-based | 1.44% |
+---------------+------------+ +---------------+------------+
| Embedded-IPv4 | 25.41% | | Embedded-IPv4 | 25.41% |
+---------------+------------+ +---------------+------------+
| Embedded-Port | 3.06% | | Embedded-Port | 3.06% |
+---------------+------------+ +---------------+------------+
| ISATAP | 0% | | ISATAP | 0.00% |
+---------------+------------+ +---------------+------------+
| Low-byte | 56.88% | | Low-byte | 56.88% |
+---------------+------------+ +---------------+------------+
| Byte-pattern | 6.97% | | Byte-pattern | 6.97% |
+---------------+------------+ +---------------+------------+
| Randomized | 6.24% | | Randomized | 6.24% |
+---------------+------------+ +---------------+------------+
Table 2: Measured webserver addresses Figure 1: Measured Web Server Addresses
+---------------+------------+ +---------------+------------+
| Address type | Percentage | | Address type | Percentage |
+---------------+------------+ +---------------+------------+
| IEEE-based | 0.67% | | IEEE-based | 0.67% |
+---------------+------------+ +---------------+------------+
| Embedded-IPv4 | 22.11% | | Embedded-IPv4 | 22.11% |
+---------------+------------+ +---------------+------------+
| Embedded-Port | 6.48% | | Embedded-Port | 6.48% |
+---------------+------------+ +---------------+------------+
| ISATAP | 0% | | ISATAP | 0.00% |
+---------------+------------+ +---------------+------------+
| Low-byte | 56.58% | | Low-byte | 56.58% |
+---------------+------------+ +---------------+------------+
| Byte-pattern | 11.07% | | Byte-pattern | 11.07% |
+---------------+------------+ +---------------+------------+
| Randomized | 3.09% | | Randomized | 3.09% |
+---------------+------------+ +---------------+------------+
Table 3: Measured nameserver addresses Figure 2: Measured Name Server Addresses
+---------------+------------+ +---------------+------------+
| Address type | Percentage | | Address type | Percentage |
+---------------+------------+ +---------------+------------+
| IEEE-based | 0.48% | | IEEE-based | 0.48% |
+---------------+------------+ +---------------+------------+
| Embedded-IPv4 | 4.02% | | Embedded-IPv4 | 4.02% |
+---------------+------------+ +---------------+------------+
| Embedded-Port | 1.07% | | Embedded-Port | 1.07% |
+---------------+------------+ +---------------+------------+
| ISATAP | 0% | | ISATAP | 0.00% |
+---------------+------------+ +---------------+------------+
| Low-byte | 92.65% | | Low-byte | 92.65% |
+---------------+------------+ +---------------+------------+
| Byte-pattern | 1.20% | | Byte-pattern | 1.20% |
+---------------+------------+ +---------------+------------+
| Randomized | 0.59% | | Randomized | 0.59% |
+---------------+------------+ +---------------+------------+
Table 4: Measured mailserver addresses Figure 3: Measured Mail Server Addresses
+--------------+------------+ +--------------+------------+
| Address type | Percentage | | Address type | Percentage |
+--------------+------------+ +--------------+------------+
| Low-byte | 70% | | Low-byte | 70.00% |
+--------------+------------+ +--------------+------------+
| IPv4-based | 5% | | IPv4-based | 5.00% |
+--------------+------------+ +--------------+------------+
| SLAAC | 1% | | SLAAC | 1.00% |
+--------------+------------+ +--------------+------------+
| Wordy | <1% | | Wordy | <1.00% |
+--------------+------------+ +--------------+------------+
| Randomized | <1% | | Randomized | <1.00% |
+--------------+------------+ +--------------+------------+
| Teredo | <1% | | Teredo | <1.00% |
+--------------+------------+ +--------------+------------+
| Other | <1% | | Other | <1.00% |
+--------------+------------+ +--------------+------------+
Table 5: Measured router addresses Figure 4: 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% |
+---------------+------------+
+---------------+------------+ Figure 5: Measured Client 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 NOTE:
"ISATAP" stands for "Intra-Site Automatic Tunnel Addressing
Protocol" [RFC5214].
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 Figure 5 shows that while around 70% of clients observed in this
measurement appear to be using temporary addresses, there are still a measurement appear to be using temporary addresses, a significant
significant amount exposing IEEE-based addresses, and addresses using number of clients still expose IEEE-based addresses and addresses
embedded IPv4 (thus also revealing IPv4 addresses). using embedded IPv4 (thus also revealing IPv4 addresses). Besides,
as noted in Section 4.1.1.3, temporary addresses are employed along
with stable IPv6 addresses; thus, hosts employing a temporary address
may still be the subject of address-scanning attacks that target
their stable address(es).
3.2. IPv6 Address Scanning of Remote Networks [ADDR-ANALYSIS] contains a spatial and temporal analysis of IPv6
addresses corresponding to clients and routers.
While in IPv4 networks attackers have been able to get away with 4.2. IPv6 Address Scanning of Remote Networks
"brute force" scanning attacks (thanks to the reduced search space),
successfully performing a brute-force scan of an entire /64 network
would be infeasible. As a result, it is expected that attackers will
leverage the IPv6 address patterns discussed in Section 3.1 to reduce
the IPv6 address search space.
IPv6 address scanning of remote area networks should consider an Although attackers have been able to get away with "brute-force"
address-scanning attacks in IPv4 networks (thanks to the lesser
search space), successfully performing a brute-force address-scanning
attack of an entire /64 network would be infeasible. As a result, it
is expected that attackers will leverage the IPv6 address patterns
discussed in Section 4.1 to reduce the IPv6 address search space.
IPv6 address scanning of remote networks should consider an
additional factor not present for the IPv4 case: since the typical additional factor not present for the IPv4 case: since the typical
IPv6 host subnet is a /64, scanning an entire /64 could, in theory, IPv6 subnet is a /64, scanning an entire /64 could, in theory, lead
lead to the creation of 2^64 entries in the Neighbor Cache of the to the creation of 2^64 entries in the Neighbor Cache of the last-hop
last-hop router. Unfortunately, a number of IPv6 implementations router. Unfortunately, a number of IPv6 implementations have been
have been found to be unable to properly handle large number of found to be unable to properly handle a large number of entries in
entries in the Neighbor Cache, and hence these address-scan attacks the Neighbor Cache; hence, these address-scanning attacks may have
may have the side effect of resulting in a Denial of Service (DoS) the side effect of resulting in a Denial-of-Service (DoS) attack
attack [CPNI-IPv6] [RFC6583]. [CPNI-IPv6] [RFC6583].
[RFC7421] discusses the "default" /64 boundary for host subnets, and [RFC7421] discusses the "default" /64 boundary for host subnets and
the assumptions surrounding it. While there are reports of a handful the assumptions surrounding it. While there are reports of sites
of sites implementing host subnets of size /112 or smaller to reduce implementing IPv6 subnets of size /112 or smaller to reduce concerns
concerns about the above attack, such smaller subnets are likely to about the above attack, such smaller subnets are likely to make
make address-based scanning more feasible, in addition to address-scanning attacks more feasible, in addition to encountering
encountering the issues with non-/64 host subnets discussed in the the issues with non-/64 host subnets discussed in [RFC7421].
above draft.
3.2.1. Reducing the subnet ID search space 4.2.1. Reducing the Subnet ID Search Space
When scanning a remote network, consideration is required to select When address scanning a remote network, consideration is required to
which subnet IDs to choose. A typical site might have a /48 select which subnet IDs to choose. A typical site might have a /48
allocation, which would mean up to 65,000 or so host /64 subnets to allocation, which would mean up to 65,000 or so IPv6 /64 subnets to
be scanned. be scanned.
However, in the same way the search space for the IID can be reduced, However, in the same way the search space for the IID can be reduced,
we may also be able to reduce the subnet ID space in a number of we may also be able to reduce the subnet ID search space in a number
ways, by guessing likely address plan schemes, or using any of ways, by guessing likely address plan schemes or using any
complementary clues that might exist from other sources or complementary clues that might exist from other sources or
observations. For example there are a number of documents available observations. For example, there are a number of documents available
online (e.g. [RFC5375]) that provide recommendations for allocation online (e.g., [RFC5375]) that provide recommendations for the
of address space, which address various operational considerations, allocation of address space, which address various operational
including: RIR assignment policy, ability to delegate reverse DNS considerations, including Regional Internet Registry (RIR) assignment
zones to different servers, ability to aggregate routes efficiently, policy, ability to delegate reverse DNS zones to different servers,
address space preservation, ability to delegate address assignment ability to aggregate routes efficiently, address space preservation,
within the organization, ability to add allocate new sites/prefixes ability to delegate address assignment within the organization,
to existing entities without updating ACLs, and ability to de- ability to add/allocate new sites/prefixes to existing entities
aggregate and advertise sub-spaces via various AS interfaces. without updating Access Control Lists (ACLs), and ability to
de-aggregate and advertise subspaces via various Autonomous System
(AS) interfaces.
Address plans might include use of subnets which: Address plans might include use of subnets that:
o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64, o Run from low ID upwards, e.g., 2001:db8:0::/64, 2001:db8:1::/64,
etc. etc.
o Use building numbers, in hex or decimal form. o Use building numbers, in hexadecimal or decimal form.
o Use VLAN numbers. o Use Virtual Local Area Network (VLAN) numbers.
o Use IPv4 subnet number in a dual-stack target, e.g. a site with a o Use an IPv4 subnet number in a dual-stack target, e.g., a site
/16 for IPv4 might use /24 subnets, and the IPv6 address plan may with a /16 for IPv4 might use /24 subnets, and the IPv6 address
re-use the third byte as the IPv6 subnet ID. plan may reuse the third byte of the IPv4 address as the IPv6
subnet ID.
o Use the service "colour", as defined for service-based prefix o Use the service "color", as defined for service-based prefix
colouring, or semantic prefixes. For example, a site using a coloring, or semantic prefixes. For example, a site using a
specific colouring for a specific service such as VoIP may reduce specific coloring for a specific service such as Voice over IP
the subnet ID search space for those devices. (VoIP) may reduce the subnet ID search space for those devices.
The net effect is that the address space of an organization may be The net effect is that the address space of an organization may be
highly structured, and allocations of individual elements within this highly structured, and allocations of individual elements within this
structure may be predictable once other elements are known. structure may be predictable once other elements are known.
In general, any subnet ID address plan may convey information, or be In general, any subnet ID address plan may convey information, or be
based on known information, which may in turn be of advantage to an based on known information, which may in turn be of advantage to an
attacker. attacker.
3.3. IPv6 Address Scanning of Local Networks 4.3. IPv6 Address Scanning of Local Networks
IPv6 address scanning in Local Area Networks could be considered, to IPv6 address scanning in Local Area Networks (LANs) could be
some extent, a completely different problem than that of scanning a considered, to some extent, a completely different problem than that
remote IPv6 network. The main difference is that use of link-local of scanning a remote IPv6 network. The main difference is that use
multicast addresses can relieve the attacker of searching for unicast of link-local multicast addresses can relieve the attacker of
addresses in a large IPv6 address space. searching for unicast addresses in a large IPv6 address space.
NOTE:
While a number of other network reconnaissance vectors (such as While a number of other network reconnaissance vectors (such as
network snooping, leveraging Neighbor Discovery traffic, etc.) are network snooping, leveraging Neighbor Discovery traffic, etc.) are
available when scanning a local network, this section focuses only available when scanning a local network, this section focuses only
on address-scanning attacks (a la "ping sweep"). on address-scanning attacks (a la "ping sweep").
An attacker can simply send probe packets to the all-nodes link-local An attacker can simply send probe packets to the all-nodes link-local
multicast address (ff02::1), such that responses are elicited from multicast address (ff02::1), such that responses are elicited from
all local nodes. all local nodes.
Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo
Request messages sent to multicast addresses, IPv6 address-scanning Request messages sent to multicast addresses, IPv6 address-scanning
tools typically employ a number of additional probe packets to elicit tools typically employ a number of additional probe packets to elicit
responses from all the local nodes. For example, unrecognized IPv6 responses from all the local nodes. For example, unrecognized IPv6
options of type 10xxxxxx elicit ICMPv6 Parameter Problem, code 2, options of type 10xxxxxx elicit Internet Control Message Protocol
error messages. version 6 (ICMPv6) Parameter Problem, code 2, error messages.
Many address-scanning tools discover only IPv6 link-local addresses Many address-scanning tools discover only IPv6 link-local addresses
(rather than e.g. the global addresses of the target systems): since (rather than, e.g., the global addresses of the target systems):
the probe packets are typically sent with the attacker's IPv6 link- since the probe packets are typically sent with the attacker's IPv6
local address, the "victim" nodes send the response packets using the link-local address, the "victim" nodes send the response packets
IPv6 link-local address of the corresponding network interface (as using the IPv6 link-local address of the corresponding network
specified by the IPv6 address selection rules [RFC6724]). However, interface (as specified by the IPv6 address-selection rules
sending multiple probe packets, with each packet employing addresses [RFC6724]). However, sending multiple probe packets, with each
from different prefixes, typically helps to overcome this limitation. packet employing source addresses from different prefixes, typically
helps to overcome this limitation.
This technique is employed by the scan6 tool of the IPv6 Toolkit
package [IPv6-Toolkit].
3.4. Existing IPv6 Address Scanning Tools 4.4. Existing IPv6 Address-Scanning Tools
3.4.1. Remote IPv6 Network Scanners 4.4.1. Remote IPv6 Network Address Scanners
IPv4 address scanning tools have traditionally carried out their task IPv4 address-scanning tools have traditionally carried out their task
for probing an entire address range (usually the entire range of a by probing an entire address range (usually the entire address range
target subnetwork). One might argue that the reason for which we comprised by the target subnetwork). One might argue that the reason
have been able to get away with such somewhat "rudimentary" for which they have been able to get away with such somewhat
techniques is that the scale or challenge of the task is so small in "rudimentary" techniques is that the scale or challenge of the task
the IPv4 world, that a "brute-force" attack is "good enough". is so small in the IPv4 world that a "brute-force" attack is "good
However, the scale of the "address scanning" task is so large in enough". However, the scale of the "address-scanning" task is so
IPv6, that attackers must be very creative to be "good enough". large in IPv6 that attackers must be very creative to be "good
Simply sweeping an entire /64 IPv6 subnet would just not be feasible. enough". Simply sweeping an entire /64 IPv6 subnet would just not be
feasible.
Many address scanning tools such as nmap [nmap2012] do not even Many address-scanning tools do not even support sweeping an IPv6
support sweeping an IPv6 address range. On the other hand, the address range. On the other hand, the alive6 tool from [THC-IPV6]
alive6 tool from [THC-IPV6] supports sweeping address ranges, thus supports sweeping address ranges, thus being able to leverage some
being able to leverage some patterns found in IPv6 addresses, such as patterns found in IPv6 addresses, such as the incremental addresses
the incremental addresses resulting from some DHCPv6 setups. resulting from some DHCPv6 setups. Finally, the scan6 tool from
Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address [IPv6-Toolkit] supports sweeping address ranges and can also leverage
ranges, and can also leverage all the address patterns described in all the address patterns described in Section 4.1 of this document.
Section 3.1 of this document.
Clearly, a limitation of many of the currently-available tools for Clearly, a limitation of many of the currently available tools for
IPv6 address scanning is that they lack of an appropriately tuned IPv6 address scanning is that they lack an appropriately tuned
"heuristics engine" that can help reduce the search space, such that "heuristics engine" that can help reduce the search space, such that
the problem of IPv6 address scanning becomes tractable. the problem of IPv6 address scanning becomes tractable.
It should be noted that IPv6 network monitoring and management tools It should be noted that IPv6 network monitoring and management tools
also need to build and maintain information about the hosts in their also need to build and maintain information about the hosts in their
network. Such systems can no longer scan internal systems in a network. Such systems can no longer scan internal systems in a
reasonable time to build a database of connected systems. Rather, reasonable time to build a database of connected systems. Rather,
such systems will need more efficient approaches, e.g. by polling such systems will need more efficient approaches, e.g., by polling
network devices for data held about observed IP addresses, MAC network devices for data held about observed IP addresses, MAC
addresses, physical ports used, etc. Such an approach can also addresses, physical ports used, etc. Such an approach can also
enhance address accountability, by mapping IPv4 and IPv6 addresses to enhance address accountability, by mapping IPv4 and IPv6 addresses to
observed MAC addresses. This of course implies that any access observed MAC addresses. This of course implies that any access
control mechanisms for querying such network devices, e.g. community control mechanisms for querying such network devices, e.g., community
strings for SNMP, should be set appropriately to avoid an attacker strings for SNMP, should be set appropriately to avoid an attacker
being able to gather address information remotely. being able to gather address information remotely.
3.4.2. Local IPv6 Network Scanners 4.4.2. Local IPv6 Network Address Scanners
There are a variety of publicly-available local IPv6 network There are a variety of publicly available local IPv6 network address-
scanners: scanners:
o Current versions of nmap [nmap2012] implement this functionality. o Current versions of nmap [nmap2015] implement this functionality.
o THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool (alive6) that o The Hacker's Choice (THC) IPv6 Attack Toolkit [THC-IPV6] includes
implements this functionality. a tool (alive6) that implements this functionality.
o SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) o SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6)
that implements this functionality. that implements this functionality.
3.5. Mitigations 4.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:
o Employing [RFC7217] (stable, semantically opaque IIDs) in o Employing [RFC7217] (stable, semantically opaque IIDs) in
replacement of addresses based on IEEE identifiers, such that any replacement of addresses based on IEEE identifiers, such that any
address patterns are eliminated. address patterns are eliminated.
o Employing Intrusion Prevention Systems (IPS) at the perimeter, o Employing Intrusion Prevention Systems (IPSs) at the perimeter.
such that address scanning attacks can be mitigated.
o Enforce IPv6 packet filtering where applicable (see e.g. o Enforcing IPv6 packet filtering where applicable (see, e.g.,
[RFC4890]). [RFC4890]).
o If virtual machines are employed, and "resistance" to address o Employing manually configured MAC addresses if virtual machines
scanning attacks is deemed as desirable, manually-configured MAC are employed and "resistance" to address-scanning attacks is
addresses can be employed, such that even if the virtual machines deemed desirable, such that even if the virtual machines employ
employ IEEE-derived IIDs, they are generated from non-predictable IEEE-derived IIDs, they are generated from non-predictable MAC
MAC addresses. addresses.
o When using DHCPv6, avoid use of sequential addresses. Ideally, o Avoiding use of sequential addresses when using DHCPv6. Ideally,
the DHCPv6 server would allocate random addresses from a large the DHCPv6 server would allocate random addresses from a large
pool. pool (see, e.g., [IIDS-DHCPv6]).
o Use the "default" /64 size IPv6 subnet prefixes. o Using the "default" /64 size IPv6 subnet prefixes.
o In general, avoid being predictable in the way addresses are o In general, avoiding being predictable in the way addresses are
assigned. assigned.
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
protocol features (such as [RFC7217]) on the corresponding nodes. protocol features (such as [RFC7217]) on the 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). And one should always remember that security by obscurity possible). And one should always remember that security by obscurity
is not a reasonable defence in itself; it may only be one (relatively is not a reasonable defense in itself; it may only be one (relatively
small) layer in a broader security environment. small) layer in a broader security environment.
Two of the techniques discussed in this document for local address- Two of the techniques discussed in this document for local address-
scanning attacks are those that employ multicasted ICMPv6 Echo scanning attacks are those that employ multicasted ICMPv6 Echo
Requests and multicasted IPv6 packets containing unsupported options Requests and multicasted IPv6 packets containing unsupported options
of type 10xxxxxx. These two vectors could be easily mitigated by of type 10xxxxxx. These two vectors could be easily mitigated by
configuring nodes to not respond to multicasted ICMPv6 Echo Request configuring nodes to not respond to multicasted ICMPv6 Echo Requests
(default on Windows systems), and by updating the IPv6 specifications (default on Windows systems) and by updating the IPv6 specifications
(and/or possibly configuring local nodes) such that multicasted (and/or possibly configuring local nodes) such that multicasted
packets never elicit ICMPv6 error messages (even if they contain packets never elicit ICMPv6 error messages (even if they contain
unsupported options of type 10xxxxxx). unsupported options of type 10xxxxxx).
[I-D.gont-6man-ipv6-smurf-amplifier] proposes such update to the NOTE:
IPv6 specifications. [SMURF-AMPLIFIER] proposed such an update to the IPv6
specifications.
In any case, when it comes to local networks, there are a variety of In any case, when it comes to local networks, there are a variety of
network reconnaissance vectors. Therefore, even if address-scanning network reconnaissance vectors. Therefore, even if address-scanning
vectors are mitigated, an attacker could still rely on e.g. protocols vectors were mitigated, an attacker could still rely on, e.g.,
employed for the so-called "opportunistic networking" (such as mDNS protocols employed for the so-called "service discovery protocols"
[RFC6762]), or eventually rely on network snooping as last resort for (see Section 5.2) or eventually rely on network snooping as a last
network reconnaissance. There is ongoing work in the IETF on resort for network reconnaissance. There is ongoing work in the IETF
extending mDNS, or at least DNS-based service discovery, to work on extending mDNS, or at least DNS-based service discovery, to work
across a whole site, rather than in just a single subnet, which will across a whole site, rather than in just a single subnet, which will
have associated security implications. have associated security implications.
4. Leveraging the Domain Name System (DNS) for Network Reconnaissance 4.6. Conclusions
4.1. DNS Advertised Hosts In the previous subsections, we have shown why a /64 host subnet may
be more vulnerable to address-based scanning than might intuitively
be thought and how an attacker might reduce the target search space
when performing an address-scanning attack.
Any systems that are "published" in the DNS, e.g. MX mail relays, or We have described a number of mitigations against address-scanning
web servers, will remain open to probing from the very fact that attacks, including the replacement of traditional SLAAC with stable
their IPv6 addresses are publicly available. It is worth noting that semantically opaque IIDs (which requires support from system
where the addresses used at a site follow specific patterns, vendors). We have also offered some practical guidance in regard to
publishing just one address may lead to a threat upon the other the principle of avoiding predictability in host addressing schemes.
hosts. Finally, examples of address-scanning approaches and tools are
discussed in the appendices.
While most early IPv6-enabled networks remain dual stack, they are
more likely to be scanned and attacked over IPv4 transport, and one
may argue that the IPv6-specific considerations discussed here are
not of an immediate concern. However, an early IPv6 deployment
within a dual-stack network may be seen by an attacker as a
potentially "easier" target if the implementation of security
policies is not as strict for IPv6 (for whatever reason). As
IPv6-only networks become more common, the above considerations will
be of much greater importance.
5. Alternative Methods to Glean IPv6 Addresses
The following subsections describe alternative methods by which an
attacker might attempt to glean IPv6 addresses for subsequent
probing.
5.1. Leveraging the Domain Name System (DNS) for Network Reconnaissance
5.1.1. DNS Advertised Hosts
Any systems that are "published" in the DNS, e.g., Mail Exchange (MX)
relays or web servers, will remain open to probing from the very fact
that their IPv6 addresses are publicly available. It is worth noting
that where the addresses used at a site follow specific patterns,
publishing just one address may lead to an attack upon the other
nodes.
Additionally, we note that publication of IPv6 addresses in the DNS Additionally, we note that publication of IPv6 addresses in the DNS
should not discourage the elimination of IPv6 address patterns: if should not discourage the elimination of IPv6 address patterns: if
any address patterns are eliminated from addresses published in the any address patterns are eliminated from addresses published in the
DNS, an attacker may have to rely on performing dictionary-based DNS DNS, an attacker may have to rely on performing dictionary-based DNS
lookups in order to find all systems in a target network (which is lookups in order to find all systems in a target network (which is
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 5.1.2. DNS Zone Transfers
A DNS zone transfer can readily provide information about potential A DNS zone transfer (DNS query type "AXFR") [RFC1034] [RFC1035] can
attack targets. Restricting zone transfers is thus probably more readily provide information about potential attack targets.
important for IPv6, even if it is already good practice to restrict Restricting zone transfers is thus probably more important for IPv6,
them in the IPv4 world. even if it is already good practice to restrict them in the IPv4
world.
4.3. DNS Brute Forcing 5.1.3. DNS Brute Forcing
Attackers may employ DNS brute-forcing techniques by testing for the Attackers may employ DNS brute-forcing techniques by testing for the
presence of DNS AAAA records against commonly used host names. presence of DNS AAAA records against commonly used host names.
4.4. DNS Reverse Mappings 5.1.4. DNS Reverse Mappings
[van-Dijk] describes an interesting technique that employs DNS [van-Dijk] describes an interesting technique that employs DNS
reverse mappings for network reconnaissance. Essentially, the reverse mappings for network reconnaissance. Essentially, the
attacker walks through the "ip6.arpa" zone looking up PTR records, in attacker walks through the "ip6.arpa" zone looking up PTR records, in
the hopes of learning the IPv6 addresses of hosts in a given target the hopes of learning the IPv6 addresses of hosts in a given target
network (assuming that the reverse mappings have been configured, of network (assuming that the reverse mappings have been configured, of
course). What is most interesting about this technique is that it course). What is most interesting about this technique is that it
can greatly reduce the IPv6 address search space. can greatly reduce the IPv6 address search space.
Basically, an attacker would walk the ip6.arpa zone corresponding to Basically, an attacker would walk the ip6.arpa zone corresponding to
a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for a target network (e.g., "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for
"2001:db8:80::/48"), issuing queries for PTR records corresponding to "2001:db8:80::/48"), issuing queries for PTR records corresponding to
the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.",
"1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR "1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR
records for any hosts "starting" with the domain name records for any hosts "starting" with the domain name
"0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name
corresponding to the IPv6 address 2001:db8:80::1), the response would corresponding to the IPv6 address 2001:db8:80::1), the response would
contain an RCODE of 0 (no error). Otherwise, the response would contain an RCODE of 0 (no error). Otherwise, the response would
contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this
technique allows for a tremendous reduction in the "IPv6 address" technique allows for a tremendous reduction in the "IPv6 address"
search space. search space.
[I-D.howard-isp-ip6rdns] analyzes different approaches and NOTE:
considerations for ISPs in managing the ip6.arpa zone for IPv6 Some name servers, incorrectly implementing the DNS protocol,
address space assigned to many customers, which may affect the reply NXDOMAIN instead of NODATA (NOERROR=0 and ANSWER=0) when
technique described in this section. encountering a domain without any resource records but that has
child domains, something that is very common in ip6.arpa (these
domains are called ENT for Empty Non-Terminals; see [RFC7719]).
When scanning ip6.arpa, this behavior may slow down or completely
prevent the exploration of ip6.arpa. Nevertheless, since such
behavior is wrong (see [NXDOMAIN-DEF]), one cannot rely on it to
"secure" ip6.arpa against tree walking.
5. Leveraging Local Name Resolution and Service Discovery Services [IPv6-RDNS] analyzes different approaches and considerations for
ISPs in managing the ip6.arpa zone for IPv6 address space assigned
to many customers, which may affect the technique described in
this section.
5.2. Leveraging Local Name Resolution and Service Discovery Services
A number of protocols allow for unmanaged local name resolution and A number of protocols allow for unmanaged local name resolution and
service. For example, multicast DNS (mDNS) [RFC6762] and DNS Service service. For example, mDNS [RFC6762] and DNS Service Discovery (DNS-
Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution SD) [RFC6763], or Link-Local Multicast Name Resolution (LLMNR)
(LLMNR) [RFC4795], are examples of such protocols. [RFC4795], are examples of such protocols.
NOTE:
Besides the Graphical User Interfaces (GUIs) included in products Besides the Graphical User Interfaces (GUIs) included in products
supporting such protocols, command-line tools such as mdns-scan supporting such protocols, command-line tools such as mdns-scan
[mdns-scan] and mzclient can help discover IPv6 hosts employing [mdns-scan] and mzclient [mzclient] can help discover IPv6 hosts
mDNS/DNS-SD. employing mDNS/DNS-SD.
6. Public Archives 5.3. Public Archives
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 to be a useful channel for an attacker, since hostnames and/or
addresses could be easily obtained by inspection of the (many) IPv6 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 5.4. Application Participation
Peer-to-peer applications often include some centralized server which Peer-to-peer applications often include some centralized server that
coordinates the transfer of data between peers. For example, coordinates the transfer of data between peers. For example,
BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks
of files, with a tracker passing information about peers with of files, with a tracker passing information about peers with
available chunks of data between the peers. Such applications may available chunks of data between the peers. Such applications may
offer an attacker a 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 5.5. 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. SAVI routing table of any system connected to such network. Source
[RFC6620] also builds a cache of IPv6 and link-layer addresses Address Validation Improvement (SAVI) [RFC6620] also builds a cache
(without actively participating in the Neighbor Discovery packet of IPv6 and link-layer addresses (without actively participating in
exchange), and hence is another source of similar information. the Neighbor Discovery packet exchange) and hence is another source
of similar information.
These data structures could be inspected either via "login" access or These data structures could be inspected via either "login" access or
via SNMP. While this requirement may limit the applicability of this SNMP. While this requirement may limit the applicability of this
technique, there are a number of scenarios in which this technique technique, there are a number of scenarios in which this technique
might be of use. For example, security audit tools might be provided might be of use. For example, security audit tools might be provided
with the necessary credentials such that the Neighbor Cache and the with the necessary credentials such that the Neighbor Cache and the
routing table of all systems for which the tool has "login" or SNMP routing table of all systems for which the tool has "login" or SNMP
access can be automatically gleaned. On the other hand, IPv6 worms access can be automatically gleaned. On the other hand, IPv6 worms
[V6-WORMS] could leverage this technique for the purpose of spreading [V6-WORMS] could leverage this technique for the purpose of spreading
on the local network, since they will typically have access to the on the local network, since they will typically have access to the
Neighbor Cache and routing table of an infected system. Neighbor Cache and routing table of an infected system.
Section 2.5.1.4 of [I-D.ietf-opsec-v6] discusses additional Section 2.5.1.4 of [OPSEC-IPv6] discusses additional considerations
considerations for the inspection of the IPv6 Neighbor Cache. for the inspection of the IPv6 Neighbor Cache.
9. Inspection of System Configuration and Log Files 5.6. Inspection of System Configuration and Log Files
Nodes are generally configured with the addresses of other important Nodes are generally configured with the addresses of other important
local computers, such as email servers, local file servers, web proxy local computers, such as email servers, local file servers, web proxy
servers, recursive DNS servers, etc. The /etc/hosts file in UNIX, servers, recursive DNS servers, etc. The /etc/hosts file in UNIX-
SSH known_hosts files, or the Microsoft Windows registry are just like systems, Secure Shell (SSH) known_hosts files, or the Microsoft
some examples of places where interesting information about such Windows registry are just some examples of places where interesting
systems might be found. information about such systems might be found.
Additionally, system log files (including web server logs, etc.) may Additionally, system log files (including web server logs, etc.) may
also prove a useful channel for an attacker. also prove to be a useful source for an attacker.
While the required credentials to access the aforementioned While the required credentials to access the aforementioned
configuration and log files may limit the applicability of this configuration and log files may limit the applicability of this
technique, there are a number of scenarios in which this technique technique, there are a number of scenarios in which this technique
might be of use. For example, security audit tools might be provided might be of use. For example, security audit tools might be provided
with the necessary credentials such that these files can be with the necessary credentials such that these files can be
automatically accessed. On the other hand, IPv6 worms could leverage automatically accessed. On the other hand, IPv6 worms could leverage
this technique for the purpose of spreading on the local network, this technique for the purpose of spreading on the local network,
since they will typically have access to these files on an infected since they will typically have access to these files on an infected
system [V6-WORMS]. system [V6-WORMS].
10. Gleaning Information from Routing Protocols 5.7. Gleaning Information from Routing Protocols
Some organizational IPv6 networks employ routing protocols to Some organizational IPv6 networks employ routing protocols to
dynamically maintain routing information. In such an environment, a dynamically maintain routing information. In such an environment, a
local attacker could become a passive listener of the routing local attacker could become a passive listener of the routing
protocol, to determine other valid subnets/prefixes and some router protocol, to determine other valid subnets/prefixes and some router
addresses within that organization [V6-WORMS]. addresses within that organization [V6-WORMS].
11. Gleaning Information from IP Flow Information Export (IPFIX) 5.8. Gleaning Information from IP Flow Information Export (IPFIX)
IPFIX [RFC7012] can aggregate the flows by source addresses, and IPFIX [RFC7012] can aggregate the flows by source addresses and hence
hence may be leveraged for obtaining a list of "active" IPv6 may be leveraged for obtaining a list of "active" IPv6 addresses.
addresses. Additional discussion of IPFIX can be found in Additional discussion of IPFIX can be found in Section 2.5.1.2 of
Section 2.5.1.2 of [I-D.ietf-opsec-v6]. [OPSEC-IPv6].
12. Obtaining Network Information with traceroute6 5.9. Obtaining Network Information with traceroute6
IPv6 traceroute [traceroute6] can be employed to find router IPv6 traceroute [traceroute6] and similar tools (such as path6 from
addresses and valid network prefixes. [IPv6-Toolkit]) can be employed to find router addresses and valid
network prefixes.
13. Gleaning Information from Network Devices Using SNMP 5.10. Gleaning Information from Network Devices Using SNMP
SNMP can be leveraged to obtain information from a number of data SNMP can be leveraged to obtain information from a number of data
structures such as the Neighbor Cache [RFC4861], the routing table, structures such as the Neighbor Cache [RFC4861], the routing table,
and the SAVI [RFC6620] cache of IPv6 and link-layer addresses. SNMP and the SAVI [RFC6620] cache of IPv6 and link-layer addresses. SNMP
access should be secured, such that unauthorized access to the access should be secured, such that unauthorized access to the
aforementioned information is prevented. aforementioned information is prevented.
14. Obtaining Network Information via Traffic Snooping 5.11. Obtaining Network Information via Traffic Snooping
Snooping network traffic can help in discovering active nodes in a Snooping network traffic can help in discovering active nodes in a
number of ways. Firstly, each captured packet will reveal the source number of ways. Firstly, each captured packet will reveal the source
and destination of the packet. Secondly, the captured traffic may and destination of the packet. Secondly, the captured traffic may
correspond to network protocols that transfer information such as correspond to network protocols that transfer information such as
host or router addresses, network topology information, etc. host or router addresses, network topology information, etc.
15. Conclusions 6. Conclusions
In this document we have discussed issues around host-based scanning
of IPv6 networks. We have shown why a /64 host subnet may be more
vulnerable to address-based scanning that might intuitively be
thought, and how an attacker might reduce the target search space
when scanning.
We have described a number of mitigations against host-based
scanning, including the replacement of traditional SLAAC with stable
semantically-opaque IIDs (which will require support from system
vendors). We have also offered some practical guidance, around the
principle of avoiding having predictability in host addressing
schemes. Finally, examples of scanning approaches and tools are
discussed in the Appendices.
While most early IPv6-enabled networks remain dual-stack, they are
more likely to be scanned and attacked over IPv4 transport, and one
may argue that the IPv6-specific considerations discussed here are
not of an immediate concern. However, an early IPv6 deployment
within a dual-stack network may be seen by an attacker as a
potentially "easier" target, if the implementation of security
policies are not as strict for IPv6 (for whatever reason). As and
when IPv6-only networks become more common, the considerations in
this document will be of much greater importance.
16. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
17. Security Considerations
This document explores the topic of Network Reconnaissance in IPv6 This document explores the topic of network reconnaissance in IPv6
networks. It analyzes the feasibility of address-scan attacks in networks. It analyzes the feasibility of address-scanning attacks in
IPv6 networks, and showing that the search space for such attacks is IPv6 networks and shows that the search space for such attacks is
typically much smaller than the one traditionally assumed (64 bits). typically much smaller than the one traditionally assumed (64 bits).
Additionally, it explores a plethora of other network reconnaissance
techniques, ranging from inspecting the IPv6 Network Cache of an Additionally, this document explores a plethora of other network
attacker-controlled system, to gleaning information about IPv6 reconnaissance techniques, ranging from inspecting the IPv6 Network
addresses from public mailing-list archives or Peer-To-Peer (P2P) Cache of an attacker-controlled system to gleaning information about
protocols. IPv6 addresses from public mailing-list archives or Peer-to-Peer
(P2P) protocols.
We expect traditional address-scanning attacks to become more and We expect traditional address-scanning attacks to become more and
more elaborated (i.e., less "brute force"), and other network more elaborated (i.e., less "brute force"), and other network
reconnaissance techniques to be actively explored, as global reconnaissance techniques to be actively explored, as global
deployment of IPv6 increases and. more specifically, as more deployment of IPv6 increases and, more specifically, as more
IPv6-only devices are deployed. IPv6-only devices are deployed.
18. Acknowledgements 7. Security Considerations
The authors would like to thank Ray Hunter, who provided valuable This document reviews methods by which addresses of hosts within IPv6
text that was readily incorporated into Section 3.2.1 of this subnets can be determined. As such, it raises no new security
document. concerns.
The authors would like to thank (in alphabetical order) Alissa 8. References
Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc Heuse,
Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki
Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke, for providing
valuable comments on earlier versions of this document.
Part of the contents of this document are based on the results of the 8.1. Normative References
project "Security Assessment of the Internet Protocol version 6
(IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK
Centre for the Protection of National Infrastructure (CPNI).
19. References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
19.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<http://www.rfc-editor.org/info/rfc6620>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006, DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>. <http://www.rfc-editor.org/info/rfc4380>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[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, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
DOI 10.17487/RFC5214, March 2008,
<http://www.rfc-editor.org/info/rfc5214>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<http://www.rfc-editor.org/info/rfc6620>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012, for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013, DOI 10.17487/RFC7012, September 2013,
<http://www.rfc-editor.org/info/rfc7012>. <http://www.rfc-editor.org/info/rfc7012>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>. February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
19.2. Informative References 8.2. Informative References
[ADDR-ANALYSIS]
Plonka, D. and A. Berger, "Temporal and Spatial
Classification of Active IPv6 Addresses", ACM Internet
Measurement Conference (IMC), Tokyo, Japan, Pages 509-522,
DOI 10.1145/2815675.2815678, October 2015,
<http://conferences2.sigcomm.org/imc/2015/papers/
p509.pdf>.
[BitTorrent]
Wikipedia, "BitTorrent", November 2015,
<https://en.wikipedia.org/w/
index.php?title=BitTorrent&oldid=690381343>.
[CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request).
[DEFAULT-IIDS]
Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
Work in Progress, draft-ietf-6man-default-iids-10,
February 2016.
[Ford2013] Ford, M., "IPv6 Address Analysis - Privacy In, Transition
Out", May 2013,
<http://www.internetsociety.org/blog/2013/05/
ipv6-address-analysis-privacy-transition-out>.
[Gont-DEEPSEC2011]
Gont, F., "Results of a Security Assessment of the
Internet Protocol version 6 (IPv6)", DEEPSEC
Conference, Vienna, Austria, November 2011,
<http://www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>.
[Gont-LACSEC2013]
Gont, F., "IPv6 Network Reconnaissance: Theory &
Practice", LACSEC Conference, Medellin, Colombia, May
2013, <http://www.si6networks.com/presentations/lacnic19/
lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.
[IIDS-DHCPv6]
Gont, F. and W. Liu, "A Method for Generating Semantically
Opaque Interface Identifiers with Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", Work in
Progress, draft-ietf-dhc-stable-privacy-addresses-02,
April 2015.
[IPV6-EXT-HEADERS]
Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", Work in Progress,
draft-ietf-v6ops-ipv6-ehs-in-real-world-02, December 2015.
[IPv6-RDNS]
Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", Work in Progress, draft-ietf-dnsop-isp-
ip6rdns-00, October 2015.
[IPv6-Toolkit]
SI6 Networks, "SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>.
[Malone2008]
Malone, D., "Observations of IPv6 Addresses", Passive and
Active Network Measurement (PAM 2008, LNCS 4979),
DOI 10.1007/978-3-540-79232-1_3, April 2008,
<http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.
[mdns-scan]
Poettering, L., "mdns-scan(1) Manual Page",
<http://manpages.ubuntu.com/manpages/precise/man1/
mdns-scan.1.html>.
[mzclient] Bockover, A., "Mono Zeroconf Project -- mzclient command-
line tool",
<http://www.mono-project.com/archived/monozeroconf/>.
[nmap2015] Lyon, Gordon "Fyodor", "Nmap 7.00", November 2015,
<http://insecure.org>.
[NXDOMAIN-DEF]
Bortzmeyer, S. and S. Huque, "NXDOMAIN really means there
is nothing underneath", Work in Progress, draft-ietf-
dnsop-nxdomain-cut-00, December 2015.
[OPSEC-IPv6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", Work in
Progress, draft-ietf-opsec-v6-07, September 2015.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, Multicast Name Resolution (LLMNR)", RFC 4795,
DOI 10.17487/RFC4795, January 2007, DOI 10.17487/RFC4795, January 2007,
<http://www.rfc-editor.org/info/rfc4795>. <http://www.rfc-editor.org/info/rfc4795>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, ICMPv6 Messages in Firewalls", RFC 4890,
DOI 10.17487/RFC4890, May 2007, DOI 10.17487/RFC4890, May 2007,
<http://www.rfc-editor.org/info/rfc4890>. <http://www.rfc-editor.org/info/rfc4890>.
skipping to change at page 28, line 39 skipping to change at page 32, line 18
<http://www.rfc-editor.org/info/rfc6583>. <http://www.rfc-editor.org/info/rfc6583>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[I-D.gont-6man-ipv6-smurf-amplifier]
Gont, F. and W. Liu, "Security Implications of IPv6
Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf-
amplifier-03 (work in progress), March 2013.
[I-D.howard-isp-ip6rdns]
Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", draft-howard-isp-ip6rdns-08 (work in
progress), May 2015.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", RFC 7421, Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015, DOI 10.17487/RFC7421, January 2015,
<http://www.rfc-editor.org/info/rfc7421>. <http://www.rfc-editor.org/info/rfc7421>.
[I-D.ietf-6man-default-iids] [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Gont, F., Cooper, A., Thaler, D., and S. LIU, Terminology", RFC 7719, DOI 10.17487/RFC7719, December
"Recommendation on Stable IPv6 Interface Identifiers", 2015, <http://www.rfc-editor.org/info/rfc7719>.
draft-ietf-6man-default-iids-07 (work in progress), August
2015.
[I-D.ietf-6man-ipv6-address-generation-privacy] [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-07 (work RFC 7721, DOI 10.17487/RFC7721, March 2016,
in progress), June 2015. <http://www.rfc-editor.org/info/rfc7721>.
[I-D.ietf-dhc-stable-privacy-addresses] [SMURF-AMPLIFIER]
Gont, F. and S. LIU, "A Method for Generating Semantically Gont, F. and W. Liu, "Security Implications of IPv6
Opaque Interface Identifiers with Dynamic Host Options of Type 10xxxxxx", Work in Progress, draft-gont-
Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- 6man-ipv6-smurf-amplifier-03, March 2013.
stable-privacy-addresses-02 (work in progress), April
2015.
[I-D.ietf-opsec-v6] [THC-IPV6] "THC-IPV6", <http://www.thc.org/thc-ipv6/>.
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", draft-ietf-
opsec-v6-06 (work in progress), March 2015.
[CPNI-IPv6] [traceroute6]
Gont, F., "Security Assessment of the Internet Protocol FreeBSD, "FreeBSD System Manager's Manual: traceroute6(8)
version 6 (IPv6)", UK Centre for the Protection of manual page", August 2009, <https://www.freebsd.org/cgi/
National Infrastructure, (available on request). man.cgi?query=traceroute6>.
[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", Vol. 31, No.
propagation strategies in an IPv6 Internet", ;login:, 1, pp. 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>.
[Malone2008] [van-Dijk] van Dijk, P., "Finding v6 hosts by efficiently mapping
Malone, D., "Observations of IPv6 Addresses", Passive and ip6.arpa", March 2012, <http://7bits.nl/blog/2012/03/26/
Active Measurement Conference (PAM 2008, LNCS 4979), April finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.
2008,
<http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.
[mdns-scan]
Poettering, L., "mdns-scan(1) manual page", 2012,
<http://manpages.ubuntu.com/manpages/precise/man1/
mdns-scan.1.html>.
[nmap2012]
Fyodor, , "nmap - Network exploration tool and security /
port scanner", 2012, <http://insecure.org>.
[VBox2011] [VBox2011] VirtualBox, "Oracle VM VirtualBox User Manual",
VirtualBox, , "Oracle VM VirtualBox User Manual, version Version 4.1.2, August 2011, <http://www.virtualbox.org>.
4.1.2", August 2011, <http://www.virtualbox.org>.
[vmesx2011] [vmesx2011]
vmware, , "Setting a static MAC address for a virtual VMware, "Setting a static MAC address for a virtual NIC
NIC", vmware Knowledge Base, August 2011, (219)", VMware Knowledge Base, August 2011,
<http://kb.vmware.com/selfservice/microsites/ <http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=219>. search.do?language=en_US&cmd=displayKC&externalId=219>.
[vSphere] vmware, , "vSphere Networking", 2014, [vSphere] VMware, "vSphere Networking", vSphere 5.5, Update 2,
<http://pubs.vmware.com/vsphere- September 2014, <http://pubs.vmware.com/
55/topic/com.vmware.ICbase/PDF/ vsphere-55/topic/com.vmware.ICbase/PDF/
vsphere-esxi-vcenter-server-552-networking-guide.pdf>. vsphere-esxi-vcenter-server-552-networking-guide.pdf>.
[traceroute6] Appendix A. Implementation of a Full-Fledged IPv6 Address-Scanning Tool
FreeBSD, , "FreeBSD System Manager's Manual:
traceroute6(8) manual page", 2009,
<https://www.freebsd.org/cgi/man.cgi?query=traceroute6>.
[Gont-DEEPSEC2011]
Gont, F., "Results of a Security Assessment of the
Internet Protocol version 6 (IPv6)", DEEPSEC 2011
Conference, Vienna, Austria, November 2011, 2011,
<http://www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>.
[Gont-LACSEC2013]
Gont, F., "IPv6 Network Reconnaissance: Theory &
Practice", LACSEC 2013 Conference, Medellin, Colombia,
May 2013, 2013,
<http://www.si6networks.com/presentations/lacnic19/
lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.
[Ford2013]
Ford, M., "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", <http://www.thc.org/thc-ipv6/>.
[IPv6-Toolkit]
"SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>.
[BitTorrent]
"BitTorrent", <http://en.wikipedia.org/wiki/BitTorrent>.
[van-Dijk]
van Dijk, P., "Finding v6 hosts by efficiently mapping
ip6.arpa", 2012, <http://7bits.nl/blog/2012/03/26/
finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.
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
scanner for local area networks. Appendix A.3 outlines ongoing work scanner for local area networks. Appendix A.3 outlines the
on the implementation of a general (i.e., non-local) IPv6 host implementation of a general (i.e., non-local) IPv6 address scanner.
scanner.
A.1. Host-probing considerations A.1. Host-Probing Considerations
A number of factors should be considered when selecting the probe A number of factors should be considered when selecting the probe
types and the probing-rate for an IPv6 address scanning tool. packet types and the probing rate for an IPv6 address-scanning tool.
Firstly, some hosts (or border firewalls) might be configured to Firstly, some hosts (or border firewalls) might be configured to
block or rate-limit some specific packet types. For example, it is block or rate limit some specific packet types. For example, it is
usual for host and router implementations to rate-limit ICMPv6 error usual for host and router implementations to rate-limit ICMPv6 error
traffic. Additionally, some firewalls might be configured to block traffic. Additionally, some firewalls might be configured to block
or rate-limit incoming ICMPv6 echo request packets (see e.g. or rate limit incoming ICMPv6 echo request packets (see, e.g.,
[RFC4890]). [RFC4890]).
NOTE:
As noted earlier in this document, Windows systems simply do not As noted earlier in this document, Windows systems simply do not
respond to ICMPv6 echo requests sent to multicast IPv6 addresses. respond to ICMPv6 echo requests sent to multicast IPv6 addresses.
Among the possible probe types are: Among the possible probe types are:
o ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies), o ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies),
o TCP SYN segments (meant to elicit SYN/ACK or RST segments), o TCP SYN segments (meant to elicit SYN/ACK or RST segments),
o TCP segments that do not contain the ACK bit set (meant to elicit o TCP segments that do not contain the ACK bit set (meant to elicit
RST segments), RST segments),
o UDP datagrams (meant to elicit a UDP application response or an o UDP datagrams (meant to elicit a UDP application response or an
ICMPv6 Port Unreachable), ICMPv6 Port Unreachable),
o IPv6 packets containing any suitable payload and an unrecognized o IPv6 packets containing any suitable payload and an unrecognized
extension header (meant to elicit ICMPv6 Parameter Problem error extension header (meant to elicit ICMPv6 Parameter Problem error
messages), or, messages), or
o IPv6 packets containing any suitable payload and an unrecognized o IPv6 packets containing any suitable payload and an unrecognized
option of type 10xxxxxx (such that a ICMPv6 Parameter Problem option of type 10xxxxxx (meant to elicit an ICMPv6 Parameter
error message is elicited) Problem error message).
Selecting an appropriate probe packet might help conceal the ongoing Selecting an appropriate probe packet might help conceal the ongoing
attack, but may also be actually necessary if host or network attack, but it may also be actually necessary if host or network
configuration causes certain probe packets to be dropped. In some configuration causes certain probe packets to be dropped.
cases, it might be desirable to insert some IPv6 extension headers
before the actual payload, such that some filtering policies can be
circumvented.
Another factor to consider is the host-probing rate. Clearly, the Some address-scanning tools (such as scan6 of [IPv6-Toolkit])
incorporate support for IPv6 extension headers. In some cases,
inserting some IPv6 extension headers in the probe packet may allow
some filtering policies or monitoring devices to be circumvented.
However, it may also result in the probe packets being dropped, as a
result of the widespread dropping of IPv6 packets that employ IPv6
extension headers (see [IPV6-EXT-HEADERS]).
Another factor to consider is the address-probing rate. Clearly, the
higher the rate, the smaller the amount of time required to perform higher the rate, the smaller the amount of time required to perform
the attack. However, the probing-rate should not be too high, or the attack. However, the probing rate should not be too high, or
else: else:
1. the attack might cause network congestion, thus resulting in 1. the attack might cause network congestion, thus resulting in
packet loss packet loss.
2. the attack might hit rate-limiting, thus resulting in packet loss 2. the attack might hit rate limiting, thus resulting in packet
loss.
3. the attack might reveal underlying problems in the Neighbor 3. the attack might reveal underlying problems in Neighbor Discovery
Discovery implementation, thus leading to packet loss and implementations, thus leading to packet loss and possibly even
possibly even Denial of Service Denial of Service.
Packet-loss is undesirable, since it would mean that an "alive" node Packet loss is undesirable, since it would mean that an "alive" node
might remain undetected as a result of a lost probe or response. might remain undetected as a result of a lost probe or response.
Such losses could be the result of congestion (in case the attacker Such losses could be the result of congestion (in case the attacker
is scanning a target network at a rate higher than the target network is scanning a target network at a rate higher than the target network
can handle), or may be the result of rate-limiting as it would be can handle) or may be the result of rate limiting (as it would be
typically the case if ICMPv6 is employed for the probe packets. typically the case if ICMPv6 is employed for the probe packets).
Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router
implementations have been found to be unable to perform decent implementations have been found to be unable to perform decent
resource management when faced with Neighbor Discovery traffic resource management when faced with Neighbor Discovery traffic
involving a large number of local nodes. This essentially means that involving a large number of local nodes. This essentially means that
regardless of the type of probe packets, an address scanning attack regardless of the type of probe packets, an address-scanning attack
might result in a Denial of Service (DoS) of the target network, with might result in a DoS of the target network, with the same (or worse)
the same (or worse) effects as that of network congestion or rate- effects as that of network congestion or rate limiting.
limiting.
The specific rates at which each of these issues may come into play The specific rates at which each of these issues may come into play
vary from one scenario to another, and depend on the type of deployed vary from one scenario to another and depend on the type of deployed
routers/firewalls, configuration parameters, etc. routers/firewalls, configuration parameters, etc.
A.2. Implementation of an IPv6 local address-scanning tool A.2. Implementation of an IPv6 Local Address-Scanning Tool
scan6 [IPv6-Toolkit] is prototype IPv6 local address scanning tool, scan6 [IPv6-Toolkit] is a full-fledged IPv6 local address-scanning
which has proven to be effective and efficient for the discovery of tool, which has proven to be effective and efficient for the
IPv6 hosts on a local network. discovery of IPv6 hosts on a local network.
The scan6 tool operates (roughly) as follows: The scan6 tool operates (roughly) as follows:
1. The tool learns the local prefixes used for auto-configuration, 1. The tool learns the local prefixes used for autoconfiguration and
an generates/configures one address for each local prefix (in generates/configures one address for each local prefix (in
addition to a link-local address). addition to a link-local address).
2. An ICMPv6 Echo Request message destined to the all-nodes on-link 2. An ICMPv6 Echo Request message destined to the all-nodes on-link
multicast address (ff02::1) is sent with each of the addresses multicast address (ff02::1) is sent from each of the addresses
"configured" in the previous step. Because of the different "configured" in the previous step. Because of the different
Source Addresses, each probe causes the victim nodes to use source addresses, each probe packet causes the victim nodes to
different Source Addresses for the response packets (this allows use different source addresses for the response packets (this
the tool to learn virtually all the addresses in use in the local allows the tool to learn virtually all the addresses in use in
network segment). the local network segment).
3. The same procedure of the previous bullet is performed, but this 3. The same procedure of the previous bullet is performed, but this
time with ICMPv6 packets that contain an unrecognized option of time with ICMPv6 packets that contain an unrecognized option of
type 10xxxxxx, such that ICMPv6 Parameter Problem error messages type 10xxxxxx, such that ICMPv6 Parameter Problem error messages
are elicited. This allows the tool to discover e.g. Windows are elicited. This allows the tool to discover, e.g., Windows
nodes, which otherwise do not respond to multicasted ICMPv6 Echo nodes, which otherwise do not respond to multicasted ICMPv6 Echo
Request messages. Request messages.
4. Each time a new "alive" address is discovered, the corresponding 4. Each time a new "alive" address is discovered, the corresponding
Interface-ID is combined with all the local prefixes, and the IID is combined with all the local prefixes, and the resulting
resulting addresses are probed (with unicasted packets). This addresses are probed (with unicasted packets). This can help to
can help to discover other addresses in use on the local network discover other addresses in use on the local network segment,
segment, since the same Interface ID is typically used with all since the same IID is typically used with all the available
the available prefixes for the local network. prefixes for the local network.
NOTE:
The aforementioned scheme can fail to discover some addresses for The aforementioned scheme can fail to discover some addresses for
some implementation. For example, Mac OS X employs IPv6 addresses some implementations. For example, Mac OS X employs IPv6
embedding IEEE-identifiers (rather than "temporary addresses") addresses embedding IEEE identifiers (rather than "temporary
when responding to packets destined to a link-local multicast addresses") when responding to packets destined to a link-local
address, sourced from an on-link prefix. multicast address, sourced from an on-link prefix.
A.3. Implementation of a IPv6 remote address-scanning tool A.3. Implementation of an IPv6 Remote Address-Scanning Tool
An IPv6 remote address scanning tool, could be implemented with the An IPv6 remote address-scanning tool could be implemented with the
following features: following features:
o The tool can be instructed to target specific address ranges (e.g. o The tool can be instructed to target specific address ranges
2001:db8::0-10:0-1000) (e.g., 2001:db8::0-10:0-1000).
o The tool can be instructed to scan for SLAAC addresses of a o The tool can be instructed to scan for SLAAC addresses of a
specific vendor, such that only addresses embedding the specific vendor, such that only addresses embedding the
corresponding IEEE OUIs are probed. corresponding IEEE OUIs are probed.
o The tool can be instructed to scan for SLAAC addresses that employ o The tool can be instructed to scan for SLAAC addresses that employ
a specific IEEE OUI. a specific IEEE OUI or set of OUIs corresponding to a specific
vector.
o The tool can be instructed to discover virtual machines, such that o The tool can be instructed to discover virtual machines, such that
a given IPv6 prefix is only scanned for the address patterns a given IPv6 prefix is only scanned for the address patterns
resulting from virtual machines. resulting from virtual machines.
o The tool can be instructed to scan for low-byte addresses. o The tool can be instructed to scan for low-byte addresses.
o The tool can be instructed to scan for wordy-addresses, in which o The tool can be instructed to scan for wordy addresses, in which
case the tool selects addresses based on a local dictionary. case the tool selects addresses based on a local dictionary.
o The tool can be instructed to scan for IPv6 addresses embedding o The tool can be instructed to scan for IPv6 addresses embedding
TCP/UDP service ports, in which case the tool selects addresses TCP/UDP service ports, in which case the tool selects addresses
based on a list of well-known service ports. based on a list of well-known service ports.
o The tool can be specified an IPv4 address range in use at the o The tool can be specified to scan an IPv4 address range in use at
target network, such that only IPv4-based IPv6 addresses are the target network, such that only IPv4-based IPv6 addresses are
scanned. scanned.
The scan6 tool of [IPv6-Toolkit] implements all these techniques/ The scan6 tool of [IPv6-Toolkit] implements all these techniques/
features. features. Furthermore, when given a target domain name or sample
IPv6 address for a given prefix, the tool will try to infer the
address pattern in use at the target network, and reduce the address
search space accordingly.
Acknowledgements
The authors would like to thank Ray Hunter, who provided valuable
text that was readily incorporated into Section 4.2.1 of this
document.
The authors would like to thank (in alphabetical order) Ivan Arce,
Alissa Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc
Heuse, Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki
Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke for providing
valuable comments on earlier draft versions of this document.
Fernando Gont would like to thank Jan Zorz of Go6 Lab
<http://go6lab.si/> and Jared Mauch of NTT America for providing
access to systems and networks that were employed to perform
experiments and measurements that helped to improve this document.
Additionally, he would like to thank SixXS <https://www.sixxs.net>
for providing IPv6 connectivity.
Part of the contents of this document are based on the results of the
project "Security Assessment of the Internet Protocol version 6
(IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK
Centre for the Protection of National Infrastructure (CPNI).
Fernando Gont would like to thank Daniel Bellomo (UNRC) for his
continued support.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
Huawei Technologies Huawei Technologies
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
skipping to change at page 35, line 4 skipping to change at page 38, line 24
Fernando Gont Fernando Gont
Huawei Technologies Huawei Technologies
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
Tim Chown Tim Chown
University of Southampton Jisc
Highfield Lumen House, Library Avenue
Southampton , Hampshire SO17 1BJ Harwell Oxford, Didcot. OX11 0SG
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tim.chown@jisc.ac.uk
 End of changes. 286 change blocks. 
784 lines changed or deleted 888 lines changed or added

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