draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02.txt		draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt
	Operational Security Capabilities for F. Gont		Operational Security Capabilities for F. Gont
	IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH		IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH
	Internet-Draft W. Liu		Internet-Draft W. Liu
	Intended status: Informational Huawei Technologies		Intended status: Informational Huawei Technologies
	Expires: July 1, 2013 December 28, 2012		Expires: August 26, 2013 February 22, 2013
	Security Implications of IPv6 on IPv4 Networks		Security Implications of IPv6 on IPv4 Networks
	draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02		draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03
	Abstract		Abstract
	This document discusses the security implications of native IPv6		This document discusses the security implications of native IPv6
	support and IPv6 transition/co-existence technologies on "IPv4-only"		support and IPv6 transition/co-existence technologies on "IPv4-only"
	networks, and describes possible mitigations for the aforementioned		networks, and describes possible mitigations for the aforementioned
	issues.		issues.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 1, 2013.		This Internet-Draft will expire on August 26, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5		2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5
	3. Security Implications of Tunneling Mechanisms . . . . . . . . 7		3. Security Implications of Tunneling Mechanisms . . . . . . . . 7
	3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8		3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9		3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9
	3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9		3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9
	3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10		3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10
	3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10		3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10
	3.7. Filtering Tunnel Broker with Tunnel Setup Protocol		3.7. Filtering Tunnel Broker with Tunnel Setup Protocol
	(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12		(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Additional Considerations when Filtering IPv6 Traffic . . . . 13		3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		4. Additional Considerations when Filtering IPv6 Traffic . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	Appendix A. Summary of filtering rules . . . . . . . . . . . . . 20		8.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Most general-purpose operating systems implement and enable by		Most general-purpose operating systems implement and enable native
	default native IPv6 [RFC2460] support and a number of transition/		IPv6 [RFC2460] support and a number of transition/co-existence
	co-existence technologies. In those cases in which the corresponding		technologies by default. For cases in which the corresponding
	devices are deployed on networks that are assumed to be IPv4-only,		devices are deployed on networks that are assumed to be IPv4-only,
	native IPv6 support and/or IPv6 transition/co-existence technologies		native IPv6 support and/or IPv6 transition/co-existence technologies
	could be leveraged by local or remote attackers for a number of		could be leveraged by local or remote attackers for a number of
	(illegitimate) purposes. For example,		(illegitimate) purposes. For example,
	o A Network Intrusion Detection System (NIDS) might be prepared to		o A Network Intrusion Detection System (NIDS) might be prepared to
	detect attack patterns for IPv4 traffic, but might be unable to		detect attack patterns for IPv4 traffic, but might be unable to
	detect the same attack patterns when a transition/co-existence		detect the same attack patterns when a transition/co-existence
	technology is leveraged for that purpose.		technology is leveraged for that purpose.
	o An IPv4 firewall might enforce a specific security policy in IPv4,		o An IPv4 firewall might enforce a specific security policy in IPv4,
	but might be unable to enforce the same policy in IPv6.		but might be unable to enforce the same policy in IPv6.
	o Some transition/co-existence mechanisms might cause an internal		o A NIDS or firewall might support both IPv4 and IPv6, but might be
			not be configured to enforce on IPv6 traffic the same controls/
			policies it enforces on IPv4 traffic.
			o Some transition/co-existence mechanisms could cause an internal
	host with otherwise limited IPv4 connectivity to become globally		host with otherwise limited IPv4 connectivity to become globally
	reachable over IPv6, therefore resulting in increased (and		reachable over IPv6, therefore resulting in increased (and
	possibly unexpected) host exposure.		possibly unexpected) host exposure.
	Some transition/co-existence mechanisms (notably Teredo) are		Some transition/co-existence mechanisms (notably Teredo) are
	designed to traverse Network Address Port Translation (NAPT)		designed to traverse Network Address Port Translation (NAPT)
	[RFC2663] devices, allowing incoming IPv6 connections from the		[RFC2663] devices, allowing incoming IPv6 connections from the
	Internet to hosts behind the organizational firewall or NAPT		Internet to hosts behind the organizational firewall or NAPT
	(which in many deployments provides a minimum level of		(which in many deployments provides a minimum level of
	protection by only allowing those instances of communication		protection by only allowing those instances of communication
	that have been initiated from the internal network).		that have been initiated from the internal network).
	o IPv6 support might, either inadvertently or as a result of a		o IPv6 support could, either inadvertently or as a result of a
	deliberate attack, result in VPN traffic leaks if IPv6-unaware		deliberate attack, result in VPN traffic leaks if IPv6-unaware
	Virtual Private Network (VPN) software is employed by dual-stacked		Virtual Private Network (VPN) software is employed by dual-stacked
	hosts [I-D.ietf-opsec-vpn-leakages].		hosts [I-D.ietf-opsec-vpn-leakages].
	In general, most of the aforementioned security implications can be		In general, most of the aforementioned security implications can be
	mitigated by enforcing security controls on native IPv6 traffic and		mitigated by enforcing security controls on native IPv6 traffic and
	on IPv4-tunneled traffic. Among such controls is the enforcement of		on IPv4-tunneled traffic. Among such controls is the enforcement of
	filtering policies, such that undesirable traffic is blocked. While		filtering policies, to block undesirable traffic. While IPv6
	IPv6 widespread/global IPv6 deployment has been slower than expected,		widespread/global IPv6 deployment has been slower than expected, it
	it is nevertheless happening, and thus filtering IPv6 traffic		is nevertheless happening; and thus, filtering IPv6 traffic (whether
	(whether native or transition/co-existence) to mitigate IPv6 security		native or transition/co-existence) to mitigate IPv6 security
	implications on IPv4 networks should only be considered as a		implications on IPv4 networks should (generally) only be considered
	temporary solution to protect a network until IPv6 is deployed. Only		as a temporary measure until IPv6 is deployed.
	in some exceptional cases (such as military operations networks)
	could this approach to mitigating the aforementioned security
	implications be thought of as a longer-term strategy.
	This document discusses the security implications of IPv6 and IPv6
	transition/co-existence technologies on (allegedly) IPv4-only
	networks, and provides guidance on how to mitigate the aforementioned
	issues.
	2. Security Implications of Native IPv6 Support		2. Security Implications of Native IPv6 Support
	Most popular operating systems include IPv6 support that is enabled		Most popular operating systems include IPv6 support that is enabled
	by default. This means that even if a network is expected to be		by default. This means that even if a network is expected to be
	IPv4-only, much of its infrastructure is nevertheless likely to be		IPv4-only, much of its infrastructure is nevertheless likely to be
	IPv6 enabled. For example, hosts are likely to have at least link-		IPv6 enabled. For example, hosts are likely to have at least link-
	local IPv6 connectivity which might be exploited by attackers with		local IPv6 connectivity which might be exploited by attackers with
	access to the local network.		access to the local network.
	skipping to change at page 5, line 25		skipping to change at page 5, line 25
	could be remotely-exploited by leveraging link-local IPv6		could be remotely-exploited by leveraging link-local IPv6
	connectivity that is enabled by default.		connectivity that is enabled by default.
	Additionally, unless appropriate measures are taken, an attacker with		Additionally, unless appropriate measures are taken, an attacker with
	access to an 'IPv4-only' local network could impersonate a local		access to an 'IPv4-only' local network could impersonate a local
	router and cause local hosts to enable their 'non-link-local' IPv6		router and cause local hosts to enable their 'non-link-local' IPv6
	connectivity (e.g. by sending Router Advertisement messages),		connectivity (e.g. by sending Router Advertisement messages),
	possibly circumventing security controls that were enforced only on		possibly circumventing security controls that were enforced only on
	IPv4 communications.		IPv4 communications.
	[THC-IPV6] is the first publicly-available toolkit that		[THC-IPV6] and [IPv6-Toolkit] include tools that implement this
	implemented this attack vector (along with many others).		attack vector (along with many others).
	[IPv6-Toolkit] is a fully-featured trouble-shooting and security
	assessment tool that implements this attack vector (along with
	many others).
	[Waters2011] provides an example of how this could be achieved		[Waters2013] provides an example of how this could be achieved
	using publicly available tools (besides incorrectly claiming the		using publicly available tools.
	discovery of a "0day vulnerability").
	Native IPv6 support could also possibly lead to VPN traffic leakages		Native IPv6 support could also possibly lead to VPN traffic leakages
	when hosts employ VPN software that not only does not support IPv6,		when hosts employ VPN software that not only does not support IPv6,
	but that does nothing about IPv6 traffic.		but that does nothing about IPv6 traffic.
	[I-D.ietf-opsec-vpn-leakages] describes this issue, along with		[I-D.ietf-opsec-vpn-leakages] describes this issue, along with
	possible mitigations.		possible mitigations.
	In general, networks should enforce on native IPv6 traffic the same		In general, networks should enforce on native IPv6 traffic the same
	security policies they currently enforce on IPv4 traffic. However,		security policies currently enforced on IPv4 traffic. However, in
	in those networks in which IPv6 has not yet been deployed, and		those networks in which IPv6 has not yet been deployed, and enforcing
	enforcing the aforementioned policies is deemed as unfeasible, a		the aforementioned policies is deemed as unfeasible, a network
	network administrator might mitigate IPv6-based attack vectors by		administrator might mitigate IPv6-based attack vectors by means of
	means of appropriate packet filtering.		appropriate packet filtering.
	2.1. Filtering Native IPv6 Traffic		2.1. Filtering Native IPv6 Traffic
	Some layer-2 devices might have the ability to selectively filter		Some layer-2 devices might have the ability to selectively filter
	packets based on the type of layer-2 payload. When such		packets based on the type of layer-2 payload. When such
	functionality is available, IPv6 traffic could be blocked at those		functionality is available, IPv6 traffic could be blocked at those
	layer-2 devices by blocking e.g. Ethernet frames with the Protocol		layer-2 devices by blocking, for example, Ethernet frames with the
	Type field set to 0x86dd [IANA-ETHER].		Protocol Type field set to 0x86dd [IANA-ETHER].
	SLAAC-based attacks [RFC3756] can be mitigated with technologies such		SLAAC-based attacks [RFC3756] can be mitigated with technologies such
	as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a		as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a
	similar way, DHCPv6-based attacks can be mitigated with technologies		similar way, DHCPv6-based attacks can be mitigated with technologies
	such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However,		such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However,
	neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that		neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
	employ IPv6 link-local addresses, since configuration of such		employ IPv6 link-local addresses, since configuration of such
	addresses does not rely on Router Advertisement messages or DCHPv6-		addresses does not rely on Router Advertisement messages or DCHPv6-
	server messages.		server messages.
	skipping to change at page 7, line 8		skipping to change at page 7, line 8
	NIDS, implementing IPv6 firewalling, etc.		NIDS, implementing IPv6 firewalling, etc.
	In some very specific scenarios (e.g., military operations		In some very specific scenarios (e.g., military operations
	networks) in which only IPv4 service might be desired, a network		networks) in which only IPv4 service might be desired, a network
	administrator might want to disable IPv6 support in all the		administrator might want to disable IPv6 support in all the
	communicating devices.		communicating devices.
	3. Security Implications of Tunneling Mechanisms		3. Security Implications of Tunneling Mechanisms
	Unless properly managed, tunneling mechanisms might result in		Unless properly managed, tunneling mechanisms might result in
	negative security implications ([RFC6169] describes the security		negative security implications. For example, they might increase
	implications of tunneling mechanisms in detail).		host exposure, might be leveraged to evade security controls, might
			contain protocol-based vulnerabilities, and/or the corresponding code
			might contain bugs with security implications.
	Of the plethora of tunneling mechanism that have so far been		[RFC6169] describes the security implications of tunneling
			mechanisms in detail.
			Of the plethora of tunneling mechanisms that have so far been
	standardized and widely implemented, the so-called "automatic		standardized and widely implemented, the so-called "automatic
	tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of		tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of
	particular interest from a security standpoint, since they might		particular interest from a security standpoint, since they might
	be employed without prior consent or action of the user or network		be employed without prior consent or action of the user or network
	administrator.		administrator.
	Therefore, tunneling mechanisms should be a concern not only to		Tunneling mechanisms should be a concern not only to network
	network administrators that have consciously deployed them, but also		administrators that have consciously deployed them, but also to those
	to network and security administrators whose security policies might		who have not deployed them, as these mechanisms might be leveraged to
	be bypassed by exploiting these mechanisms.		bypass their security policies.
	[CERT2009] contains some examples of how tunnels can be leveraged		[CERT2009] contains some examples of how tunnels can be leveraged
	to bypass firewall rules.		to bypass firewall rules.
	The aforementioned issues could be mitigated by applying the common		The aforementioned issues could be mitigated by applying the common
	security practice of only allowing traffic deemed as "necessary"		security practice of only allowing traffic deemed as "necessary"
	(i.e., the so-called "default deny" policy). Thus, when such policy		(i.e., the so-called "default deny" policy). Thus, when such policy
	is enforced IPv6 transition/co-existence traffic would be blocked by		is enforced, IPv6 transition/co-existence traffic would be blocked by
	default, and would only be allowed as a result of an explicit		default, and would only be allowed as a result of an explicit
	decision (rather than as a result of lack of awareness about such		decision.
	traffic).
	It should be noted that this type of policy is usually enforced at		It should be noted that this type of policy is usually enforced on
	a network that is the target of such traffic (such as an		a network that is the target of such traffic (such as an
	enterprise network). IPv6 transition traffic should generally		enterprise network). IPv6 transition traffic should generally
	never be filtered e.g. by an ISP when it is transit traffic.		never be filtered e.g. by an ISP when it is transit traffic.
	In those scenarios in which transition/co-existence traffic is meant		In those scenarios in which transition/co-existence traffic is meant
	to be blocked, it is highly recommended that, in addition to the		to be blocked, it is highly recommended that, in addition to the
	enforcement of filtering policies at the organizational perimeter,		enforcement of filtering policies at the organizational perimeter,
	the corresponding transition/co-existence mechanisms be disabled on		the corresponding transition/co-existence mechanisms be disabled on
	each node connected to the organizational network. This would not		each node connected to the organizational network. This would not
	only prevent security breaches resulting from accidental use of these		only prevent security breaches resulting from accidental use of these
	skipping to change at page 12, line 14		skipping to change at page 12, line 14
	teredo.ipv6.microsoft.com) resolve.		teredo.ipv6.microsoft.com) resolve.
	As these IPv4 addresses might change over time, an administrator		As these IPv4 addresses might change over time, an administrator
	should obtain these addresses when implementing the filtering		should obtain these addresses when implementing the filtering
	policy, and should also be prepared to keep this list up to date.		policy, and should also be prepared to keep this list up to date.
	The corresponding addresses can be easily obtained from a UNIX		The corresponding addresses can be easily obtained from a UNIX
	host by issuing the command 'dig teredo.ipv6.microsoft.com a'		host by issuing the command 'dig teredo.ipv6.microsoft.com a'
	(without quotes).		(without quotes).
			dig(1) is a free-software tool (part of the "dnsutils" package)
			produced by the Internet Software Consortium (ISC).
	It should be noted that even with all these filtering policies in		It should be noted that even with all these filtering policies in
	place, a node in the internal network might still be able to		place, a node in the internal network might still be able to
	communicate with some Teredo clients. That is, it could configure an		communicate with some Teredo clients. That is, it could configure an
	IPv6 address itself (without even contacting a Teredo server), and		IPv6 address itself (without even contacting a Teredo server), and
	might send Teredo traffic to those peers for which intervention of		might send Teredo traffic to those peers for which intervention of
	the host's Teredo server is not required (e.g., Teredo clients behind		the host's Teredo server is not required (e.g., Teredo clients behind
	a cone NAT).		a cone NAT).
	3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP)		3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP)
	skipping to change at page 13, line 5		skipping to change at page 12, line 47
	TSP can use either TCP or UDP as the transport protocol. In both		TSP can use either TCP or UDP as the transport protocol. In both
	cases TSP uses port number 3653, which has been assigned by the IANA		cases TSP uses port number 3653, which has been assigned by the IANA
	for this purpose. As a result, TSP (the Tunnel Broker control		for this purpose. As a result, TSP (the Tunnel Broker control
	channel) can be blocked by blocking TCP and UDP packets originating		channel) can be blocked by blocking TCP and UDP packets originating
	from the local network and destined to UDP port 3653 or TCP port		from the local network and destined to UDP port 3653 or TCP port
	3653. Additionally, the data channel can be blocked by blocking UDP		3653. Additionally, the data channel can be blocked by blocking UDP
	packets originated from the local network and destined to UDP port		packets originated from the local network and destined to UDP port
	3653, and IPv4 packets with a Protocol field set to 41.		3653, and IPv4 packets with a Protocol field set to 41.
			3.8. Filtering AYIYA
			AYIYA ("Anything In Anything") [I-D.massar-v6ops-ayiya] allows the
			tunnelling of packets across Network Address Port Translation (NAPT)
			[RFC2663] devices. While the specification of this tunneling
			mechanism was never published as an RFC, it is nevertheless widely
			deployed [SixXS-stats].
			AYIYA can be blocked by blocking TCP and UDP packets originating from
			the local network and destined to UDP port 5072 or TCP port 5072.
	4. Additional Considerations when Filtering IPv6 Traffic		4. Additional Considerations when Filtering IPv6 Traffic
	IPv6 deployments in the Internet are continually increasing, and some		IPv6 deployments in the Internet are continually increasing, and some
	hosts default to preferring IPv6 connectivity whenever it is		hosts default to preferring IPv6 connectivity whenever it is
	available. This is likely to cause IPv6-capable hosts to attempt to		available. This is likely to cause IPv6-capable hosts to attempt to
	reach an ever-increasing number of popular destinations via IPv6,		reach an ever-increasing number of popular destinations via IPv6,
	even if this IPv6 connectivity is provided relies on a transition		even if this IPv6 connectivity relies on a transition technology over
	technology over an IPv4-only network.		an IPv4-only network.
	A large source of IPv6 brokenness today comes from nodes that believe		A large source of IPv6 brokenness today comes from nodes that believe
	that they have functional IPv6 connectivity, but the path to their		that they have functional IPv6 connectivity, but the path to their
	destination fails somewhere upstream [Anderson2010] [Anderson2011]		destination fails somewhere upstream [Anderson2010] [Anderson2011]
	[Huston2010b] [Huston2012]. Upstream filtering of transition		[Huston2010b] [Huston2012]. Upstream filtering of transition
	technologies or situations where a misconfigured node attempts to		technologies or situations where a mis-configured node attempts to
	"provide" native IPv6 service on a given network without proper		"provide" native IPv6 service on a given network without proper
	upstream IPv6 connectivity may result in hosts attempting to reach		upstream IPv6 connectivity may result in hosts attempting to reach
	remote nodes via IPv6, and depending on the absence or presence and		remote nodes via IPv6, and depending on the absence or presence and
	specific implementation details of "Happy Eyeballs" [RFC6555], there		specific implementation details of "Happy Eyeballs" [RFC6555], there
	might be a non-trivial timeout period before the host falls back to		might be a non-trivial timeout period before the host falls back to
	IPv4 [Huston2010a] [Huston2012].		IPv4 [Huston2010a] [Huston2012].
	For this reason, networks attempting to prevent IPv6 traffic from		For this reason, networks attempting to prevent IPv6 traffic from
	traversing their devices should consider configuring their local		traversing their devices should consider configuring their local
	recursive DNS servers to ignore queries for AAAA DNS records, or even		recursive DNS servers to respond to queries for AAAA DNS records with
	consider filtering AAAA records at the network ingress point to		a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such
	prevent end hosts from attempting their own DNS resolution. This		queries, and should even consider filtering AAAA records at the
	will ensure that end hosts which are on an IPv4-only network will		network ingress point to prevent the internal hosts from attempting
	only receive DNS A records, and they will be unlikely to attempt to		their own DNS resolution. This will ensure that hosts which are on
	use (likely broken) IPv6 connectivity to reach their desired		an IPv4-only network will only receive DNS A records, and they will
	destinations. Additionally, it is generally deemed as good practice		be unlikely to attempt to use (likely broken) IPv6 connectivity to
	to signal the packet drop to the source node, such that the source		reach their desired destinations.
	node is able to react to such packet drop in a more appropriate and
			Additionally, it should be noted that when filtering IPv6 traffic, it
			is good practice to signal the packet drop to the source node, such
			that it is able to react to the packet drop in a more appropriate and
	timely way.		timely way.
	A firewall could signal the packet drop by means of an ICMPv6		For example, a firewall could signal the packet drop by means of
	error message (or TCP [RFC0793] RST segment if appropriate), such		an ICMPv6 error message (or TCP [RFC0793] RST segment if
	that the source node can e.g. quickly react as described in		appropriate), such that the source node can e.g. quickly react as
	[RFC5461].		described in [RFC5461].
	For obvious reasons, if the traffic being filtered is IPv6		For obvious reasons, if the traffic being filtered is IPv6
	transition/co-existence traffic, the signalling packet should be		transition/co-existence traffic, the signalling packet should be
	sent by means of the corresponding IPv6 transition/co-existence		sent by means of the corresponding IPv6 transition/co-existence
	technology.		technology.
	5. IANA Considerations		5. 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
	skipping to change at page 16, line 11		skipping to change at page 17, line 11
	traffic the same security policies currently enforced for IPv4		traffic the same security policies currently enforced for IPv4
	traffic, and/or blocking the aforementioned traffic when it is deemed		traffic, and/or blocking the aforementioned traffic when it is deemed
	as undesirable.		as undesirable.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Wes George, who contributed most of		The authors would like to thank Wes George, who contributed most of
	the text that comprises Section 4 of this document.		the text that comprises Section 4 of this document.
	The authors would like to thank (in alphabetical order) Ran Atkinson,		The authors would like to thank (in alphabetical order) Ran Atkinson,
	Brian Carpenter, Panos Kampanakis, David Malone, Arturo Servin,		Brian Carpenter, Joel Jaeggli, Panos Kampanakis, Warren Kumari, David
	Donald Smith, Tina Tsou, and Eric Vyncke, for providing valuable		Malone, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke, for
	comments on earlier versions of this document.		providing valuable comments on earlier versions of this document.
	This document is based on the results of the the project "Security		This document is based on the results of the the project "Security
	Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6],		Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6],
	carried out by Fernando Gont on behalf of the UK Centre for the		carried out by Fernando Gont on behalf of the UK Centre for the
	Protection of National Infrastructure (CPNI). Fernando Gont would		Protection of National Infrastructure (CPNI). Fernando Gont would
	like to thank the UK CPNI for their continued support.		like to thank the UK CPNI for their continued support.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
			[RFC1035] Mockapetris, P., "Domain names - implementation and
			specification", STD 13, RFC 1035, November 1987.
	[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.
	[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4		[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
	Domains without Explicit Tunnels", RFC 2529, March 1999.		Domains without Explicit Tunnels", RFC 2529, March 1999.
	[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6		[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
	Tunnel Broker", RFC 3053, January 2001.		Tunnel Broker", RFC 3053, January 2001.
	[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains		[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
	skipping to change at page 18, line 47		skipping to change at page 19, line 50
	in dual-stack hosts/ networks",		in dual-stack hosts/ networks",
	draft-ietf-opsec-vpn-leakages-00 (work in progress),		draft-ietf-opsec-vpn-leakages-00 (work in progress),
	December 2012.		December 2012.
	[I-D.ietf-opsec-dhcpv6-shield]		[I-D.ietf-opsec-dhcpv6-shield]
	Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield:		Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield:
	Protecting Against Rogue DHCPv6 Servers",		Protecting Against Rogue DHCPv6 Servers",
	draft-ietf-opsec-dhcpv6-shield-00 (work in progress),		draft-ietf-opsec-dhcpv6-shield-00 (work in progress),
	December 2012.		December 2012.
			[I-D.massar-v6ops-ayiya]
			Massar, J., "AYIYA: Anything In Anything",
			draft-massar-v6ops-ayiya-02 (work in progress), July 2004.
	[IANA-ETHER]		[IANA-ETHER]
	IANA, "Ether Types", 2012,		IANA, "Ether Types", 2012,
	<http://www.iana.org/assignments/ethernet-numbers>.		<http://www.iana.org/assignments/ethernet-numbers>.
	[CERT2009]		[CERT2009]
	CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http		CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http
	://www.cert.org/blogs/vuls/2009/04/		://www.cert.org/blogs/vuls/2009/04/
	bypassing_firewalls_with_ipv6.html>.		bypassing_firewalls_with_ipv6.html>.
	[CORE2007]		[CORE2007]
	skipping to change at page 19, line 41		skipping to change at page 20, line 47
	[Anderson2011]		[Anderson2011]
	Anderson, T., "IPv6 dual-stack client loss in Norway",		Anderson, T., "IPv6 dual-stack client loss in Norway",
	2011, <http://www.fud.no/ipv6/>.		2011, <http://www.fud.no/ipv6/>.
	[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).
	[IPv6-Toolkit]		[IPv6-Toolkit]
	"IPv6 Toolkit",		"SI6 Networks' IPv6 Toolkit",
	<http://www.si6networks.com/tools/ipv6toolkit>.		<http://www.si6networks.com/tools/ipv6toolkit>.
	[THC-IPV6]		[THC-IPV6]
	"The Hacker's Choice IPv6 Attack Toolkit",		"The Hacker's Choice IPv6 Attack Toolkit",
	<http://www.thc.org/thc-ipv6/>.		<http://www.thc.org/thc-ipv6/>.
	[Waters2011]		[Waters2013]
	Waters, A., "SLAAC Attack - 0day Windows Network		Waters, A., "The SLAAC Attack - using IPv6 as a weapon
	Interception Configuration Vulnerability", 2011,		against IPv4", 2013, <http://wirewatcher.wordpress.com/
	<http://resources.infosecinstitute.com/slaac-attack/>.		2011/04/04/
			the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/>.
			[SixXS-stats]
			SixXS, "SixXS - IPv6 Deployment & Tunnel Broker ::
			Statistics", 2013, <http://www.sixxs.net/misc/usage/>.
	Appendix A. Summary of filtering rules		Appendix A. Summary of filtering rules
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| Technology | Filtering rules |		| Technology | Filtering rules |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| Native | EtherType 0x86DD |		| Native | EtherType 0x86DD |
	| IPv6 | |		| IPv6 | |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| 6in4 | IP proto 41 |		| 6in4 | IP proto 41 |
	skipping to change at page 20, line 28		skipping to change at page 22, line 28
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| 6to4 | IP proto 41 |		| 6to4 | IP proto 41 |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| ISATAP | IP proto 41 |		| ISATAP | IP proto 41 |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| Teredo | UDP Dest Port 3544 |		| Teredo | UDP Dest Port 3544 |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest |		| TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest |
	| TSP | Port 3653) |		| TSP | Port 3653) |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
			| AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 |
			+------------+------------------------------------------------------+
	Table 1: Summary of filtering rules		Table 1: Summary of filtering rules
	NOTE: the table above describes general and simple filtering rules		NOTE: the table above describes general and simple filtering rules
	for blocking the corresponding traffic. More finer-grained rules		for blocking the corresponding traffic. More finer-grained rules
	might be available in each of the corresponding sections of this		might be available in each of the corresponding sections of this
	document.		document.
	Authors' Addresses		Authors' Addresses
	Fernando Gont		Fernando Gont
	SI6 Networks / UTN-FRH		SI6 Networks / UTN-FRH
	Evaristo Carriego 2644		Evaristo Carriego 2644
	Haedo, Provincia de Buenos Aires 1706		Haedo, Provincia de Buenos Aires 1706
	Argentina		Argentina
	Phone: +54 11 4650 8472		Phone: +54 11 4650 8472
	Email: fgont@si6networks.com		Email: fgont@si6networks.com
	URI: http://www.si6networks.com		URI: http://www.si6networks.com
	Will Liu		Will (Shucheng) Liu
	Huawei Technologies		Huawei Technologies
	Bantian, Longgang District		Bantian, Longgang District
	Shenzhen 518129		Shenzhen 518129
	P.R. China		P.R. China
	Email: liushucheng@huawei.com		Email: liushucheng@huawei.com
End of changes. 32 change blocks.
	84 lines changed or deleted		111 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/