RFC 7707
Network Reconnaissance in IPv6 Networks
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 should not discourage the elimination of IPv6 address patterns: if any address patterns are eliminated from addresses published in the 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 generally less reliable and more time/traffic consuming than mapping nodes with predictable IPv6 addresses).5.1.2. DNS Zone Transfers
A DNS zone transfer (DNS query type "AXFR") [RFC1034] [RFC1035] can readily provide information about potential attack targets. Restricting zone transfers is thus probably more important for IPv6, even if it is already good practice to restrict them in the IPv4 world.5.1.3. DNS Brute Forcing
Attackers may employ DNS brute-forcing techniques by testing for the presence of DNS AAAA records against commonly used host names.
5.1.4. DNS Reverse Mappings
[van-Dijk] describes an interesting technique that employs DNS reverse mappings for network reconnaissance. Essentially, the 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 network (assuming that the reverse mappings have been configured, of course). What is most interesting about this technique is that it can greatly reduce the IPv6 address search space. 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 "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.", "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 "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 contain an RCODE of 0 (no error). Otherwise, the response would contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this technique allows for a tremendous reduction in the "IPv6 address" search space. NOTE: Some name servers, incorrectly implementing the DNS protocol, reply NXDOMAIN instead of NODATA (NOERROR=0 and ANSWER=0) when 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. [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 service. For example, mDNS [RFC6762] and DNS Service Discovery (DNS- SD) [RFC6763], or Link-Local Multicast Name Resolution (LLMNR) [RFC4795], are examples of such protocols.
NOTE:
Besides the Graphical User Interfaces (GUIs) included in products
supporting such protocols, command-line tools such as mdns-scan
[mdns-scan] and mzclient [mzclient] can help discover IPv6 hosts
employing mDNS/DNS-SD.
5.3. Public Archives
Public mailing-list archives or Usenet news messages archives may
prove to be a useful channel for an attacker, since hostnames and/or
IPv6 addresses could be easily obtained by inspection of the (many)
"Received from:" or other header lines in the archived email or
Usenet news messages.
5.4. Application Participation
Peer-to-peer applications often include some centralized server that
coordinates the transfer of data between peers. For example,
BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks
of files, with a tracker passing information about peers with
available chunks of data between the peers. Such applications may
offer an attacker a source of peer addresses to probe.
5.5. Inspection of the IPv6 Neighbor Cache and Routing Table
Information about other systems connected to the local network might
be readily available from the Neighbor Cache [RFC4861] and/or the
routing table of any system connected to such network. Source
Address Validation Improvement (SAVI) [RFC6620] also builds a cache
of IPv6 and link-layer addresses (without actively participating in
the Neighbor Discovery packet exchange) and hence is another source
of similar information.
These data structures could be inspected via either "login" access or
SNMP. While this requirement may limit the applicability of this
technique, there are a number of scenarios in which this technique
might be of use. For example, security audit tools might be provided
with the necessary credentials such that the Neighbor Cache and the
routing table of all systems for which the tool has "login" or SNMP
access can be automatically gleaned. On the other hand, IPv6 worms
[V6-WORMS] could leverage this technique for the purpose of spreading
on the local network, since they will typically have access to the
Neighbor Cache and routing table of an infected system.
Section 2.5.1.4 of [OPSEC-IPv6] discusses additional considerations
for the inspection of the IPv6 Neighbor Cache.
5.6. Inspection of System Configuration and Log Files
Nodes are generally configured with the addresses of other important local computers, such as email servers, local file servers, web proxy servers, recursive DNS servers, etc. The /etc/hosts file in UNIX- like systems, Secure Shell (SSH) known_hosts files, or the Microsoft Windows registry are just some examples of places where interesting information about such systems might be found. Additionally, system log files (including web server logs, etc.) may also prove to be a useful source for an attacker. While the required credentials to access the aforementioned configuration and log files may limit the applicability of this technique, there are a number of scenarios in which this technique might be of use. For example, security audit tools might be provided with the necessary credentials such that these files can be automatically accessed. On the other hand, IPv6 worms could leverage this technique for the purpose of spreading on the local network, since they will typically have access to these files on an infected system [V6-WORMS].5.7. Gleaning Information from Routing Protocols
Some organizational IPv6 networks employ routing protocols to dynamically maintain routing information. In such an environment, a local attacker could become a passive listener of the routing protocol, to determine other valid subnets/prefixes and some router addresses within that organization [V6-WORMS].5.8. Gleaning Information from IP Flow Information Export (IPFIX)
IPFIX [RFC7012] can aggregate the flows by source addresses and hence may be leveraged for obtaining a list of "active" IPv6 addresses. Additional discussion of IPFIX can be found in Section 2.5.1.2 of [OPSEC-IPv6].5.9. Obtaining Network Information with traceroute6
IPv6 traceroute [traceroute6] and similar tools (such as path6 from [IPv6-Toolkit]) can be employed to find router addresses and valid network prefixes.
5.10. Gleaning Information from Network Devices Using SNMP
SNMP can be leveraged to obtain information from a number of data structures such as the Neighbor Cache [RFC4861], the routing table, and the SAVI [RFC6620] cache of IPv6 and link-layer addresses. SNMP access should be secured, such that unauthorized access to the aforementioned information is prevented.5.11. Obtaining Network Information via Traffic Snooping
Snooping network traffic can help in discovering active nodes in a number of ways. Firstly, each captured packet will reveal the source and destination of the packet. Secondly, the captured traffic may correspond to network protocols that transfer information such as host or router addresses, network topology information, etc.6. Conclusions
This document explores the topic of network reconnaissance in IPv6 networks. It analyzes the feasibility of address-scanning attacks in IPv6 networks and shows that the search space for such attacks is typically much smaller than the one traditionally assumed (64 bits). Additionally, this document explores a plethora of other network reconnaissance techniques, ranging from inspecting the IPv6 Network Cache of an attacker-controlled system to gleaning information about IPv6 addresses from public mailing-list archives or Peer-to-Peer (P2P) protocols. We expect traditional address-scanning attacks to become more and more elaborated (i.e., less "brute force"), and other network reconnaissance techniques to be actively explored, as global deployment of IPv6 increases and, more specifically, as more IPv6-only devices are deployed.7. Security Considerations
This document reviews methods by which addresses of hosts within IPv6 subnets can be determined. As such, it raises no new security concerns.
8. References
8.1. Normative 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>. [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 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 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 Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <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 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 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 Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.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 Multicast Name Resolution (LLMNR)", RFC 4795, DOI 10.17487/RFC4795, January 2007, <http://www.rfc-editor.org/info/rfc4795>. [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 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 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., and C. Hahn, "IPv6 Unicast Address Assignment 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 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, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>. [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <http://www.rfc-editor.org/info/rfc7421>. [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>. [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>. [SMURF-AMPLIFIER] Gont, F. and W. Liu, "Security Implications of IPv6 Options of Type 10xxxxxx", Work in Progress, draft-gont- 6man-ipv6-smurf-amplifier-03, March 2013. [THC-IPV6] "THC-IPV6", <http://www.thc.org/thc-ipv6/>. [traceroute6] FreeBSD, "FreeBSD System Manager's Manual: traceroute6(8) manual page", August 2009, <https://www.freebsd.org/cgi/ man.cgi?query=traceroute6>. [V6-WORMS] Bellovin, S., Cheswick, B., and A. Keromytis, "Worm propagation strategies in an IPv6 Internet", Vol. 31, No. 1, pp. 70-76, February 2006, <https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>. [van-Dijk] van Dijk, P., "Finding v6 hosts by efficiently mapping ip6.arpa", March 2012, <http://7bits.nl/blog/2012/03/26/ finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.
[VBox2011] VirtualBox, "Oracle VM VirtualBox User Manual", Version 4.1.2, August 2011, <http://www.virtualbox.org>. [vmesx2011] VMware, "Setting a static MAC address for a virtual NIC (219)", VMware Knowledge Base, August 2011, <http://kb.vmware.com/selfservice/microsites/ search.do?language=en_US&cmd=displayKC&externalId=219>. [vSphere] VMware, "vSphere Networking", vSphere 5.5, Update 2, September 2014, <http://pubs.vmware.com/ vsphere-55/topic/com.vmware.ICbase/PDF/ vsphere-esxi-vcenter-server-552-networking-guide.pdf>.
Appendix A. Implementation of a Full-Fledged IPv6 Address-Scanning Tool
This section describes the implementation of a full-fledged IPv6 address-scanning tool. Appendix A.1 discusses the selection of host probes. Appendix A.2 describes the implementation of an IPv6 address scanner for local area networks. Appendix A.3 outlines the implementation of a general (i.e., non-local) IPv6 address scanner.A.1. Host-Probing Considerations
A number of factors should be considered when selecting the probe packet types and the probing rate for an IPv6 address-scanning tool. Firstly, some hosts (or border firewalls) might be configured to block or rate limit some specific packet types. For example, it is usual for host and router implementations to rate-limit ICMPv6 error traffic. Additionally, some firewalls might be configured to block or rate limit incoming ICMPv6 echo request packets (see, e.g., [RFC4890]). NOTE: As noted earlier in this document, Windows systems simply do not respond to ICMPv6 echo requests sent to multicast IPv6 addresses. Among the possible probe types are: 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 segments that do not contain the ACK bit set (meant to elicit RST segments), o UDP datagrams (meant to elicit a UDP application response or an ICMPv6 Port Unreachable), o IPv6 packets containing any suitable payload and an unrecognized extension header (meant to elicit ICMPv6 Parameter Problem error messages), or o IPv6 packets containing any suitable payload and an unrecognized option of type 10xxxxxx (meant to elicit an ICMPv6 Parameter Problem error message). Selecting an appropriate probe packet might help conceal the ongoing attack, but it may also be actually necessary if host or network configuration causes certain probe packets to be dropped.
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 the attack. However, the probing rate should not be too high, or else: 1. the attack might cause network congestion, 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 Neighbor Discovery implementations, thus leading to packet loss and possibly even Denial of Service. Packet loss is undesirable, since it would mean that an "alive" node might remain undetected as a result of a lost probe or response. 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 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). Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router implementations have been found to be unable to perform decent resource management when faced with Neighbor Discovery traffic involving a large number of local nodes. This essentially means that regardless of the type of probe packets, an address-scanning attack might result in a DoS of the target network, with the same (or worse) effects as that of network congestion or rate limiting. 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 routers/firewalls, configuration parameters, etc.A.2. Implementation of an IPv6 Local Address-Scanning Tool
scan6 [IPv6-Toolkit] is a full-fledged IPv6 local address-scanning tool, which has proven to be effective and efficient for the discovery of IPv6 hosts on a local network.
The scan6 tool operates (roughly) as follows:
1. The tool learns the local prefixes used for autoconfiguration and
generates/configures one address for each local prefix (in
addition to a link-local address).
2. An ICMPv6 Echo Request message destined to the all-nodes on-link
multicast address (ff02::1) is sent from each of the addresses
"configured" in the previous step. Because of the different
source addresses, each probe packet causes the victim nodes to
use different source addresses for the response packets (this
allows the tool to learn virtually all the addresses in use in
the local network segment).
3. The same procedure of the previous bullet is performed, but this
time with ICMPv6 packets that contain an unrecognized option of
type 10xxxxxx, such that ICMPv6 Parameter Problem error messages
are elicited. This allows the tool to discover, e.g., Windows
nodes, which otherwise do not respond to multicasted ICMPv6 Echo
Request messages.
4. Each time a new "alive" address is discovered, the corresponding
IID is combined with all the local prefixes, and the resulting
addresses are probed (with unicasted packets). This can help to
discover other addresses in use on the local network segment,
since the same IID is typically used with all the available
prefixes for the local network.
NOTE:
The aforementioned scheme can fail to discover some addresses for
some implementations. For example, Mac OS X employs IPv6
addresses embedding IEEE identifiers (rather than "temporary
addresses") when responding to packets destined to a link-local
multicast address, sourced from an on-link prefix.
A.3. Implementation of an IPv6 Remote Address-Scanning Tool
An IPv6 remote address-scanning tool could be implemented with the
following features:
o The tool can be instructed to target specific address ranges
(e.g., 2001:db8::0-10:0-1000).
o The tool can be instructed to scan for SLAAC addresses of a
specific vendor, such that only addresses embedding the
corresponding IEEE OUIs are probed.
o The tool can be instructed to scan for SLAAC addresses that employ
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
a given IPv6 prefix is only scanned for the address patterns
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 wordy addresses, in which
case the tool selects addresses based on a local dictionary.
o The tool can be instructed to scan for IPv6 addresses embedding
TCP/UDP service ports, in which case the tool selects addresses
based on a list of well-known service ports.
o The tool can be specified to scan an IPv4 address range in use at
the target network, such that only IPv4-based IPv6 addresses are
scanned.
The scan6 tool of [IPv6-Toolkit] implements all these techniques/
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
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot. OX11 0SG United Kingdom Email: tim.chown@jisc.ac.uk