draft-ietf-opsec-ipv6-host-scanning-05.txt		draft-ietf-opsec-ipv6-host-scanning-06.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: July 23, 2015 January 19, 2015		Expires: August 9, 2015 February 5, 2015
	Network Reconnaissance in IPv6 Networks		Network Reconnaissance in IPv6 Networks
	draft-ietf-opsec-ipv6-host-scanning-05		draft-ietf-opsec-ipv6-host-scanning-06
	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
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	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 July 23, 2015.		This Internet-Draft will expire on August 9, 2015.
	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 35		skipping to change at page 2, line 35
	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) . . . . . . . . . . . . . . . . . . . . . . 10
	3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10		3.1.3. Manually-configured Addresses . . . . . . . . . . . . 10
	3.1.4. IPv6 Addresses Corresponding to Transition/Co-		3.1.4. IPv6 Addresses Corresponding to Transition/Co-
	existence Technologies . . . . . . . . . . . . . . . 12		existence Technologies . . . . . . . . . . . . . . . 12
	3.1.5. IPv6 Address Assignment in Real-world Network		3.1.5. IPv6 Address Assignment in Real-world Network
	Scenarios . . . . . . . . . . . . . . . . . . . . . . 13		Scenarios . . . . . . . . . . . . . . . . . . . . . . 13
	3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 15		3.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 16
	3.2.1. Reducing the subnet ID search space . . . . . . . . . 16		3.2.1. Reducing the subnet ID search space . . . . . . . . . 16
	3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 16		3.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 17
	3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 17		3.4. Existing IPv6 Address Scanning Tools . . . . . . . . . . 18
	3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 17		3.4.1. Remote IPv6 Network Scanners . . . . . . . . . . . . 18
	3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 18		3.4.2. Local IPv6 Network Scanners . . . . . . . . . . . . . 19
	3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19		3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 19
	4. Leveraging the Domain Name System (DNS) for Network		4. Leveraging the Domain Name System (DNS) for Network
	Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20		Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 20
	4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20		4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . 20
	4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 20		4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . 21
	4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 20		4.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . . . 21
	4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21		4.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . . . 21
	5. Leveraging Local Name Resolution and Service Discovery		5. Leveraging Local Name Resolution and Service Discovery
	Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21		Services . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 21		6. Public Archives . . . . . . . . . . . . . . . . . . . . . . . 22
	7. Application Participation . . . . . . . . . . . . . . . . . . 21		7. Application Participation . . . . . . . . . . . . . . . . . . 22
	8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22		8. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 22
	9. Inspection of System Configuration and Log Files . . . . . . 22		9. Inspection of System Configuration and Log Files . . . . . . 23
	10. Gleaning Information from Routing Protocols . . . . . . . . . 23		10. Gleaning Information from Routing Protocols . . . . . . . . . 23
	11. Gleaning Information from IP Flow Information Export (IPFIX) 23		11. Gleaning Information from IP Flow Information Export (IPFIX) 23
	12. Obtaining Network Information with traceroute6 . . . . . . . 23		12. Obtaining Network Information with traceroute6 . . . . . . . 23
	13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23		13. Gleaning Information from Network Devices Using SNMP . . . . 23
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		14. Obtaining Network Information via Traffic Snooping . . . . . 24
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 24		15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
	16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		17. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	17.1. Normative References . . . . . . . . . . . . . . . . . . 24		18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	17.2. Informative References . . . . . . . . . . . . . . . . . 25		19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
			19.1. Normative References . . . . . . . . . . . . . . . . . . 25
			19.2. Informative References . . . . . . . . . . . . . . . . . 26
	Appendix A. Implementation of a full-fledged IPv6 address-		Appendix A. Implementation of a full-fledged IPv6 address-
	scanning tool . . . . . . . . . . . . . . . . . . . 28		scanning tool . . . . . . . . . . . . . . . . . . . 29
	A.1. Host-probing considerations . . . . . . . . . . . . . . . 28		A.1. Host-probing considerations . . . . . . . . . . . . . . . 29
	A.2. Implementation of an IPv6 local address-scanning tool . . 30		A.2. Implementation of an IPv6 local address-scanning tool . . 31
	A.3. Implementation of a IPv6 remote address-scanning tool . . 31		A.3. Implementation of a IPv6 remote address-scanning tool . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	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: with
	default IPv6 subnets of /64, each subnet comprises more than 1.844 *		default IPv6 subnets of /64, each subnet comprises more than 1.844 *
	skipping to change at page 5, line 38		skipping to change at page 5, line 38
	+---------------------------------------------+----------+----------+		+---------------------------------------------+----------+----------+
	| Gleaning information from Routing Protocols | Yes | No |		| Gleaning information from Routing Protocols | Yes | No |
	| (Section 10) | | |		| (Section 10) | | |
	+---------------------------------------------+----------+----------+		+---------------------------------------------+----------+----------+
	| Gleaning Information from IP Flow | No | Yes |		| Gleaning Information from IP Flow | No | Yes |
	| Information Export (IPFIX) (Section 11) | | |		| Information Export (IPFIX) (Section 11) | | |
	+---------------------------------------------+----------+----------+		+---------------------------------------------+----------+----------+
	| Obtaining Network Information with | No | No |		| Obtaining Network Information with | No | No |
	| traceroute6 (Section 12) | | |		| traceroute6 (Section 12) | | |
	+---------------------------------------------+----------+----------+		+---------------------------------------------+----------+----------+
			| Gleaning Information from Network Devices | No | Yes |
			| Using SNMP | | |
			+---------------------------------------------+----------+----------+
			| Obtaining Network Information via Traffic | Yes | No |
			| Snooping | | |
			+---------------------------------------------+----------+----------+
	Table 1: Requirements for the Applicability of Network Reconnaissance		Table 1: Requirements for the Applicability of Network Reconnaissance
	Techniques		Techniques
	3. IPv6 Address Scanning		3. IPv6 Address Scanning
	This section discusses how traditional address scanning techniques		This section discusses how traditional address scanning techniques
	(e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an		(e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an
	essential analysis of how address configuration is performed in IPv6,		essential analysis of how address configuration is performed in IPv6,
	identifying patterns in IPv6 addresses that can be leveraged to		identifying patterns in IPv6 addresses that can be leveraged to
	skipping to change at page 16, line 24		skipping to change at page 16, line 43
	When scanning a remote network, consideration is required to select		When scanning a remote network, consideration is required to select
	which subnet IDs to choose. A typical site might have a /48		which subnet IDs to choose. A typical site might have a /48
	allocation, which would mean up to 65,000 or so host /64 subnets to		allocation, which would mean up to 65,000 or so host /64 subnets to
	be scanned.		be scanned.
	However, in the same way the search space for the IID can be reduced,		However, in the same way the search space for the IID can be reduced,
	we may also be able to reduce the subnet ID space in a number of		we may also be able to reduce the subnet ID space in a number of
	ways, by guessing likely address plan schemes, or using any		ways, by guessing likely address plan schemes, or using any
	complementary clues that might exist from other sources or		complementary clues that might exist from other sources or
	observations.		observations. For example there are a number of documents available
			online (e.g. [RFC5375]) that provide recommendations for allocation
			of address space, which address various operational considerations,
			including: RIR assignment policy, ability to delegate reverse DNS
			zones to different servers, ability to aggregate routes efficiently,
			address space preservation, ability to delegate address assignment
			within the organization, ability to add allocate new sites/prefixes
			to existing entities without updating ACLs, and ability to de-
			aggregate and advertise sub-spaces via various AS interfaces.
	Address plans might include use of subnets which:		Address plans might include use of subnets which:
	o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64,		o Run from low ID upwards, e.g. 2001:db8:0::/64, 2001:db8:1::/64,
	etc.		etc.
	o Use building numbers, in hex or decimal form.		o Use building numbers, in hex or decimal form.
	o Use VLAN numbers.		o Use VLAN numbers.
	o Use IPv4 subnet number in a dual-stack target, e.g. a site with a		o Use IPv4 subnet number in a dual-stack target, e.g. a site with a
	/16 for IPv4 might use /24 subnets, and the IPv6 address plan may		/16 for IPv4 might use /24 subnets, and the IPv6 address plan may
	re-use the third byte as the IPv6 subnet ID.		re-use the third byte as the IPv6 subnet ID.
	o Use the service "colour", as defined for service-based prefix		o Use the service "colour", as defined for service-based prefix
	colouring, or semantic prefixes. For example, a site using a		colouring, or semantic prefixes. For example, a site using a
	specific colouring for a specific service such as VoIP may reduce		specific colouring for a specific service such as VoIP may reduce
	the subnet ID search space for those devices.		the subnet ID search space for those devices.
			The net effect is that the address space of an organization may be
			highly structured, and allocations of individual elements within this
			structure may be predictable once other elements are known.
	In general, any subnet ID address plan may convey information, or be		In general, any subnet ID address plan may convey information, or be
	based on known information, which may in turn be of advantage to an		based on known information, which may in turn be of advantage to an
	attacker.		attacker.
	3.3. IPv6 Address Scanning of Local Networks		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
	skipping to change at page 18, line 16		skipping to change at page 18, line 47
	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.
	The most "advanced" IPv6 scanning technique that has been found in
	the wild (and publicly reported) is described in [Ybema2010] (the
	attacker seemed to be scanning specific IPv6 addresses based on some
	specific patterns). However, the aforementioned attempt probably
	still falls into the category of "rudimentary".
	It should be noted that IPv6 network monitoring and management tools		It should be noted that IPv6 network monitoring and management tools
	also need to build and maintain information about the hosts in their		also need to build and maintain information about the hosts in their
	network. Such systems can no longer scan internal systems in a		network. Such systems can no longer scan internal systems in a
	reasonable time to build a database of connected systems. Rather,		reasonable time to build a database of connected systems. Rather,
	such systems will need more efficient approaches, e.g. by polling		such systems will need more efficient approaches, e.g. by polling
	network devices for data held about observed IP addresses, MAC		network devices for data held about observed IP addresses, MAC
	addresses, physical ports used, etc. Such an approach can also		addresses, physical ports used, etc. Such an approach can also
	enhance address accountability, by mapping IPv4 and IPv6 addresses to		enhance address accountability, by mapping IPv4 and IPv6 addresses to
	observed MAC addresses. This of course implies that any access		observed MAC addresses. This of course implies that any access
	control mechanisms for querying such network devices, e.g. community		control mechanisms for querying such network devices, e.g. community
	skipping to change at page 23, line 25		skipping to change at page 23, line 47
	IPFIX [RFC7012] can aggregate the flows by source addresses, and		IPFIX [RFC7012] can aggregate the flows by source addresses, and
	hence may be leveraged for obtaining a list of "active" IPv6		hence may be leveraged for obtaining a list of "active" IPv6
	addresses. Additional discussion of IPFIX can be found in		addresses. Additional discussion of IPFIX can be found in
	Section 2.5.1.2 of [I-D.ietf-opsec-v6].		Section 2.5.1.2 of [I-D.ietf-opsec-v6].
	12. Obtaining Network Information with traceroute6		12. Obtaining Network Information with traceroute6
	IPv6 traceroute [traceroute6] can be employed to find router		IPv6 traceroute [traceroute6] can be employed to find router
	addresses and valid network prefixes.		addresses and valid network prefixes.
	13. Conclusions		13. 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.
			14. 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.
			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		privacy-enhanced IIDs (which will require support from system
	skipping to change at page 24, line 5		skipping to change at page 24, line 41
	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
	potentially "easier" target, if the implementation of security		potentially "easier" target, if the implementation of security
	policies are not as strict for IPv6 (for whatever reason). As and		policies are not as strict for IPv6 (for whatever reason). As and
	when IPv6-only networks become more common, the considerations in		when IPv6-only networks become more common, the considerations in
	this document will be of much greater importance.		this document will be of much greater importance.
	14. IANA Considerations		16. IANA Considerations
	There are no IANA registries within this document. The RFC-Editor		There are no IANA registries within this document. The RFC-Editor
	can remove this section before publication of this document as an		can remove this section before publication of this document as an
	RFC.		RFC.
	15. Security Considerations		17. Security Considerations
	This document explores the topic of Network Reconnaissance in IPv6		This document explores the topic of Network Reconnaissance in IPv6
	networks. It analyzes the feasibility of address-scan attacks in		networks. It analyzes the feasibility of address-scan attacks in
	IPv6 networks, and showing that the search space for such attacks is		IPv6 networks, and showing that the search space for such attacks is
	typically much smaller than the one traditionally assumed (64 bits).		typically much smaller than the one traditionally assumed (64 bits).
	Additionally, it explores a plethora of other network reconnaissance		Additionally, it explores a plethora of other network reconnaissance
	techniques, ranging from inspecting the IPv6 Network Cache of an		techniques, ranging from inspecting the IPv6 Network Cache of an
	attacker-controlled system, to gleaning information about IPv6		attacker-controlled system, to gleaning information about IPv6
	addresses from public mailing-list archives or Peer-To-Peer (P2P)		addresses from public mailing-list archives or Peer-To-Peer (P2P)
	protocols.		protocols.
	We expect traditional address-scanning attacks to become more and		We expect traditional address-scanning attacks to become more and
	more elaborated (i.e., less "brute force"), and other network		more elaborated (i.e., less "brute force"), and other network
	reconnaissance techniques to be actively explored, as global		reconnaissance techniques to be actively explored, as global
	deployment of IPv6 increases and. more specifically, as more		deployment of IPv6 increases and. more specifically, as more
	IPv6-only devices are deployed.		IPv6-only devices are deployed.
	16. Acknowledgements		18. Acknowledgements
			The authors would like to thank Ray Hunter, who provided valuable
			text that was readily incorporated into Section 3.2.1 of this
			document.
	The authors would like to thank (in alphabetical order) Marc Heuse,		The authors would like to thank (in alphabetical order) Marc Heuse,
	Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric		Ray Hunter, Libor Polcak, Jan Schaumann, Arturo Servin, and Eric
	Vyncke, for providing valuable comments on earlier versions of this		Vyncke, for providing valuable comments on earlier versions of this
	document.		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		Fernando Gont would like to thank the UK CPNI for their continued
	support.		support.
	17. References		19. References
	17.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, December 1998.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[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
	skipping to change at page 25, line 39		skipping to change at page 26, line 34
	[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow		[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
	Information Export (IPFIX)", RFC 7012, September 2013.		Information Export (IPFIX)", RFC 7012, September 2013.
	[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, February 2014.
	[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, April 2014.
	17.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, January
	2007.		2007.
	[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, May 2007.
	[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC		[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC
	5157, March 2008.		5157, March 2008.
			[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
			and C. Hahn, "IPv6 Unicast Address Assignment
			Considerations", RFC 5375, December 2008.
	[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational		[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
	Neighbor Discovery Problems", RFC 6583, March 2012.		Neighbor Discovery Problems", RFC 6583, March 2012.
	[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
	February 2013.		February 2013.
	[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service		[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
	Discovery", RFC 6763, February 2013.		Discovery", RFC 6763, February 2013.
	[I-D.gont-6man-ipv6-smurf-amplifier]		[I-D.gont-6man-ipv6-smurf-amplifier]
	skipping to change at page 26, line 23		skipping to change at page 27, line 23
	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.
	[RFC7421] 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		A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
	in IPv6 Addressing", RFC 7421, January 2015.		in IPv6 Addressing", RFC 7421, January 2015.
	[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 W. Will,
	"Recommendation on Stable IPv6 Interface Identifiers",		"Recommendation on Stable IPv6 Interface Identifiers",
	draft-ietf-6man-default-iids-01 (work in progress),		draft-ietf-6man-default-iids-02 (work in progress),
	October 2014.		January 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-03 (work		draft-ietf-6man-ipv6-address-generation-privacy-03 (work
	in progress), January 2015.		in progress), January 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 W. Will, "A Method for Generating
	Semantically Opaque Interface Identifiers with Dynamic		Semantically Opaque Interface Identifiers with Dynamic
	skipping to change at page 27, line 41		skipping to change at page 28, line 41
	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>.
	[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>.
	[Ybema2010]
	Ybema, I., "just seen my first IPv6 network abuse scan, is
	this the start for more?", Post to the NANOG mailing-list,
	2010, <http://mailman.nanog.org/pipermail/
	nanog/2010-September/025049.html>.
	[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, May
End of changes. 24 change blocks.
	47 lines changed or deleted		79 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/