draft-ietf-opsec-ipv6-host-scanning-07.txt   draft-ietf-opsec-ipv6-host-scanning-08.txt 
opsec F. Gont opsec F. Gont
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 5157 (if approved) T. Chown Obsoletes: 5157 (if approved) T. Chown
Intended status: Informational University of Southampton Intended status: Informational University of Southampton
Expires: November 1, 2015 April 30, 2015 Expires: February 29, 2016 August 28, 2015
Network Reconnaissance in IPv6 Networks Network Reconnaissance in IPv6 Networks
draft-ietf-opsec-ipv6-host-scanning-07 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 less 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, and
therefore brute-force IPv6 address scanning attacks have been therefore brute-force IPv6 address scanning attacks have been
considered unfeasible. This document updates RFC 5157, which first considered unfeasible. This document formally obsoletes RFC 5157,
discussed this assumption, by providing further analysis on how which first discussed this assumption, by providing further analysis
traditional address scanning techniques apply to IPv6 networks, and on how traditional address scanning techniques apply to IPv6
exploring some additional techniques that can be employed for IPv6 networks, and exploring some additional techniques that can be
network reconnaissance. In doing so, this document formally employed for IPv6 network reconnaissance.
obsoletes RFC 5157.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 1, 2015. This Internet-Draft will expire on February 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for the Applicability of Network Reconnaissance 2. Requirements for the Applicability of Network Reconnaissance
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4 Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5
3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6
3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6
3.1.2. Dynamic Host Configuration Protocol version 6 3.1.2. Dynamic Host Configuration Protocol version 6
(DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10 (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 11
3.1.4. IPv6 Addresses Corresponding to Transition/Co- 3.1.4. IPv6 Addresses Corresponding to Transition/Co-
existence Technologies . . . . . . . . . . . . . . . 12 existence Technologies . . . . . . . . . . . . . . . 14
3.1.5. IPv6 Address Assignment in Real-world Network 3.1.5. IPv6 Address Assignment in Real-world Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 13 Scenarios . . . . . . . . . . . . . . . . . . . . . . 14
3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 16 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17
3.2.1. Reducing the subnet ID search space . . . . . . . . . 16 3.2.1. Reducing the subnet ID search space . . . . . . . . . 17
3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 17 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 18
3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 18 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 19
3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 18 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 19
3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 19 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 20
3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 20
4. Leveraging the Domain Name System (DNS) for Network 4. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 21
4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 21 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 22
4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 21 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 22
4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 22
5. Leveraging Local Name Resolution and Service Discovery 5. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 22 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 23
7. Application Participation . . . . . . . . . . . . . . . . . . 22 7. Application Participation . . . . . . . . . . . . . . . . . . 23
8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 23
9. Inspection of System Configuration and Log Files . . . . . . 23 9. Inspection of System Configuration and Log Files . . . . . . 24
10. Gleaning Information from Routing Protocols . . . . . . . . . 23 10. Gleaning Information from Routing Protocols . . . . . . . . . 24
11. Gleaning Information from IP Flow Information Export (IPFIX) 23 11. Gleaning Information from IP Flow Information Export (IPFIX) 24
12. Obtaining Network Information with traceroute6 . . . . . . . 23 12. Obtaining Network Information with traceroute6 . . . . . . . 24
13. Gleaning Information from Network Devices Using SNMP . . . . 24 13. Gleaning Information from Network Devices Using SNMP . . . . 25
14. Obtaining Network Information via Traffic Snooping . . . . . 24 14. Obtaining Network Information via Traffic Snooping . . . . . 25
15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
17. Security Considerations . . . . . . . . . . . . . . . . . . . 25 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
19.1. Normative References . . . . . . . . . . . . . . . . . . 25 19.1. Normative References . . . . . . . . . . . . . . . . . . 26
19.2. Informative References . . . . . . . . . . . . . . . . . 26 19.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Implementation of a full-fledged IPv6 address- Appendix A. Implementation of a full-fledged IPv6 address-
scanning tool . . . . . . . . . . . . . . . . . . . 29 scanning tool . . . . . . . . . . . . . . . . . . . 31
A.1. Host-probing considerations . . . . . . . . . . . . . . . 29 A.1. Host-probing considerations . . . . . . . . . . . . . . . 31
A.2. Implementation of an IPv6 local address-scanning tool . . 31 A.2. Implementation of an IPv6 local address-scanning tool . . 33
A.3. Implementation of a IPv6 remote address-scanning tool . . 32 A.3. Implementation of a IPv6 remote address-scanning tool . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The main driver for IPv6 [RFC2460] deployment is its larger address The main driver for IPv6 [RFC2460] deployment is its larger address
space [CPNI-IPv6]. This larger address space not only allows for an space [CPNI-IPv6]. This larger address space not only allows for an
increased number of connected devices, but also introduces a number increased number of connected devices, but also introduces a number
of subtle changes in several aspects of the resulting networks. One of subtle changes in several aspects of the resulting networks. One
of these changes is the reduced host density (the number of hosts of these changes is the reduced host density (the number of hosts
divided by the number of addresses) of typical IPv6 subnetworks: with divided by the number of addresses) of typical IPv6 subnetworks, when
default IPv6 subnets of /64, each subnet comprises more than 1.844 * compared to their IPv4 counterparts. [RFC5157] describes how this
10^19 available addresses; however, the actual number of nodes in significantly lower IPv6 host-density is likely to make classic
each subnet is likely to remain similar to that of IPv4 subnetworks
(typically a few hundred nodes per subnet). [RFC5157] describes how
this significantly lower IPv6 host-density is likely to make classic
network address scans less feasible, since even by applying various network address scans less feasible, since even by applying various
heuristics, the address space to be scanned remains very large. RFC heuristics, the address space to be scanned remains very large. RFC
5157 goes on to describe some alternative methods for attackers to 5157 goes on to describe some alternative methods for attackers to
glean active IPv6 addresses, and provides some guidance for glean active IPv6 addresses, and provides some guidance for
administrators and implementors, e.g. not using sequential addresses administrators and implementors, e.g. not using sequential addresses
with DHCPv6. with DHCPv6.
With the benefit of five years of additional IPv6 deployment With the benefit of more than five years of additional IPv6
experience, this document formally updates and obsoletes RFC 5157. deployment experience, this document formally obsoletes RFC 5157. It
It emphasises that while scanning attacks are less feasible, they emphasises that while scanning attacks are less feasible, they may,
may, with appropriate heuristics, remain possible. At the time that with appropriate heuristics, remain possible. At the time that RFC
RFC 5157 was written, observed scans were typically across ports on 5157 was written, observed scans were typically across ports on the
the addresses of discovered servers; since then, evidence that some addresses of discovered servers; since then, evidence that some
classic address scanning is occurring is being witnessed. This text classic address scanning is occurring is being witnessed. This text
thus updates the analysis on the feasibility of "traditional" thus updates the analysis on the feasibility of "traditional"
address-scanning attacks in IPv6 networks, and it explores a number address-scanning attacks in IPv6 networks, and it explores a number
of additional techniques that can be employed for IPv6 network of additional techniques that can be employed for IPv6 network
reconnaissance. Practical examples and guidance are also included in reconnaissance. Practical examples and guidance are also included in
the Appendices. 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 two-fold.
Section 3 analyzes the feasibility of traditional address-scanning Section 3 analyzes the feasibility of traditional address-scanning
attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of
possible improvements to such techniques. [van-Dijk] describes a possible improvements to such techniques. Appendix A describes how
technique for leveraging DNS reverse mappings for discovering IPv6 the aforementioned analysis can be leveraged to produce address-
nodes. Finally, Appendix A describes how the analysis carried out scanning tools (e.g. for penetration testing purposes). Section 4
throughout this document can be leveraged to produce address-scanning analyzes network reconnaissance techniques that leverage the Domain
tools (e.g. for penetration testing purposes). Name System (DNS). Finally, the rest of this document discusses a
number of other miscellaneous techniques that could be leveraged for
IPv6 network reconnaissance.
2. Requirements for the Applicability of Network Reconnaissance 2. Requirements for the Applicability of Network Reconnaissance
Techniques Techniques
Throughout this document, a number of network reconnaissance Throughout this document, a number of network reconnaissance
techniques are discussed. Each of these techniques have different techniques are discussed. Each of these techniques have different
requirements on the side of the practitioner, with respect to whether requirements on the side of the practitioner, with respect to whether
they require local access to the target network, and whether they they require local access to the target network, and whether they
require login access (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.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
For example, the MAC address 00:1b:38:83:88:3c would lead to the IID For example, the MAC address 00:1b:38:83:88:3c would lead to the IID
021b:38ff:fe83:883c. 021b:38ff:fe83:883c.
NOTE: NOTE:
[RFC7136] notes that all bits of an IID should be treated as [RFC7136] notes that all bits of an IID should be treated as
"opaque" bits. Furthermore, [I-D.ietf-6man-default-iids] is "opaque" bits. Furthermore, [I-D.ietf-6man-default-iids] is
currently in the process of changing the default IID generation currently in the process of changing the default IID generation
scheme to [RFC7217]. Therefore, the traditional IIDs based on scheme to [RFC7217]. Therefore, the traditional IIDs based on
link-layer addresses are expected to become less common over time. link-layer addresses are expected to become less common over time.
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.
A number of considerations should be made about these identifiers. A number of considerations should be made about these identifiers.
Firstly, as it should be obvious from the algorithm described above, Firstly, two bytes (bytes 3-4) of the resulting address always have a
two bytes (bytes 4-5) of the resulting address always have a fixed fixed value (0xff, 0xfe), thus reducing the search space for the IID.
value (0xff, 0xfe), thus reducing the search space for the IID.
Secondly, the first three bytes of these identifiers correspond to Secondly, the first three bytes of these identifiers 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 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.
skipping to change at page 8, line 8 skipping to change at page 8, line 11
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 Further, if just one host address is detected or known within a
subnet, it is not unlikely that, if systems were ordered in a batch, subnet, it is not unlikely that, if systems were ordered in a batch,
that they may have sequential MAC addresses. Additionally, given a that they may have sequential MAC addresses. Additionally, given a
MAC address observed in one subnet, sequential or nearby MAC MAC address observed in one subnet, sequential or nearby MAC
addresses may be seen in other subnets in the same site. addresses may be seen in other subnets in the same site.
Another interesting factor arises from the use of virtualization 3.1.1.2. Interface-Identifiers of Virtualization Technologies
technologies, since they generally employ automatically-generated MAC
addresses, with very specific patterns. For example, all
automatically-generated MAC addresses in VirtualBox virtual machines
employ the OUI 08:00:27 [VBox2011]. This means that all SLAAC-
produced addresses will have an IID of the form a00:27ff:feXX:XXXX,
thus effectively reducing the IID search space from 64 bits to 24
bits.
VMWare ESX server provides yet a more interesting example. IIDs resulting from virtualization technologies can be considered a
Automatically-generated MAC addresses have the following pattern specific sub-case of IIDs embedding IEEE identifiers (please see
[vmesx2011]: Section 3.1.1.1): they employ IEEE identifiers, but part of the lower
half of the IID has specific patterns. The following subsections
describe IIDs of some popular virtualization technologies.
1. The OUI is set to 00:05:59 3.1.1.2.1. VirtualBox
2. The next 16-bits of the MAC address are set to the same value as All automatically-generated MAC addresses in VirtualBox virtual
machines employ the OUI 08:00:27 [VBox2011]. This means that all
SLAAC-produced addresses will have an IID of the form
a00:27ff:feXX:XXXX, thus effectively reducing the IID search space
from 64 bits to 24 bits.
3.1.1.2.2. VMWare ESX server
VMWare ESX server (versions 1.0 to 2.5) provides yet a more
interesting example. Automatically-generated MAC addresses have the
following pattern [vmesx2011]:
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
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 eight bits of the MAC address are set to a hash value 3. The final 8 bits of the MAC address are set to a hash value based
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 VMWare ESX
server employ the OUI 00:50:56, with the low-order three bytes being server employ the OUI 00:50:56, with the low-order three bytes being
in the range 0x000000-0x3fffff (to avoid conflicts with other VMware in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware
products). Therefore, even in the case of manually-configured MAC products). Therefore, even in the case of manually-configured MAC
addresses, the IID search space is reduced from 64-bits to 22 bits. addresses, the IID search space is reduced from 64 bits to 22 bits.
3.1.1.2. Temporary Addresses 3.1.1.2.3. VMWare vSphere
VMWare vSphere [vSphere] supports these default MAC address
generation algorithms:
o Generated addresses
* Assigned by vCenter Server
* Assigned by the ESXi host
o Manually-configured addresses
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
calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)),
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
therefore the search space for the resulting SLAAC addresses will be
24 bits.
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
lastthree octets in hexadecimal format of the virtual machine UUID
(based on a hash calculated by using the UUID of the ESXi physical
machine and the path to a configuration file). Thus, the MAC
addresses will be in the range 00:0C:29:XX:YY:ZZ-00:0C:29:FF:FF:FF,
and therefore the search space for the resulting SLAAC addresses will
be 22 bits.
Finally, manually-configured MAC addresses employ the OUI 00:50:56,
with the low-order three bytes being in the range 0x000000-0x3fffff
(to avoid conflicts with other VMware products). Therefore,
therefore the search space for the resulting SLAAC addresses will be
22 bits.
3.1.1.3. Temporary Addresses
Privacy concerns [Gont-DEEPSEC2011] Privacy concerns [Gont-DEEPSEC2011]
[I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface [I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface
identifiers embedding IEEE identifiers led to the introduction of identifiers embedding IEEE identifiers led to the introduction of
"Privacy Extensions for Stateless Address Auto-configuration 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 auto-
configuration IPv6 prefix advertised in a Router Advertisement. configuration IPv6 prefix advertised in a Router Advertisement.
skipping to change at page 9, line 30 skipping to change at page 10, line 30
addition to (rather than as a replacement of) the traditional SLAAC addition to (rather than as a replacement of) the traditional SLAAC
addresses derived from e.g. IEEE identifiers. addresses derived from e.g. 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 SLAAC address 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 SLAAC address remains liable to be
scanned from offsite. scanned from offsite.
3.1.1.3. Randomized Stable Interface Identifiers 3.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 interface IDs are constant across system bootstraps,
and also constant across networks. and also constant across networks.
skipping to change at page 10, line 5 skipping to change at page 11, line 5
However, since the resulting interface IDs are constant across However, since the resulting interface IDs are constant across
networks, these addresses may still be leveraged for host tracking networks, these addresses may still be leveraged for host tracking
purposes [RFC7217] purposes [RFC7217]
[I-D.ietf-6man-ipv6-address-generation-privacy]. [I-D.ietf-6man-ipv6-address-generation-privacy].
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 a scan, but, in the absence of
concurrent use of temporary addresses, the host is liable to be concurrent use of temporary addresses, the host is liable to be
tracked across visited networks. tracked across visited networks.
3.1.1.4. Stable Privacy-Enhanced Addresses 3.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 3.1.1.1
and the privacy issues discussed in and the privacy issues discussed in
[I-D.ietf-6man-ipv6-address-generation-privacy], the IETF has [I-D.ietf-6man-ipv6-address-generation-privacy], the IETF has
standardized (in [RFC7217]) a method for generating IPv6 Interface standardized (in [RFC7217]) a method for generating IPv6 Interface
Identifiers to be used with IPv6 Stateless Address Autoconfiguration Identifiers to be used with IPv6 Stateless Address Autoconfiguration
(SLAAC), such that addresses configured using this method are stable (SLAAC), such that addresses configured using this method are stable
within each subnet, but the Interface Identifier changes when hosts 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 Interface Identifiers based on
skipping to change at page 11, line 33 skipping to change at page 12, line 33
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 3.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 the bytes of the IID (except the least significant bytes) are set to
zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also zero (as in 2001:db8::1, 2001:db8::2, etc.). However, it is also
common to find similar addresses in which the two lowest order 16-bit common to find similar addresses in which the two lowest order 16-bit
words are set to small numbers (as in 2001::db8::1:10, words (from the right to left) are set to small numbers (as in
2001:db8::2:10, etc.). Yet it is not uncommon to find IPv6 addresses 2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to
in which the second lowest-order 16-bit word is set to a small value find IPv6 addresses in which the second lowest-order 16-bit word
in the range 0-255, while the lowest-order 16-bit word varies in the (from right to left) is set to a small value in the range 0-255,
while the lowest-order 16-bit word (from right to left) varies in the
range 0-65535. It should be noted that all of these address patterns range 0-65535. It should be noted that all of these address patterns
are generally referred to as "low-byte addresses", even when, are generally referred to as "low-byte addresses", even when,
strictly speaking, it is not not only the lowest-order byte of the strictly speaking, it is not only the lowest-order byte of the IPv6
IPv6 address that varies from one address to another. 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 3.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 notation of addresses in 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 one byte of the IPv4 address in each of the 16-bit words of
the IID (as in e.g. 2001:db8::192:0:2:1). the IID (as in e.g. 2001:db8::192:0:2:1).
For obvious reasons, the search space for addresses following this Therefore, the search space for addresses following this pattern is
pattern is that of the corresponding IPv4 prefix (or twice the size that of the corresponding IPv4 prefix (or twice the size of that
of that search space if both forms of "IPv4-based addresses" are to search space if both forms of "IPv4-based addresses" are to be
be searched). searched).
3.1.3.3. Service-port Addresses 3.1.3.3. Service-port Addresses
Address following this pattern include the service port (e.g. 80 for Address following this pattern include the service port (e.g. 80 for
HTTP) in the lowest-order byte of the IID, and set the rest of the HTTP) in the lowest-order byte of the IID, and set the rest of the
IID to zero. There are a number of variants for this address IID to zero. There are a number of variants for this address
pattern: pattern:
o The lowest-order 16-bit word may contain the service port, and the o The lowest-order 16-bit word (from right to left) may contain the
second lowest-order 16-bit word may be set to a number in the service port, and the second lowest-order 16-bit word (from right
range 0-255 (as in e.g. 2001:db8::1:80). to left) may be set to a number in the range 0-255 (as in e.g.
2001:db8::1:80).
o The lowest-order 16-bit word may be set to a value in the range o The lowest-order 16-bit word (from right to left) may be set to a
0-255, while the second lowest-order 16-bit word may contain the value in the range 0-255, while the second lowest-order 16-bit
service port (as in e.g. 2001:db8::80:1). word (from right to left) may contain the service port (as 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. 20 * 2^10.
skipping to change at page 17, line 39 skipping to change at page 18, line 39
attacker. attacker.
3.3. IPv6 Address Scanning of Local Networks 3.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 could be considered, to
some extent, a completely different problem than that of scanning a some extent, a completely different problem than that of scanning a
remote IPv6 network. The main difference is that use of link-local remote IPv6 network. The main difference is that use of link-local
multicast addresses can relieve the attacker of searching for unicast multicast addresses can relieve the attacker of searching for unicast
addresses in a large IPv6 address space. addresses in a large IPv6 address space.
Obviously, a number of other network reconnaissance vectors (such While a number of other network reconnaissance vectors (such as
as network snooping, leveraging Neighbor Discovery traffic, etc.) network snooping, leveraging Neighbor Discovery traffic, etc.) are
are available when scanning a local network. However, this available when scanning a local network, this section focuses only
section focuses only on address-scanning attacks (a la "ping on address-scanning attacks (a la "ping sweep").
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 ICMPv6 Parameter Problem, code 2,
skipping to change at page 18, line 36 skipping to change at page 19, line 36
have been able to get away with such somewhat "rudimentary" have been able to get away with such somewhat "rudimentary"
techniques is that the scale or challenge of the task is so small in techniques is that the scale or challenge of the task is so small in
the IPv4 world, that a "brute-force" attack is "good enough". the IPv4 world, that a "brute-force" attack is "good enough".
However, the scale of the "address scanning" task is so large in However, the scale of the "address scanning" task is so large in
IPv6, that attackers must be very creative to be "good enough". IPv6, that attackers must be very creative to be "good enough".
Simply sweeping an entire /64 IPv6 subnet would just not be feasible. 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 such as nmap [nmap2012] do not even
support sweeping an IPv6 address range. On the other hand, the support sweeping an IPv6 address range. On the other hand, the
alive6 tool from [THC-IPV6] supports sweeping address ranges, thus alive6 tool from [THC-IPV6] supports sweeping address ranges, thus
being able to leverage some patters found in IPv6 addresses, such as being able to leverage some patterns found in IPv6 addresses, such as
the incremental addresses resulting from some DHCPv6 setups. the incremental addresses resulting from some DHCPv6 setups.
Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address
ranges, and can also leverage all the address patterns described in ranges, and can also leverage all the address patterns described in
Section 3.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 of 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.
skipping to change at page 19, line 30 skipping to change at page 20, line 30
implements this functionality. 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 3.5. Mitigations
IPv6 address-scanning attacks can be mitigated in a number of ways. IPv6 address-scanning attacks can be mitigated in a number of ways.
A non-exhaustive list of the possible mitigations includes: A non-exhaustive list of the possible mitigations includes:
o Employing stable privacy-enhanced addresses [RFC7217] 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 (IPS) at the perimeter,
such that address scanning attacks can be mitigated. such that address scanning attacks can be mitigated.
o Enforce IPv6 packet filtering where applicable (see e.g. o Enforce IPv6 packet filtering where applicable (see e.g.
[RFC4890]). [RFC4890]).
o If virtual machines are employed, and "resistance" to address o If virtual machines are employed, and "resistance" to address
skipping to change at page 24, line 31 skipping to change at page 25, line 31
15. Conclusions 15. Conclusions
In this document we have discussed issues around host-based scanning 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 of IPv6 networks. We have shown why a /64 host subnet may be more
vulnerable to address-based scanning that might intuitively be vulnerable to address-based scanning that might intuitively be
thought, and how an attacker might reduce the target search space thought, and how an attacker might reduce the target search space
when scanning. when scanning.
We have described a number of mitigations against host-based We have described a number of mitigations against host-based
scanning, including the replacement of traditional SLAAC with stable scanning, including the replacement of traditional SLAAC with stable
privacy-enhanced IIDs (which will require support from system semantically-opaque IIDs (which will require support from system
vendors). We have also offered some practical guidance, around the vendors). We have also offered some practical guidance, around the
principle of avoiding having predictability in host addressing principle of avoiding having predictability in host addressing
schemes. Finally, examples of scanning approaches and tools are schemes. Finally, examples of scanning approaches and tools are
discussed in the Appendices. discussed in the Appendices.
While most early IPv6-enabled networks remain dual-stack, they are While most early IPv6-enabled networks remain dual-stack, they are
more likely to be scanned and attacked over IPv4 transport, and one more likely to be scanned and attacked over IPv4 transport, and one
may argue that the IPv6-specific considerations discussed here are may argue that the IPv6-specific considerations discussed here are
not of an immediate concern. However, an early IPv6 deployment not of an immediate concern. However, an early IPv6 deployment
within a dual-stack network may be seen by an attacker as a within a dual-stack network may be seen by an attacker as a
skipping to change at page 25, line 29 skipping to change at page 26, line 29
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 18. Acknowledgements
The authors would like to thank Ray Hunter, who provided valuable The authors would like to thank Ray Hunter, who provided valuable
text that was readily incorporated into Section 3.2.1 of this text that was readily incorporated into Section 3.2.1 of this
document. document.
The authors would like to thank (in alphabetical order) Wesley The authors would like to thank (in alphabetical order) Alissa
George, Marc Heuse, Ray Hunter, Libor Polcak, Tomoyuki Sahara, Jan Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc Heuse,
Schaumann, Arturo Servin, and Eric Vyncke, for providing valuable Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki
comments on earlier versions of this document. 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 Part of the contents of this document are based on the results of the
project "Security Assessment of the Internet Protocol version 6 project "Security Assessment of the Internet Protocol version 6
(IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK
Centre for the Protection of National Infrastructure (CPNI). Centre for the Protection of National Infrastructure (CPNI).
Fernando Gont would like to thank the UK CPNI for their continued
support.
19. References 19. References
19.1. Normative References 19.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC Improvement for Locally Assigned IPv6 Addresses",
6620, May 2012. RFC 6620, DOI 10.17487/RFC6620, May 2012,
<http://www.rfc-editor.org/info/rfc6620>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (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, February Network Address Translations (NATs)", RFC 4380,
2006. DOI 10.17487/RFC4380, February 2006,
<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,
September 2007. DOI 10.17487/RFC4861, September 2007,
<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, September 2007. Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<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, September 2007. IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
Information Export (IPFIX)", RFC 7012, September 2013. for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<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, February 2014. Interface Identifiers", RFC 7136, DOI 10.17487/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, April 2014. Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
19.2. Informative References 19.2. Informative References
[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, January Multicast Name Resolution (LLMNR)", RFC 4795,
2007. DOI 10.17487/RFC4795, January 2007,
<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, May 2007. ICMPv6 Messages in Firewalls", RFC 4890,
DOI 10.17487/RFC4890, May 2007,
<http://www.rfc-editor.org/info/rfc4890>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
5157, March 2008. RFC 5157, DOI 10.17487/RFC5157, March 2008,
<http://www.rfc-editor.org/info/rfc5157>.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008. Considerations", RFC 5375, DOI 10.17487/RFC5375, December
2008, <http://www.rfc-editor.org/info/rfc5375>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<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,
February 2013. DOI 10.17487/RFC6762, February 2013,
<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, February 2013. Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[I-D.gont-6man-ipv6-smurf-amplifier] [I-D.gont-6man-ipv6-smurf-amplifier]
Gont, F. and W. Liu, "Security Implications of IPv6 Gont, F. and W. Liu, "Security Implications of IPv6
Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf- Options of Type 10xxxxxx", draft-gont-6man-ipv6-smurf-
amplifier-03 (work in progress), March 2013. amplifier-03 (work in progress), March 2013.
[I-D.howard-isp-ip6rdns] [I-D.howard-isp-ip6rdns]
Howard, L., "Reverse DNS in IPv6 for Internet Service Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", draft-howard-isp-ip6rdns-07 (work in Providers", draft-howard-isp-ip6rdns-08 (work in
progress), February 2015. progress), May 2015.
[RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
in IPv6 Addressing", RFC 7421, January 2015. Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015,
<http://www.rfc-editor.org/info/rfc7421>.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will, Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-02 (work in progress), draft-ietf-6man-default-iids-07 (work in progress), August
January 2015. 2015.
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "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-05 (work draft-ietf-6man-ipv6-address-generation-privacy-07 (work
in progress), April 2015. in progress), June 2015.
[I-D.ietf-dhc-stable-privacy-addresses] [I-D.ietf-dhc-stable-privacy-addresses]
Gont, F. and W. Will, "A Method for Generating Gont, F. and S. LIU, "A Method for Generating Semantically
Semantically Opaque Interface Identifiers with Dynamic Opaque Interface Identifiers with Dynamic Host
Host Configuration Protocol for IPv6 (DHCPv6)", draft- Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-
ietf-dhc-stable-privacy-addresses-02 (work in progress), stable-privacy-addresses-02 (work in progress), April
April 2015. 2015.
[I-D.ietf-opsec-v6] [I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", draft-ietf- Security Considerations for IPv6 Networks", draft-ietf-
opsec-v6-06 (work in progress), March 2015. opsec-v6-06 (work in progress), March 2015.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
[V6-WORMS] [V6-WORMS]
Bellovin, S., Cheswick, B., and A. Keromytis, "Worm Bellovin, S., Cheswick, B., and A. Keromytis, "Worm
propagation strategies in an IPv6 Internet", ;login:, propagation strategies in an IPv6 Internet", ;login:,
pages 70-76, February 2006, pages 70-76, February 2006,
<https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>. <https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>.
[Malone2008] [Malone2008]
Malone, D., "Observations of IPv6 Addresses", Passive and Malone, D., "Observations of IPv6 Addresses", Passive and
Active Measurement Conference (PAM 2008, LNCS 4979), April Active Measurement Conference (PAM 2008, LNCS 4979), April
2008, 2008,
<http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>. <http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.
[mdns-scan] [mdns-scan]
Poettering, L., "mdns-scan(1) manual page", 2012, Poettering, L., "mdns-scan(1) manual page", 2012,
<http://manpages.ubuntu.com/manpages/precise/man1/ <http://manpages.ubuntu.com/manpages/precise/man1/
mdns-scan.1.html>. mdns-scan.1.html>.
[nmap2012] [nmap2012]
Fyodor, , "nmap - Network exploration tool and security / Fyodor, , "nmap - Network exploration tool and security /
port scanner", 2012, <http://insecure.org>. port scanner", 2012, <http://insecure.org>.
[VBox2011] [VBox2011]
VirtualBox, , "Oracle VM VirtualBox User Manual, version VirtualBox, , "Oracle VM VirtualBox User Manual, 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", vmware Knowledge Base, August 2011, NIC", 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,
<http://pubs.vmware.com/vsphere-
55/topic/com.vmware.ICbase/PDF/
vsphere-esxi-vcenter-server-552-networking-guide.pdf>.
[traceroute6] [traceroute6]
FreeBSD, , "FreeBSD System Manager's Manual: FreeBSD, , "FreeBSD System Manager's Manual:
traceroute6(8) manual page", 2009, traceroute6(8) manual page", 2009,
<https://www.freebsd.org/cgi/man.cgi?query=traceroute6>. <https://www.freebsd.org/cgi/man.cgi?query=traceroute6>.
[Gont-DEEPSEC2011] [Gont-DEEPSEC2011]
Gont, F., "Results of a Security Assessment of the Gont, F., "Results of a Security Assessment of the
Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Internet Protocol version 6 (IPv6)", DEEPSEC 2011
Conference, Vienna, Austria, November 2011, 2011, Conference, Vienna, Austria, November 2011, 2011,
<http://www.si6networks.com/presentations/deepsec2011/ <http://www.si6networks.com/presentations/deepsec2011/
fgont-deepsec2011-ipv6-security.pdf>. fgont-deepsec2011-ipv6-security.pdf>.
[Gont-LACSEC2013] [Gont-LACSEC2013]
Gont, F., "IPv6 Network Reconnaissance: Theory & Gont, F., "IPv6 Network Reconnaissance: Theory &
Practice", LACSEC 2013 Conference, Medellin, Colombia, May Practice", LACSEC 2013 Conference, Medellin, Colombia,
2013, 2013, May 2013, 2013,
<http://www.si6networks.com/presentations/lacnic19/ <http://www.si6networks.com/presentations/lacnic19/
lacsec2013-fgont-ipv6-network-reconnaissance.pdf>. lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.
[Ford2013] [Ford2013]
Ford, M., "IPv6 Address Analysis - Privacy In, Transition Ford, M., "IPv6 Address Analysis - Privacy In, Transition
Out", 2013, <http://www.internetsociety.org/blog/2013/05/ Out", 2013, <http://www.internetsociety.org/blog/2013/05/
ipv6-address-analysis-privacy-transition-out>. ipv6-address-analysis-privacy-transition-out>.
[THC-IPV6] [THC-IPV6]
"THC-IPV6", <http://www.thc.org/thc-ipv6/>. "THC-IPV6", <http://www.thc.org/thc-ipv6/>.
 End of changes. 68 change blocks. 
165 lines changed or deleted 242 lines changed or added

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