draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.txt		draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06.txt
	Operational Security Capabilities for F. Gont		opsec wg F. Gont
	IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH		Internet-Draft SI6 Networks/UTN-FRH
	Internet-Draft W. Liu		Intended status: Informational W. Liu
	Intended status: Informational Huawei Technologies		Expires: May 30, 2014 Huawei Technologies
	Expires: January 6, 2014 July 5, 2013		November 26, 2013
	Security Implications of IPv6 on IPv4 Networks		Security Implications of IPv6 on IPv4 Networks
	draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05		draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06
	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
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 6, 2014.		This Internet-Draft will expire on May 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Security Implications of Native IPv6 Support . . . . . . . . . 5		2. Security Implications of Native IPv6 Support . . . . . . . . 3
	2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5		2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4
	3. Security Implications of Tunneling Mechanisms . . . . . . . . 7		3. Security Implications of Tunneling Mechanisms . . . . . . . . 5
	3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8		3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7
	3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9		3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9		3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 7
	3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10		3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9
	3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 11		3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9
	3.7. Filtering Tunnel Broker with Tunnel Setup Protocol		3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11
	(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11
	3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 13		4. Additional Considerations when Filtering IPv6 Traffic . . . . 11
	4. Additional Considerations when Filtering IPv6 Traffic . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		Appendix A. Summary of filtering rules . . . . . . . . . . . . . 17
	Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Most general-purpose operating systems implement and enable native		Most general-purpose operating systems implement and enable native
	IPv6 [RFC2460] support and a number of transition/co-existence		IPv6 [RFC2460] support and a number of transition/co-existence
	technologies by default. Support of IPv6 by all nodes is intended to		technologies by default. Support of IPv6 by all nodes is intended to
	become best current practice [RFC6540]. Some enterprise networks		become best current practice [RFC6540]. Some enterprise networks
	might, however, choose to delay active use of IPv6.		might, however, choose to delay active use of IPv6.
	This document describes operational practices for enterprise networks		This document describes operational practices for enterprise networks
	to prevent security exposure resulting from unplanned use of IPv6 on		to prevent security exposure resulting from unplanned use of IPv6 on
	such networks. This document is only applicable to enterprise		such networks. This document is only applicable to enterprise
	networks: networks where the network operator is not providing a		networks: networks where the network operator is not providing a
	general-purpose internet, but rather a business-specific network.		general-purpose internet, but rather a business-specific network.
	The solutions proposed here are not practical for home networks, nor		The solutions proposed here are not practical for home networks, nor
	are they appropriate for provider networks such as ISPs, mobile		are they appropriate for provider networks such as ISPs, mobile
	providers, Wifi hotspot providers or any other public internet		providers, Wifi hotspot providers or any other public internet
	service.		service.
	In scenarios in which IPv6-enabled devices are deployed on enterprise		In scenarios in which IPv6-enabled devices are deployed on enterprise
	networks that are intended to be IPv4-only, native IPv6 support		networks that are intended to be IPv4-only, native IPv6 support and/
	and/or IPv6 transition/co-existence technologies could be leveraged		or IPv6 transition/co-existence technologies could be leveraged by
	by local or remote attackers for a number of (illegitimate) purposes.		local or remote attackers for a number of (illegitimate) purposes.
	For example,		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 A NIDS or firewall might support both IPv4 and IPv6, but might be		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/		not be configured to enforce on IPv6 traffic the same controls/
	skipping to change at page 3, line 46		skipping to change at page 3, line 21
	o A NIDS or firewall might support both IPv4 and IPv6, but might be		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/		not be configured to enforce on IPv6 traffic the same controls/
	policies it enforces on IPv4 traffic.		policies it enforces on IPv4 traffic.
	o Some transition/co-existence mechanisms could cause an internal		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
	Internet to hosts behind the organizational firewall or NAPT		the Internet to hosts behind the organizational firewall or
	(which in many deployments provides a minimum level of		NAPT (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 could, 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 IPv6 traffic. Among such controls is the		on IPv4-tunneled IPv6 traffic. Among such controls is the
	enforcement of filtering policies, to block undesirable traffic.		enforcement of filtering policies, to block undesirable traffic.
	skipping to change at page 5, line 47		skipping to change at page 4, line 42
	administrator might mitigate IPv6-based attack vectors by means of		administrator might mitigate IPv6-based attack vectors by 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, for example, Ethernet frames with the		layer-2 devices by blocking, for example, Ethernet frames with the
	Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however,		Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however,
	that enforcement of such filtering policy would break applications		that blocking IPv6 at layer-2 might create problems that are
	that expect IPv6 link-local connectivity to work properly (e.g.		difficult to diagnose inclusive of intentional or incidental use of
	Bonjour).		link-local addressing (as in Multicast DNS/DNS-based Service
			Discovery [RFC6762] [RFC6763]); sites that enforce such filtering
			policy should keep that possibility in mind when debugging the
			network.
	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
	server messages.		DCHPv6-server messages.
	Administrators considering the filtering of native IPv6 traffic at		Administrators considering the filtering of native IPv6 traffic at
	layer-3 devices are urged to pay attention to the general		layer-3 devices are urged to pay attention to the general
	considerations for IPv6 traffic filtering discussed in Section 4.		considerations for IPv6 traffic filtering discussed in Section 4.
	If native IPv6 traffic is filtered at layer-2, local IPv6 nodes		If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
	would only get to configure IPv6 link-local addresses.		would only get to configure IPv6 link-local addresses.
	In order to mitigate attacks based on native IPv6 traffic, IPv6		In order to mitigate attacks based on native IPv6 traffic, IPv6
	security controls should be enforced on both IPv4 and IPv6 networks.		security controls should be enforced on both IPv4 and IPv6 networks.
	skipping to change at page 8, line 8		skipping to change at page 6, line 30
	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
	mechanisms, but would also disable this functionality altogether,		mechanisms, but would also disable this functionality altogether,
	possibly mitigating vulnerabilities that might be present in the host		possibly mitigating vulnerabilities that might be present in the host
	implementation of these transition/co-existence mechanisms.		implementation of these transition/co-existence mechanisms.
	IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured		IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured
	tunnels) can generally be blocked by dropping IPv4 packets that		tunnels) can generally be blocked by dropping IPv4 packets that
	contain a Protocol field set to 41. Security devices such as NIDS		contain a Protocol field set to 41. Security devices such as NIDS
	might also include signatures that detect such transition/		might also include signatures that detect such transition/co-
	co-existence traffic.		existence traffic.
	Administrators considering the filtering of transition/co-existence		Administrators considering the filtering of transition/co-existence
	traffic are urged to pay attention to the general considerations for		traffic are urged to pay attention to the general considerations for
	IPv6 traffic filtering discussed in Section 4.		IPv6 traffic filtering discussed in Section 4.
	We note that this document only covers standardized IPv6 tunneling		We note that this document only covers standardized IPv6 tunneling
	mechanisms, but does not aim to cover non-standard tunneling		mechanisms, but does not aim to cover non-standard tunneling
	mechanisms or IPsec-based [RFC4301] or SSL/TLS-based [RFC5246]		mechanisms or IPsec-based [RFC4301] or SSL/TLS-based [RFC5246]
	[RFC6101] tunneling of IPv6 packets.		[RFC6101] tunneling of IPv6 packets.
	skipping to change at page 9, line 49		skipping to change at page 8, line 25
	traffic is allowed, then more finer-grained filtering rules could be		traffic is allowed, then more finer-grained filtering rules could be
	applied. For example, 6to4 traffic could be filtered by applying		applied. For example, 6to4 traffic could be filtered by applying
	filtering rules such as:		filtering rules such as:
	o Filter outgoing IPv4 packets that have the Destination Address set		o Filter outgoing IPv4 packets that have the Destination Address set
	to an address that belongs to the prefix 192.88.99.0/24.		to an address that belongs to the prefix 192.88.99.0/24.
	o Filter incoming IPv4 packets that have the Source Address set to		o Filter incoming IPv4 packets that have the Source Address set to
	an address that belongs to the prefix 192.88.99.0/24.		an address that belongs to the prefix 192.88.99.0/24.
	These rules assume that the corresponding nodes employ the		These rules assume that the corresponding nodes employ the
	"Anycast Prefix for 6to4 Relay Routers" [RFC3068].		"Anycast Prefix for 6to4 Relay Routers" [RFC3068].
	It has been suggested that 6to4 relays send their packets with		It has been suggested that 6to4 relays send their packets
	their IPv4 Source Address set to 192.88.99.1.		with their IPv4 Source Address set to 192.88.99.1.
	o Filter outgoing IPv4 packets that have the Destination Address set		o Filter outgoing IPv4 packets that have the Destination Address set
	to the IPv4 address of well-known 6to4 relays.		to the IPv4 address of well-known 6to4 relays.
	o Filter incoming IPv4 packets that have the Source Address set to		o Filter incoming IPv4 packets that have the Source Address set to
	the IPv4 address of well-known 6to4 relays.		the IPv4 address of well-known 6to4 relays.
	These last two filtering policies will generally be unnecessary,		These last two filtering policies will generally be unnecessary,
	and possibly unfeasible to enforce (given the number of potential		and possibly unfeasible to enforce (given the number of potential
	6to4 relays, and the fact that many relays might remain unknown to		6to4 relays, and the fact that many relays might remain unknown to
	skipping to change at page 12, line 5		skipping to change at page 10, line 30
	filtering rules, since the information required to enforce them		filtering rules, since the information required to enforce them
	might be missing in the received fragments (which should be		might be missing in the received fragments (which should be
	expected if Teredo is being employed for malicious purposes).		expected if Teredo is being employed for malicious purposes).
	The most popular operating system that includes an implementation of		The most popular operating system that includes an implementation of
	Teredo in the default installation is Microsoft Windows. Microsoft		Teredo in the default installation is Microsoft Windows. Microsoft
	Windows obtains the Teredo server addresses (primary and secondary)		Windows obtains the Teredo server addresses (primary and secondary)
	by resolving the domain name teredo.ipv6.microsoft.com into DNS A		by resolving the domain name teredo.ipv6.microsoft.com into DNS A
	records. A network administrator might want to prevent Microsoft		records. A network administrator might want to prevent Microsoft
	Windows hosts from obtaining Teredo service by filtering at the		Windows hosts from obtaining Teredo service by filtering at the
	organizational firewall outgoing UDP datagrams (i.e. IPv4 packets		organizational firewall outgoing UDP datagrams (i.e. IPv4 packets
	with the Protocol field set to 17) that contain in the IPv4		with the Protocol field set to 17) that contain in the IPv4
	Destination Address any of the IPv4 addresses that the domain name		Destination Address any of the IPv4 addresses that the domain name
	teredo.ipv6.microsoft.com maps to. Additionally, the firewall would		teredo.ipv6.microsoft.com maps to. Additionally, the firewall would
	filter incoming UDP datagrams from any of the IPv4 addresses to which		filter incoming UDP datagrams from any of the IPv4 addresses to which
	the domain names of well-known Teredo servers (such as		the domain names of well-known Teredo servers (such as
	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.
	skipping to change at page 18, line 28		skipping to change at page 13, line 48
	[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
	via IPv4 Clouds", RFC 3056, February 2001.		via IPv4 Clouds", RFC 3056, February 2001.
	[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",		[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
	RFC 3068, June 2001.		RFC 3068, June 2001.
	[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through		[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
	Network Address Translations (NATs)", RFC 4380,		Network Address Translations (NATs)", RFC 4380, February
	February 2006.		2006.
	[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,		Multicast Name Resolution (LLMNR)", RFC 4795, January
	January 2007.		2007.
	[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site		[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
	Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,		Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
	March 2008.		March 2008.
	[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4		[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
	Infrastructures (6rd)", RFC 5569, January 2010.		Infrastructures (6rd)", RFC 5569, January 2010.
	[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4		[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
	Infrastructures (6rd) -- Protocol Specification",		Infrastructures (6rd) -- Protocol Specification", RFC
	RFC 5969, August 2010.		5969, August 2010.
	[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the		[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
	Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.		Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
	8.2. Informative References		8.2. Informative References
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
	RFC 793, September 1981.		793, September 1981.
	[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address		[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
	Translator (NAT) Terminology and Considerations",		Translator (NAT) Terminology and Considerations", RFC
	RFC 2663, August 1999.		2663, August 1999.
	[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor		[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
	Discovery (ND) Trust Models and Threats", RFC 3756,		Discovery (ND) Trust Models and Threats", RFC 3756, May
	May 2004.		2004.
	[RFC3964] Savola, P. and C. Patel, "Security Considerations for		[RFC3964] Savola, P. and C. Patel, "Security Considerations for
	6to4", RFC 3964, December 2004.		6to4", RFC 3964, December 2004.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	skipping to change at page 19, line 46		skipping to change at page 15, line 22
	[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",		[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
	RFC 6343, August 2011.		RFC 6343, August 2011.
	[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,		[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
	"IPv6 Support Required for All IP-Capable Nodes", BCP 177,		"IPv6 Support Required for All IP-Capable Nodes", BCP 177,
	RFC 6540, April 2012.		RFC 6540, April 2012.
	[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with		[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
	Dual-Stack Hosts", RFC 6555, April 2012.		Dual-Stack Hosts", RFC 6555, April 2012.
			[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
			February 2013.
			[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
			Discovery", RFC 6763, February 2013.
	[I-D.ietf-v6ops-ra-guard-implementation]		[I-D.ietf-v6ops-ra-guard-implementation]
	Gont, F., "Implementation Advice for IPv6 Router		Gont, F., "Implementation Advice for IPv6 Router
	Advertisement Guard (RA-Guard)",		Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-
	draft-ietf-v6ops-ra-guard-implementation-07 (work in		guard-implementation-07 (work in progress), November 2012.
	progress), November 2012.
	[I-D.ietf-opsec-vpn-leakages]		[I-D.ietf-opsec-vpn-leakages]
	Gont, F., "Virtual Private Network (VPN) traffic leakages		Gont, F., "Virtual Private Network (VPN) traffic leakages
	in dual-stack hosts/ networks",		in dual-stack hosts/ networks", draft-ietf-opsec-vpn-
	draft-ietf-opsec-vpn-leakages-01 (work in progress),		leakages-02 (work in progress), August 2013.
	June 2013.
	[I-D.ietf-opsec-dhcpv6-shield]		[I-D.ietf-opsec-dhcpv6-shield]
	Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield:		Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:
	Protecting Against Rogue DHCPv6 Servers",		Protecting Against Rogue DHCPv6 Servers", draft-ietf-
	draft-ietf-opsec-dhcpv6-shield-00 (work in progress),		opsec-dhcpv6-shield-01 (work in progress), October 2013.
	December 2012.
	[I-D.massar-v6ops-ayiya]		[I-D.massar-v6ops-ayiya]
	Massar, J., "AYIYA: Anything In Anything",		Massar, J., "AYIYA: Anything In Anything", draft-massar-
	draft-massar-v6ops-ayiya-02 (work in progress), July 2004.		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,
	://www.cert.org/blogs/vuls/2009/04/		<http://www.cert.org/blogs/vuls/2009/04/
	bypassing_firewalls_with_ipv6.html>.		bypassing_firewalls_with_ipv6.html>.
	[CORE2007]		[CORE2007]
	CORE, "OpenBSD's IPv6 mbufs remote kernel buffer		CORE, , "OpenBSD's IPv6 mbufs remote kernel buffer
	overflow", 2007,		overflow", 2007,
	<http://www.coresecurity.com/content/open-bsd-advisorie>.		<http://www.coresecurity.com/content/open-bsd-advisorie>.
	[Huston2010a]		[Huston2010a]
	Huston, G., "IPv6 Measurements", 2010,		Huston, G., "IPv6 Measurements", 2010,
	<http://www.potaroo.net/stats/1x1/>.		<http://www.potaroo.net/stats/1x1/>.
	[Huston2010b]		[Huston2010b]
	Huston, G., "Flailing IPv6", 2010,		Huston, G., "Flailing IPv6", 2010,
	<http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>.		<http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>.
	[Huston2012]		[Huston2012]
	Huston, G., "Bemused Eyeballs: Tailoring Dual Stack		Huston, G., "Bemused Eyeballs: Tailoring Dual Stack
	Applications for a CGN Environment", 2012,		Applications for a CGN Environment", 2012,
	<http://www.potaroo.net/ispcol/2012-05/notquite.pdf>.		<http://www.potaroo.net/ispcol/2012-05/notquite.pdf>.
	[Anderson2010]		[Anderson2010]
	Anderson, T., "Measuring and combating IPv6 brokenness",		Anderson, T., "Measuring and combating IPv6 brokenness",
	RIPE 61, Roma, November 2010,		RIPE 61, Roma, November 2010, November 2010,
	<http://ripe61.ripe.net/presentations/162-ripe61.pdf>.		<http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
	[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]
	"SI6 Networks' 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/>.
	[Waters2013]		[Waters2013]
	Waters, A., "The SLAAC Attack - using IPv6 as a weapon		Waters, A., "The SLAAC Attack - using IPv6 as a weapon
	against IPv4", 2013, <http://wirewatcher.wordpress.com/		against IPv4", 2013, <http://wirewatcher.wordpress.com/
	2011/04/04/		2011/04/04/the-slaac-attack-using-ipv6-as-a-weapon-
	the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/>.		against-ipv4/>.
	[SixXS-stats]		[SixXS-stats]
	SixXS, "SixXS - IPv6 Deployment & Tunnel Broker ::		SixXS, , "SixXS - IPv6 Deployment & Tunnel Broker ::
	Statistics", 2013, <http://www.sixxs.net/misc/usage/>.		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 IPv6 | EtherType 0x86DD |
	| IPv6 | |		+-------------------+-----------------------------------------------+
	+------------+------------------------------------------------------+		| 6in4 | IP proto 41 |
	| 6in4 | IP proto 41 |		+-------------------+-----------------------------------------------+
	+------------+------------------------------------------------------+		| 6over4 | IP proto 41 |
	| 6over4 | IP proto 41 |		+-------------------+-----------------------------------------------+
	+------------+------------------------------------------------------+		| 6rd | IP proto 41 |
	| 6rd | IP proto 41 |		+-------------------+-----------------------------------------------+
	+------------+------------------------------------------------------+		| 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 TSP | (IP proto 41) || (UDP Dest Port 3653 || TCP |
	| TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest |		| | Dest Port 3653) |
	| TSP | Port 3653) |		+-------------------+-----------------------------------------------+
	+------------+------------------------------------------------------+		| AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 |
	| 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
End of changes. 36 change blocks.
	112 lines changed or deleted		114 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/