--- 1/draft-ietf-opsec-ipv6-host-scanning-04.txt 2015-01-19 23:14:55.394573955 -0800 +++ 2/draft-ietf-opsec-ipv6-host-scanning-05.txt 2015-01-19 23:14:55.458575513 -0800 @@ -1,19 +1,19 @@ opsec F. Gont Internet-Draft Huawei Technologies Obsoletes: 5157 (if approved) T. Chown Intended status: Informational University of Southampton -Expires: December 16, 2014 June 14, 2014 +Expires: July 23, 2015 January 19, 2015 Network Reconnaissance in IPv6 Networks - draft-ietf-opsec-ipv6-host-scanning-04 + draft-ietf-opsec-ipv6-host-scanning-05 Abstract IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, 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 to perform address scanning attacks against IPv6 networks, and @@ -33,84 +33,86 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 16, 2014. + This Internet-Draft will expire on July 23, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements for the Applicability of Network Reconnaissance Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 5 + 3.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6 3.1.1. StateLess Address Auto-Configuration (SLAAC) . . . . 6 3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10 3.1.4. IPv6 Addresses Corresponding to Transition/Co- existence Technologies . . . . . . . . . . . . . . . 12 3.1.5. IPv6 Address Assignment in Real-world Network - Scenarios . . . . . . . . . . . . . . . . . . . . . . 12 + Scenarios . . . . . . . . . . . . . . . . . . . . . . 13 3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 15 3.2.1. Reducing the subnet ID search space . . . . . . . . . 16 3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 16 3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 17 3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 17 3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 18 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19 4. Leveraging the Domain Name System (DNS) for Network Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 20 4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 20 4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21 5. Leveraging Local Name Resolution and Service Discovery Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21 - 7. Application Participation . . . . . . . . . . . . . . . . . . 22 + 7. Application Participation . . . . . . . . . . . . . . . . . . 21 8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22 9. Inspection of System Configuration and Log Files . . . . . . 22 10. Gleaning Information from Routing Protocols . . . . . . . . . 23 - 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 24 - 15.2. Informative References . . . . . . . . . . . . . . . . . 25 + 11. Gleaning Information from IP Flow Information Export (IPFIX) 23 + 12. Obtaining Network Information with traceroute6 . . . . . . . 23 + 13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 17.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Implementation of a full-fledged IPv6 address- - scanning tool . . . . . . . . . . . . . . . . . . . 27 - A.1. Host-probing considerations . . . . . . . . . . . . . . . 27 - A.2. Implementation of an IPv6 local address-scanning tool . . 29 - A.3. Implementation of a IPv6 remote address-scanning tool . . 30 + scanning tool . . . . . . . . . . . . . . . . . . . 28 + A.1. Host-probing considerations . . . . . . . . . . . . . . . 28 + A.2. Implementation of an IPv6 local address-scanning tool . . 30 + A.3. Implementation of a IPv6 remote address-scanning tool . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction The main driver for IPv6 [RFC2460] deployment is its larger address space [CPNI-IPv6]. This larger address space not only allows for an increased number of connected devices, but also introduces a number of subtle changes in several aspects of the resulting networks. One of these changes is the reduced host density (the number of hosts divided by the number of addresses) of typical IPv6 subnetworks: with @@ -143,34 +145,34 @@ techniques may allow (in some cases) network and security administrators to prevent or detect such attempts. On the other hand, network reconnaissance is essential for the so-called "penetration tests" typically performed to assess the security of production networks. As a result, we believe the benefits of a thorough discussion of IPv6 network reconnaissance are two-fold. Section 3 analyzes the feasibility of traditional address-scanning attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of possible improvements to such techniques. [van-Dijk] describes a - recently-disclosed technique for leveraging DNS reverse mappings for - discovering IPv6 nodes. Finally, Appendix A describes how the - analysis carried out throughout this document can be leveraged to - produce address-scanning tools (e.g. for penetration testing - purposes). + technique for leveraging DNS reverse mappings for discovering IPv6 + nodes. Finally, Appendix A describes how the analysis carried out + throughout this document can be leveraged to produce address-scanning + tools (e.g. for penetration testing purposes). 2. Requirements for the Applicability of Network Reconnaissance Techniques Throughout this document, a number of network reconnaissance techniques are discussed. Each of these techniques have different requirements on the side of the practitioner, with respect to whether they require local access to the target network, and whether they - require login access to the system on which the technique is applied. + require login access (or similar access credentials) to the system on + which the technique is applied. The following table tries to summarize the aforementioned requirements, and serves as a cross index to the corresponding sections. +---------------------------------------------+----------+----------+ | Technique | Local | Login | | | access | access | +---------------------------------------------+----------+----------+ | Local address scans (Section 3.3) | Yes | No | @@ -189,20 +191,26 @@ +---------------------------------------------+----------+----------+ | Inspection of the IPv6 Neighbor Cache and | No | Yes | | Routing Table (Section 8) | | | +---------------------------------------------+----------+----------+ | Inspecting System Configuration and Log | No | Yes | | Files (Section 9) | | | +---------------------------------------------+----------+----------+ | Gleaning information from Routing Protocols | Yes | No | | (Section 10) | | | +---------------------------------------------+----------+----------+ + | Gleaning Information from IP Flow | No | Yes | + | Information Export (IPFIX) (Section 11) | | | + +---------------------------------------------+----------+----------+ + | Obtaining Network Information with | No | No | + | traceroute6 (Section 12) | | | + +---------------------------------------------+----------+----------+ Table 1: Requirements for the Applicability of Network Reconnaissance Techniques 3. IPv6 Address Scanning This section discusses how traditional address scanning techniques (e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an essential analysis of how address configuration is performed in IPv6, identifying patterns in IPv6 addresses that can be leveraged to @@ -329,21 +337,22 @@ bits. 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 in the range 0x000000-0x3fffff (to avoid conflicts with other VMware products). Therefore, even in the case of manually-configured MAC addresses, the IID search space is reduced from 64-bits to 22 bits. 3.1.1.2. Temporary Addresses - Privacy concerns [CPNI-IPv6] [Gont-DEEPSEC2011] regarding interface + Privacy concerns [Gont-DEEPSEC2011] + [I-D.ietf-6man-ipv6-address-generation-privacy] regarding interface identifiers embedding IEEE identifiers led to the introduction of "Privacy Extensions for Stateless Address Auto-configuration in IPv6" [RFC4941], also known as "temporary addresses" or "privacy addresses". Essentially, "temporary addresses" produce random addresses by concatenating a random identifier to the auto- configuration IPv6 prefix advertised in a Router Advertisement. In addition to their unpredictability, these addresses are 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 @@ -407,36 +416,41 @@ IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. Implementation of this method (in replacement of Interface Identifiers based on IEEE identifiers) would eliminate any patterns from the Interface ID, thus benefiting user privacy and reducing the ease with which addresses can be scanned. 3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) - DHCPv6 can be employed as a stateful address configuration mechanism, - in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 - hosts. As with the IPv4 counterpart, addresses are assigned - according to a configuration-defined address range and policy, with - some DHCPv6 servers assigned addresses sequentially, from a specific - range. In such cases, addresses tend to be predictable. + DHC DHCPv6 can be employed as a stateful address configuration + mechanism, in which a server (the DHCPv6 server) leases IPv6 + addresses to IPv6 hosts. As with the IPv4 counterpart, addresses are + assigned according to a configuration-defined address range and + policy, with some DHCPv6 servers assigning addresses sequentially, + from a specific range. In such cases, addresses tend to be + predictable. For example, if the prefix 2001:db8::/64 is used for assigning addresses on the local network, the DHCPv6 server might (sequentially) assign addresses from the range 2001:db8::1 - 2001:db8::100. 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 recommended that DHCPv6 instead issue addresses randomly from a large pool; that advice is repeated here. + [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that + can be employed by DHCPv6 servers to produce stable addresses which + do not follow any specific pattern, thus resulting in an IID search + space of 64 bits. 3.1.3. Manually-configured Addresses In some scenarios, node addresses may be manually configured. This is typically the case for IPv6 addresses assigned to routers (since routers do not employ automatic address configuration) but also for servers (since having a stable address that does not depend on the underlying link-layer address is generally desirable). While network administrators are mostly free to select the IID from @@ -662,38 +677,38 @@ IPv6 address scanning of remote area networks should consider an additional factor not present for the IPv4 case: since the typical IPv6 host subnet is a /64, scanning an entire /64 could, in theory, lead to the creation of 2^64 entries in the Neighbor Cache of the last-hop router. Unfortunately, a number of IPv6 implementations have been found to be unable to properly handle large number of entries in the Neighbor Cache, and hence these address-scan attacks may have the side effect of resulting in a Denial of Service (DoS) attack [CPNI-IPv6] [RFC6583]. - [I-D.ietf-6man-why64] discusses the "default" /64 boundary for host - subnets, and the assumptions surrounding it. While there are reports - of a handful of sites implementing host subnets of size /112 or - smaller to reduce concerns about the above attack, such smaller - subnets are likely to make address-based scanning more feasible, in - addition to encountering the issues with non-/64 host subnets - discussed in the above draft. + [RFC7421] discusses the "default" /64 boundary for host subnets, and + the assumptions surrounding it. While there are reports of a handful + of sites implementing host subnets of size /112 or smaller to reduce + concerns about the above attack, such smaller subnets are likely to + make address-based scanning more feasible, in addition to + encountering the issues with non-/64 host subnets discussed in the + above draft. 3.2.1. Reducing the subnet ID search space When scanning a remote network, consideration is required to 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 be scanned. - However, just as with the search space within a host IID being able - to be reduced, we may also be able to reduce the subnet ID space in a - number of ways, by guessing likely address plan schemes, or using any + 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 + ways, by guessing likely address plan schemes, or using any complementary clues that might exist from other sources or observations. Address plans might include use of subnets which: o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64, etc. o Use building numbers, in hex or decimal form. @@ -900,28 +915,27 @@ important for IPv6, even if it is already good practice to restrict them in the IPv4 world. 4.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. 4.4. DNS Reverse Mappings - An interesting technique that employs DNS reverse mappings for - network reconnaissance has been recently disclosed [van-Dijk]. - 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. + [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::/32"), 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 @@ -955,32 +969,38 @@ 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. 8. 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. + routing table of any system connected to such network. 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. - While the requirement of having "login" access to a system in the - target network 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" 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. + These data structures could be inspected either via "login" access or + via 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 [I-D.ietf-opsec-v6] discusses additional + considerations for the inspection of the IPv6 Neighbor Cache. 9. 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, SSH known_hosts files, or the Microsoft Windows registry are just some examples of places where interesting information about such systems might be found. @@ -995,24 +1015,36 @@ 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]. 10. 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 within that organization - [V6-WORMS]. + protocol, to determine other valid subnets/prefixes and some router + addresses within that organization [V6-WORMS]. -11. Conclusions +11. 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 [I-D.ietf-opsec-v6]. + +12. Obtaining Network Information with traceroute6 + + IPv6 traceroute [traceroute6] can be employed to find router + addresses and valid network prefixes. + +13. 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 privacy-enhanced IIDs (which will require support from system @@ -1024,95 +1056,104 @@ 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. -12. IANA Considerations +14. 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. -13. Security Considerations +15. Security Considerations This document explores the topic of Network Reconnaissance in IPv6 networks. It analyzes the feasibility of address-scan attacks in IPv6 networks, and showing that the search space for such attacks is 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 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. -14. Acknowledgements +16. Acknowledgements The authors would like to thank (in alphabetical order) Marc Heuse, - Ray Hunter, Libor Polcak, Jan Schaumann, and Arturo Servin, for - providing valuable comments on earlier versions of this document. + Ray Hunter, Libor Polcak, 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 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 the UK CPNI for their continued support. -15. References +17. References -15.1. Normative References +17.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + [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, May 2012. + [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. + [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow + Information Export (IPFIX)", RFC 7012, September 2013. + [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014. [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014. -15.2. Informative References +17.2. Informative References [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007. [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007. [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008. @@ -1124,37 +1165,47 @@ February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. [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.ietf-6man-why64] - Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, + [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary - in IPv6 Addressing", draft-ietf-6man-why64-01 (work in - progress), May 2014. + in IPv6 Addressing", RFC 7421, January 2015. [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and W. Will, "Recommendation on Stable IPv6 Interface Identifiers", - draft-ietf-6man-default-iids-00 (work in progress), - January 2014. + draft-ietf-6man-default-iids-01 (work in progress), + October 2014. [I-D.ietf-6man-ipv6-address-generation-privacy] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", - draft-ietf-6man-ipv6-address-generation-privacy-01 (work - in progress), February 2014. + draft-ietf-6man-ipv6-address-generation-privacy-03 (work + in progress), January 2015. + + [I-D.ietf-dhc-stable-privacy-addresses] + Gont, F. and W. Will, "A Method for Generating + Semantically Opaque Interface Identifiers with Dynamic + Host Configuration Protocol for IPv6 (DHCPv6)", draft- + ietf-dhc-stable-privacy-addresses-00 (work in progress), + October 2014. + + [I-D.ietf-opsec-v6] + Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational + Security Considerations for IPv6 Networks", draft-ietf- + opsec-v6-05 (work in progress), October 2014. [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). [V6-WORMS] Bellovin, S., Cheswick, B., and A. Keromytis, "Worm propagation strategies in an IPv6 Internet", ;login:, pages 70-76, February 2006, @@ -1178,20 +1229,25 @@ [VBox2011] VirtualBox, , "Oracle VM VirtualBox User Manual, version 4.1.2", August 2011, . [vmesx2011] vmware, , "Setting a static MAC address for a virtual NIC", vmware Knowledge Base, August 2011, . + [traceroute6] + FreeBSD, , "FreeBSD System Manager's Manual: + traceroute6(8) manual page", 2009, + . + [Ybema2010] Ybema, I., "just seen my first IPv6 network abuse scan, is this the start for more?", Post to the NANOG mailing-list, 2010, . [Gont-DEEPSEC2011] Gont, F., "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, 2011,