draft-ietf-v6ops-6to4-security-03.txt		draft-ietf-v6ops-6to4-security-04.txt
	v6ops Working Group P. Savola		v6ops Working Group P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Expires: December 16, 2004 C. Patel		Expires: January 16, 2005 C. Patel
	All Play, No Work		All Play, No Work
	June 17, 2004		July 18, 2004
	Security Considerations for 6to4		Security Considerations for 6to4
	draft-ietf-v6ops-6to4-security-03.txt		draft-ietf-v6ops-6to4-security-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at http://
	http://www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 16, 2004.		This Internet-Draft will expire on January 16, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	The IPv6 interim mechanism 6to4 (RFC3056) uses automatic		The IPv6 interim mechanism 6to4 (RFC3056) uses automatic
	IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The		IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The
	architecture includes 6to4 routers and 6to4 relay routers, which		architecture includes 6to4 routers and 6to4 relay routers, which
	skipping to change at page 2, line 11		skipping to change at page 2, line 13
	of security threats, mainly Denial of Service. It also makes it		of security threats, mainly Denial of Service. It also makes it
	easier for nodes to spoof IPv6 addresses. This document discusses		easier for nodes to spoof IPv6 addresses. This document discusses
	these issues in more detail and suggests enhancements to alleviate		these issues in more detail and suggests enhancements to alleviate
	the problems.		the problems.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5		2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 5
	2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5		2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . 5
	2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 5		2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . 6
	2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6		2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . 6
	2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 6		2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . 7		2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . 7
	2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . 7		2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . 7
	2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . 7		2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . 8
	3. Functionalities of 6to4 Network Components . . . . . . . . . . 9		3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
	3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9		3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 10		3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . 11
	4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11		4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 12		4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . 13
	4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13		4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . 13
	4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 14		4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . 15
	4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17		4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . 17
	4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 18		4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 19
	4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 20		4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . 21
	4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 20		4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . 21
	4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21		4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . 21
	4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 22		4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . 23
	4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24		4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . 24
	4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 24		4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . 25
	4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26		4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . 26
	4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 27		4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . 28
	4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 27		4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . 28
	5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 29		5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
	5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 30		5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . 31
	5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 30		5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . 31
	5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 31		5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . 32
	5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 31		5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32
	5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32		5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 33
	5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 32		5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . 33
	5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 32		5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . 33
	6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 33		6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
	6.1 Implementation Considerations with Automatic Tunnels . . . 33		6.1 Implementation Considerations with Automatic Tunnels . . . 34
	6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 34		6.2 A Different Model for 6to4 Deployment . . . . . . . . . . 35
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 35		7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36		10.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
	10.2 Informative References . . . . . . . . . . . . . . . . . . . 36		10.2 Informative References . . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
	A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 38		A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
	B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39		B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	Intellectual Property and Copyright Statements . . . . . . . . 40		Intellectual Property and Copyright Statements . . . . . . . . 41
	1. Introduction		1. Introduction
	The IPv6 interim mechanism "6to4" [1] specifies automatic		The IPv6 interim mechanism "6to4" [1] specifies automatic
	IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by		IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by
	embedding the tunnel IPv4 address in the IPv6 6to4 prefix.		embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
	Two characteristics of the 6to4 mechanism introduce most of the		Two characteristics of the 6to4 mechanism introduce most of the
	security considerations:		security considerations:
	1. All 6to4 routers must accept and decapsulate IPv4 packets from		1. All 6to4 routers must accept and decapsulate IPv4 packets from
	every other 6to4 router, and 6to4 relays.		every other 6to4 router, and 6to4 relays.
	2. 6to4 relay routers must accept traffic from any native IPv6 node.		2. 6to4 relay routers must accept traffic from any native IPv6 node.
	Since the 6to4 router must accept from traffic from any other 6to4		Since the 6to4 router must accept traffic from any other 6to4 router
	router or relay, a certain requirement for trust is implied, and		or relay, a certain requirement for trust is implied, and there are
	there are no strict constraints on what the IPv6 packet may contain.		no strict constraints on what the IPv6 packet may contain. Thus,
	Thus, addresses within the IPv4, and IPv6 header may be spoofed, and		addresses within the IPv4, and IPv6 header may be spoofed, and this
	this property leads to various types of threats including different		property leads to various types of threats including different
	flavors of Denial of Service -attacks.		flavors of Denial of Service -attacks.
	The 6to4 specification outlined a few security considerations and		The 6to4 specification outlined a few security considerations and
	rules, but was very ambiguous on their exact requirement level.		rules, but was very ambiguous on their exact requirement level.
	Further, the description of the considerations was rather short, and		Further, the description of the considerations was rather short, and
	in fact, some of them have been proven to be difficult to understand		in fact, some of them have been proven to be difficult to understand
	or impossible to implement.		or impossible to implement.
	This draft analyzes the 6to4 security issues in more detail and		This draft analyzes the 6to4 security issues in more detail and
	outlines some enhancements and caveats.		outlines some enhancements and caveats.
	skipping to change at page 4, line 46		skipping to change at page 4, line 46
	rehashing how 6to4 is used today based on the 6to4 specification, so		rehashing how 6to4 is used today based on the 6to4 specification, so
	that it is easier to understand how security could be affected.		that it is easier to understand how security could be affected.
	Section 4 provides a threat analysis for implementations that already		Section 4 provides a threat analysis for implementations that already
	implement most of the security checks. Section 5 describes the		implement most of the security checks. Section 5 describes the
	optimal decapsulation/encapsulation rules for 6to4 implementations,		optimal decapsulation/encapsulation rules for 6to4 implementations,
	and Section 6 provides further discussion on a few issues which have		and Section 6 provides further discussion on a few issues which have
	proven to be difficult to implement. Appendix A outlines a few		proven to be difficult to implement. Appendix A outlines a few
	possible trivial attack scenarios in the case that very little or no		possible trivial attack scenarios in the case that very little or no
	security has been implemented.		security has been implemented.
	For the sake of simplicity, in this document, native IPv6 Internet is		For the sake of simplicity, in this document, the native Internet is
	assumed to encompass IPv6 networks formed using other transition		assumed to encompass IPv6 networks formed using other transition
	mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk		mechanisms (e.g. RFC 2893 [4]), as these mechanisms cannot talk
	directly 6to4 network.		directly to the 6to4 network.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [2].		document are to be interpreted as described in RFC 2119 [2].
			Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24, 8.0.0.0/
			24 and 9.0.0.0/24 are used for demonstrative purposes, to represent
			global IPv4 addresses which have no relation to each other. This
			approach was chosen instead of just using addresses from 192.0.2.0/24
			[5] for two reasons: to use addresses whose 6to4 mapping is
			blindingly obvious, and to make it obvious that the IPv4 addresses of
			different 6to4 gateways do not have to have any relation to each
			other.
	2. Different 6to4 Forwarding Scenarios		2. Different 6to4 Forwarding Scenarios
	It should be noted that when communicating between 6to4 and native		It should be noted that when communicating between 6to4 and native
	domains, the 6to4 relays that will be used in the two directions are		domains, the 6to4 relays that will be used in the two directions are
	very likely different; routing is highly asymmetric. Because of		very likely different; routing is highly asymmetric. Because of
	this, it is not feasible to limit relays from which 6to4 routers may		this, it is not feasible to limit relays from which 6to4 routers may
	accept traffic.		accept traffic.
	The first three subsections introduce the most common forms of 6to4		The first three subsections introduce the most common forms of 6to4
	operation. Other models are presented in the fourth subsection.		operation. Other models are presented in the fourth subsection.
	skipping to change at page 7, line 10		skipping to change at page 7, line 30
	2.4 Other Models		2.4 Other Models
	These are more or less special cases of 6to4 operations. In later		These are more or less special cases of 6to4 operations. In later
	chapters, unless otherwise stated, only the most generally-used		chapters, unless otherwise stated, only the most generally-used
	models (above) will be considered.		models (above) will be considered.
	2.4.1 BGP Between 6to4 Routers and Relays		2.4.1 BGP Between 6to4 Routers and Relays
	Section 5.2.2.2 in [1] presents a model where, instead of static		Section 5.2.2.2 in [1] presents a model where, instead of static
	configuration, BGP [5] is used between 6to4 relay routers and 6to4		configuration, BGP [6] is used between 6to4 relay routers and 6to4
	routers.		routers (for outgoing relay selection only).
	If the 6to4 router established a BGP session between all the possible		Going further than [1], if the 6to4 router established a BGP session
	6to4 relays, and advertised its /48 prefix to them, the traffic from		between all the possible 6to4 relays, and advertised its /48 prefix
	non-6to4 sites would always come from a "known" relay.		to them, the traffic from non-6to4 sites would always come from a
	Alternatively, the 6to4 relays might advertise the more specific 6to4		"known" relay. Alternatively, the 6to4 relays might advertise the
	routes between 6to4 relays.		more specific 6to4 routes between 6to4 relays.
	Both of these approaches are more or less obviously infeasible due to		Both of these approaches are more or less obviously infeasible due to
	scalability issues.		scalability issues.
	Neither of these models are known to be used at the time of writing;		Neither of these models are known to be used at the time of writing;
	this is probably caused by the fact that parties that need 6to4 are		this is probably caused by the fact that parties that need 6to4 are
	those that are not able to run BGP, and because setting up these		those that are not able to run BGP, and because setting up these
	sessions would be much more work for relay operators.		sessions would be much more work for relay operators.
	2.4.2 6to4 as an Optimization Method		2.4.2 6to4 as an Optimization Method
	Some sites seem to use 6to4 as an IPv6 connectivity "optimization		Some sites seem to use 6to4 as an IPv6 connectivity "optimization
	method"; that is, they have also non-6to4 addresses on their nodes		method"; that is, they have also non-6to4 addresses on their nodes
	and border routers, but also employ 6to4 to reach 6to4 sites.		and border routers, but also employ 6to4 to reach 6to4 sites.
	This is typically done to be able to reach 6to4 destinations by		This is typically done to be able to reach 6to4 destinations by
	direct tunneling and not having to use relays at all.		direct tunneling and not having to use relays at all.
	These sites also publish both 6to4 and non-6to4 addresses in DNS to		These sites also publish both 6to4 and non-6to4 addresses in DNS to
	affect inbound connections; if the source host's default address		affect inbound connections; if the source host's default address
	selection [6] works properly, 6to4 sources will use 6to4 addresses to		selection [7] works properly, 6to4 sources will use 6to4 addresses to
	reach the site and non-6to4 nodes use non-6to4 addresses. If this		reach the site and non-6to4 nodes use non-6to4 addresses. If this
	behavior of foreign nodes can be assumed, the security threats to		behavior of foreign nodes can be assumed, the security threats to
	such sites can be significantly simplified.		such sites can be significantly simplified.
	2.4.3 6to4 as Tunnel End-Point Addressing Mechanism		2.4.3 6to4 as Tunnel End-Point Addressing Mechanism
	6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel		6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel
	endpoint addressing and routing mechanism.		endpoint addressing and routing mechanism.
	An example of this is interconnecting 10 branch offices where nodes		An example of this is interconnecting 10 branch offices where nodes
	skipping to change at page 10, line 11		skipping to change at page 10, line 31
	o Decapsulate IPv4 packets received via the relay closest to the		o Decapsulate IPv4 packets received via the relay closest to the
	native IPv6 sources. Note, it is not easily distinguishable that		native IPv6 sources. Note, it is not easily distinguishable that
	the packet was really received from a 6to4 relay router, not from		the packet was really received from a 6to4 relay router, not from
	a spoofing third party.		a spoofing third party.
	The 6to4 router should also perform security checks on traffic that		The 6to4 router should also perform security checks on traffic that
	it will receive from other 6to4 relays, or 6to4 routers, or from		it will receive from other 6to4 relays, or 6to4 routers, or from
	within the 6to4 site. These checks include:		within the 6to4 site. These checks include:
	o Disallow traffic that has private, broadcast or reserved IPv4		o Disallow traffic that has private, broadcast or certain specific
	addresses in tunnels, or the matching 6to4 prefixes.		reserved IPv4 addresses (see Section 5.3.1 for details) in
			tunnels, or the matching 6to4 prefixes.
	o Disallow traffic from 6to4 routers where the IPv4 tunnel source		o Disallow traffic from 6to4 routers where the IPv4 tunnel source
	address does not match the 6to4 prefix. (Note that the		address does not match the 6to4 prefix. (Note that the
	pseudo-interface must pick the IPv4 address corresponding to the		pseudo-interface must pick the IPv4 address corresponding to the
	prefix when encapsulating, or else problems may ensue on e.g.,		prefix when encapsulating, or else problems may ensue on e.g.,
	multi-interface routers.)		multi-interface routers.)
	o Disallow traffic where the destination IPv6 address is not a		o Disallow traffic where the destination IPv6 address is not a
	global address; in particular, e.g. link-local addresses, mapped		global address; in particular, e.g. link-local addresses, mapped
	addresses and such should not be used.		addresses and such should not be used.
	skipping to change at page 11, line 16		skipping to change at page 11, line 35
	through tunneling, using normal IPv6 routing.		through tunneling, using normal IPv6 routing.
	o Tunnels packets received through normal IPv6 routing from native		o Tunnels packets received through normal IPv6 routing from native
	addresses, and are destined for 2002::/16, to the corresponding		addresses, and are destined for 2002::/16, to the corresponding
	6to4 router.		6to4 router.
	The 6to4 relay should also perform security checks on traffic that it		The 6to4 relay should also perform security checks on traffic that it
	will receive from 6to4 routers, or from native IPv6 nodes. These		will receive from 6to4 routers, or from native IPv6 nodes. These
	checks are:		checks are:
	o Disallow traffic that has private, broadcast or reserved IPv4		o Disallow traffic that has private, broadcast or certain specific
	addresses in tunnels, or the matching 6to4 prefixes.		reserved IPv4 addresses in tunnels, or the matching 6to4 prefixes.
	o Disallow traffic from 6to4 routers where the IPv4 tunnel source		o Disallow traffic from 6to4 routers where the IPv4 tunnel source
	address does not match the 6to4 prefix. (Note that the		address does not match the 6to4 prefix. (Note that the
	pseudo-interface must pick the IPv4 address corresponding to the		pseudo-interface must pick the IPv4 address corresponding to the
	prefix when encapsulating, or else problems may ensue on e.g.,		prefix when encapsulating, or else problems may ensue on e.g.,
	multi-interface routers.)		multi-interface routers.)
	o Disallow traffic where the destination IPv6 address is not a		o Disallow traffic where the destination IPv6 address is not a
	global address; in particular, e.g. link-local addresses, mapped		global address; in particular, e.g. link-local addresses, mapped
	addresses and such should not be used.		addresses and such should not be used.
	skipping to change at page 12, line 32		skipping to change at page 12, line 52
	The attacks descriptions are classified based on the target of the		The attacks descriptions are classified based on the target of the
	attack:		attack:
	1. Attacks on 6to4 networks.		1. Attacks on 6to4 networks.
	2. Attacks on IPv6 networks.		2. Attacks on IPv6 networks.
	3. Attacks on IPv4 networks.		3. Attacks on IPv4 networks.
	Note, the IPv4 address blocks 8.0.0.0/24 and 9.0.0.0/24 are only used
	for demonstrative purposes, and represent global IPv4 addresses.
	Note, one of the mitigation methods listed for various attacks is		Note, one of the mitigation methods listed for various attacks is
	based on the premise that 6to4 relays will a have a feature that may		based on the premise that 6to4 relays could have a feature that may
	be able to limit traffic to/from specific 6to4 sites. At the time of		be able to limit traffic to/from specific 6to4 sites. At the time of
	writing this document, such a feature is speculation, and more work		writing this document, such a feature is speculation, and more work
	needs to be done to determine the logistics of such a feature.		needs to be done to determine the logistics of such a feature.
	4.1 Attacks on 6to4 Networks		4.1 Attacks on 6to4 Networks
	This section describes attacks against 6to4 networks. Attacks which		This section describes attacks against 6to4 networks. Attacks which
	leverage 6to4 networks, but where the ultimate victim is elsewhere		leverage 6to4 networks, but where the ultimate victim is elsewhere
	(e.g., a native IPv6 user, an IPv4 user) are described later in the		(e.g., a native IPv6 user, an IPv4 user) are described later in the
	memo.		memo.
	skipping to change at page 13, line 46		skipping to change at page 14, line 16
	dst_v6 = fe80::1 (valid or invalid address)		dst_v6 = fe80::1 (valid or invalid address)
	src_v4 = 8.0.0.1 (valid or forged address)		src_v4 = 8.0.0.1 (valid or forged address)
	dst_v4 = 9.0.0.2 (valid address, matches dst_v6)		dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
	These attacks are exacerbated in case the implementation supports		These attacks are exacerbated in case the implementation supports
	more tunneling mechanisms than just 6to4 (or configured tunneling),		more tunneling mechanisms than just 6to4 (or configured tunneling),
	because it is impossible to disambiguate such mechanisms, making it		because it is impossible to disambiguate such mechanisms, making it
	difficult to enable strict security checks (see Section 6.1).		difficult to enable strict security checks (see Section 6.1).
	The Neighbor Discovery threats (Redirect DoS, or DoS) are described		The Neighbor Discovery threats (Redirect DoS, or DoS) are described
	in [7]. Note that all attacks may not be applicable, as the 6to4		in [8]. Note that all attacks may not be applicable, as the 6to4
	pseudo-interface is assumed not to have a link-layer address (Section		pseudo-interface is assumed not to have a link-layer address (Section
	3.8 RFC 2893 [4]). However, one should note that the 6to4 router can		3.8 RFC 2893 [4]). However, one should note that the 6to4 router can
	be either a router or host from the Neighbor Discovery perspective.		be either a router or host from the Neighbor Discovery perspective.
	THREAT ANALYSIS AND MITIGATION METHODS		THREAT ANALYSIS AND MITIGATION METHODS
	The attacks can be mitigated by using any of the following methods:		The attacks can be mitigated by using any of the following methods:
	o The usage of ND messages could be prohibited. It implies that all		o The usage of ND messages could be prohibited. It implies that all
	packets using addresses of scope link-local will be silently		packets using addresses of scope link-local will be silently
	discarded. Section 3.1 of RFC 3056 [1] leaves scope for future		discarded. Section 3.1 of RFC 3056 [1] leaves scope for future
	uses of link-local address. This method has its pitfalls - it		uses of link-local address. This method has its pitfalls - it
	would prohibit any sort of ND message, and thus close the doors on		would prohibit any sort of ND message, and thus close the doors on
	development, and use of other ND options. Whether this is a		development, and use of other ND options. Whether this is a
	significant problem is another thing.		significant problem is another thing.
	o The 6to4 pseudo-interface could be insulated from the other		o The 6to4 pseudo-interface could be insulated from the other
	interfaces (for example, using a separate neighbor cache).		interfaces, particularly the other tunnel interfaces (if any), for
			example using a separate neighbor cache.
	o Either IPsec [4] or an extension of SEND could be used [8] to		o If ND messages are needed, either IPsec [4] or an extension of
	secure packet exchange using link-local address; vanilla SEND		SEND could be used [9] to secure packet exchange using link-local
	would not work as the link-layer does not have an address -- and		address; vanilla SEND would not work as the link-layer does not
	IPsec would be rather complex.		have an address -- and IPsec would be rather complex.
	COMPARISON TO SITUATION WITHOUT 6to4		COMPARISON TO SITUATION WITHOUT 6to4
	Even though rather simply fixable, this attack is not new as such;		Even though rather simply fixable, this attack is not new as such;
	the same is possible using automatic tunneling [4] or configured		the same is possible using automatic tunneling [4] or configured
	tunneling (if one is able to spoof source IPv4 address to that of the		tunneling (if one is able to spoof source IPv4 address to that of the
	tunnel end-point).		tunnel end-point).
	However, as 6to4 provides open decapsulation, and automatic tunneling		However, as 6to4 provides open decapsulation, and automatic tunneling
	is being deprecated [9], 6to4 provides an easy means which would not		is being deprecated [10], 6to4 provides an easy means which would not
	exist without 6to4.		exist without 6to4.
	4.1.2 Spoofing Traffic to 6to4 Nodes		4.1.2 Spoofing Traffic to 6to4 Nodes
	ATTACK DESCRIPTION		ATTACK DESCRIPTION
	The attacker - a malicious IPv4 or IPv6 node - can send packets which		The attacker - a malicious IPv4 or IPv6 node - can send packets which
	are difficult to trace (e.g., due to spoofing or going through a		are difficult to trace (e.g., due to spoofing or going through a
	relay) to a 6to4 node. This can be used e.g., to accomplish a DoS		relay) to a 6to4 node. This can be used e.g., to accomplish a DoS
	attack.		attack.
	skipping to change at page 15, line 15		skipping to change at page 15, line 33
	node. From IPv4 nodes, src_v4 can be either a spoofed or the real		node. From IPv4 nodes, src_v4 can be either a spoofed or the real
	source address.		source address.
	The 6to4 router receives these packets from 8.0.0.1, decapsulates		The 6to4 router receives these packets from 8.0.0.1, decapsulates
	them, discards the IPv4 header containing the source address 8.0.0.1		them, discards the IPv4 header containing the source address 8.0.0.1
	and processes them as normal (the attacker has guessed or obtained		and processes them as normal (the attacker has guessed or obtained
	"dst_v6" using one of a number of techniques).		"dst_v6" using one of a number of techniques).
	This is a DoS attack on 6to4 nodes.		This is a DoS attack on 6to4 nodes.
	This attack is similar to ones shown in [10].		This attack is similar to ones shown in [11].
	EXTENSIONS		EXTENSIONS
	Replies to the traffic will be directed to the src_v6 address,		Replies to the traffic will be directed to the src_v6 address,
	resulting in 6to4 nodes in participating in a reflection DoS. This		resulting in 6to4 nodes in participating in a reflection DoS. This
	attack is described in more detail in Section 4.2.3. That is, the		attack is described in more detail in Section 4.2.3. That is, the
	replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to		replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to
	UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to		UDP echo service, ICMPv6 Destination Unreachable, etc.) are sent to
	the victim (src_v6), above. All the traces from the original		the victim (src_v6), above. All the traces from the original
	attacker (src_v4) have been discarded. These return packets will go		attacker (src_v4) have been discarded. These return packets will go
	skipping to change at page 16, line 34		skipping to change at page 16, line 50
	o The relay's IPv4 address may be used as a source address for these		o The relay's IPv4 address may be used as a source address for these
	attacks, potentially causing a lot of complaints or other actions		attacks, potentially causing a lot of complaints or other actions
	as the relay might seem to be the source of the attack (see		as the relay might seem to be the source of the attack (see
	Section 4.2.6 for more).		Section 4.2.6 for more).
	Some of the mitigation methods for such attacks are:		Some of the mitigation methods for such attacks are:
	1. Ingress filtering in the native IPv6 networks to prevent packets		1. Ingress filtering in the native IPv6 networks to prevent packets
	with spoofed IPv6 source being transmitted. It would, thus, make		with spoofed IPv6 source being transmitted. It would, thus, make
	it easy to identify the source of the attack.		it easy to identify the source of the attack. Unfortunately,
			this would depend on significant (or even complete) ingress
			filtering everywhere in other networks; while this is highly
			desirable, it may also be practically unfeasible.
	2. Security checks in the 6to4 relay. The 6to4 relay must drop		2. Security checks in the 6to4 relay. The 6to4 relay must drop
	traffic (from the IPv6 internet) that has 6to4 addresses as		traffic (from the IPv6 Internet) that has 6to4 addresses as
	source address, see Section 5 for more.		source address, see Section 5 for more. This has very little
			cost.
	However, these mitigation methods do not address the case of IPv4		However, these mitigation methods do not address the case of IPv4
	node sending encapsulated IPv6 packets.		node sending encapsulated IPv6 packets.
	There exists no simple way to prevent such attacks, and longer term		There exists no simple way to prevent such attacks, and longer term
	solutions like ingress filtering [11] or itrace [12] would have to be		solutions like ingress filtering [12] or itrace [13] would have to be
	deployed in both IPv6 and IPv4 networks to help identify the source		deployed in both IPv6 and IPv4 networks to help identify the source
	of the attacks. (Note that itrace work has been discontinued, as of		of the attacks. A total penetration is likely impossible to achieve.
	this writing.)		(Note that itrace work has been discontinued, as of this writing in
			July 2004.)
	COMPARISON TO SITUATION WITHOUT 6to4		COMPARISON TO SITUATION WITHOUT 6to4
	Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just		Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just
	makes it easier: anyone can, regardless of ingress filtering, spoof a		makes it easier: anyone can, regardless of ingress filtering, spoof a
	native IPv6 address to a 6to4 node, even if "maximal security" would		native IPv6 address to a 6to4 node, even if "maximal security" would
	be implemented and deployed. Losing trails is also easier.		be implemented and deployed. Losing trails is also easier.
	Therefore, depending on how much one assumes ingress filtering is		Therefore, depending on how much one assumes ingress filtering is
	deployed for IPv4 and IPv6, this could be considered to be a very		deployed for IPv4 and IPv6, this could be considered to be a very
	skipping to change at page 18, line 4		skipping to change at page 18, line 24
	are involved in sending spoofed traffic with the same src_v6.		are involved in sending spoofed traffic with the same src_v6.
	Malicious 6to4 nodes can also (try to) initiate this attack by		Malicious 6to4 nodes can also (try to) initiate this attack by
	bouncing traffic off 6to4 nodes in other 6to4 sites. However this		bouncing traffic off 6to4 nodes in other 6to4 sites. However this
	attack may not be possible as the 6to4 router (in the site from which		attack may not be possible as the 6to4 router (in the site from which
	the attack is being launched) will filter packets with forged source		the attack is being launched) will filter packets with forged source
	address (with security checks mentioned in Section 5), and thus the		address (with security checks mentioned in Section 5), and thus the
	attack will be prevented.		attack will be prevented.
	THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS		THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
	The reverse traffic in this case are replies to the messages received		The reverse traffic in this case are replies to the messages received
	by the 6to4 nodes. The attacker has less control on the packet type		by the 6to4 nodes. The attacker has less control on the packet type
	in this case, and this would inhibit certain types of attacks. For		in this case, and this would inhibit certain types of attacks. For
	example, flooding a 6to4 node with TCP SYN packets will not be		example, flooding a 6to4 node with TCP SYN packets will not be
	possible (but e.g., a SYN-ACK or RST would be).		possible (but e.g., a SYN-ACK or RST would be).
	These attacks may be countered in various ways:		These attacks may be mitigated in various ways:
	o Implementation of ingress filtering by the IPv4 service providers.		o Implementation of ingress filtering by the IPv4 service providers.
	It would prevent forging of the src_v4 address, and would help in		It would prevent forging of the src_v4 address, and would help in
	closing down on the culprit IPv4 nodes. Note that, it will be		closing down on the culprit IPv4 nodes. Note that, it will be
	difficult to shut down the attack if a large number of IPv4 nodes		difficult to shut down the attack if a large number of IPv4 nodes
	are involved.		are involved.
	These attacks may be also be stopped at the 6to4 sites if the		These attacks may be also be stopped at the 6to4 sites if the
	culprit src_v4 address is identified, and if it is constant, by		culprit src_v4 address is identified, and if it is constant, by
	filtering traffic from this address. Note that it would be		filtering traffic from this address. Note that it would be
	difficult to implement this method, if appropriate logging is not		difficult to implement this method, if appropriate logging is not
	done by the 6to4 router, or if a large number of 6to4 nodes, and/		done by the 6to4 router, or if a large number of 6to4 nodes, and/
	or a large number of IPv4 nodes are participating in the attack.		or a large number of IPv4 nodes are participating in the attack.
			Unfortunately, as many IPv4 service providers don't implement
			ingress filtering, for whatever reasons, this may not be a
			satisfactory resolution.
	o Implementation of ingress filtering by all IPv6 service providers		o Implementation of ingress filtering by all IPv6 service providers
	would eliminate this attack, because src_v6 could not be spoofed		would eliminate this attack, because src_v6 could not be spoofed
	to be a 6to4 address. However, expecting this to happen may not		to be a 6to4 address. However, expecting this to happen may not
	be practical.		be practical.
	o Proper implementation of security checks (see Section 5) both at		o Proper implementation of security checks (see Section 5) both at
	the 6to4 relays and routers would eliminate the attack, when		the 6to4 relays and routers would eliminate the attack, when
	launched from an IPv4 node, except when the IPv4 source address		launched from an IPv4 node, except when the IPv4 source address
	was also spoofed -- but then the attacker would have been able to		was also spoofed -- but then the attacker would have been able to
	just attack the ultimate destination directly.		just attack the ultimate destination directly.
	o Rate limiting traffic at the 6to4 relays. In a scenario where		o Rate limiting traffic at the 6to4 relays. In a scenario where
	most of the traffic is passing through few 6to4 relays, these		most of the traffic is passing through few 6to4 relays, these
	relays can implement traffic rate-limiting features, and		relays can implement traffic rate-limiting features, and
	rate-limit the traffic from 6to4 sites		rate-limit the traffic from 6to4 sites.
	COMPARISON TO SITUATION WITHOUT 6to4		COMPARISON TO SITUATION WITHOUT 6to4
	This particular attack can be mitigated by proper implementation of		This particular attack can be mitigated by proper implementation of
	security checks and ingress filtering; where ingress filtering is not		security checks (which is quite straightforward) and ingress
	implemented, it's typically easier to attack directly than through		filtering; where ingress filtering is not implemented, it's typically
	reflection -- unless "traffic laundering" is an explicit goal in the		easier to attack directly than through reflection -- unless "traffic
	attack. Therefore, this attack does not seem very serious.		laundering" is an explicit goal in the attack. Therefore, this
			attack does not seem very serious.
	4.1.4 Local IPv4 Broadcast Attack		4.1.4 Local IPv4 Broadcast Attack
	ATTACK DESCRIPTION		ATTACK DESCRIPTION
	This threat is applicable if the 6to4 router does not check whether		This threat is applicable if the 6to4 router does not check whether
	the IPv4 address it tries to send encapsulated IPv6 packets to a		the IPv4 address it tries to send encapsulated IPv6 packets to a
	local broadcast address, or a multicast address.		local broadcast address, or a multicast address.
	This threat is described in the specification [1], and implementing		This threat is described in the specification [1], and implementing
	the checks eliminates this threat. However, as this has not been		the checks eliminates this threat. However, as this has not been
	widely implemented, it is included here regardless for completeness.		widely implemented, it is included here regardless for completeness.
	There practically two kinds of attacks: where a local 6to4 user tries		There practically two kinds of attacks: where a local 6to4 user tries
	to send packets to the address corresponding to the broadcast		to send packets to the address corresponding to the broadcast
	skipping to change at page 19, line 27		skipping to change at page 20, line 6
	broadcast address. After receiving the packet with a destionation		broadcast address. After receiving the packet with a destionation
	address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the		address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the
	router doesn't check the destination address for subnet broadcast, it		router doesn't check the destination address for subnet broadcast, it
	would send the encapsulated protocol-41 packet to 9.0.0.255. This		would send the encapsulated protocol-41 packet to 9.0.0.255. This
	would be received by all nodes in the subnet, and the responses would		would be received by all nodes in the subnet, and the responses would
	be directed to the 6to4 router.		be directed to the 6to4 router.
	Malicious sites may also embed forged 6to4 addresses in the DNS, use		Malicious sites may also embed forged 6to4 addresses in the DNS, use
	of which by a 6to4 node will result in a local broadcast by the 6to4		of which by a 6to4 node will result in a local broadcast by the 6to4
	router. One way to perform this attack would be to send an HTML mail		router. One way to perform this attack would be to send an HTML mail
	containing a link to an invalid URL (for example,		containing a link to an invalid URL (for example, http://
	http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4		[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology
	technology based network. Opening of the mail simultaneously would		based network. Opening of the mail simultaneously would result in a
	result in a broadcast storm.		broadcast storm.
	The second kind of attack is more complex: the attack can be		The second kind of attack is more complex: the attack can be
	initiated by IPv4 nodes not belonging to the local network as long as		initiated by IPv4 nodes not belonging to the local network as long as
	they can send traffic with invalid (for example 2002:0900:00ff::bbbb)		they can send traffic with invalid (for example 2002:0900:00ff::bbbb)
	source address. The 6to4 router has to respond to the traffic by		source address. The 6to4 router has to respond to the traffic by
	sending ICMPv6 packets back to the source, for example Hop Limit		sending ICMPv6 packets back to the source, for example Hop Limit
	Exceeded or Destination Unreachable. The packet would be as follows:		Exceeded or Destination Unreachable. The packet would be as follows:
	src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)		src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
	dst_v6 = 2002:0800:0001::0001 (valid non-existent address)		dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
	skipping to change at page 22, line 21		skipping to change at page 22, line 49
	could tone down the attack.		could tone down the attack.
	o For every packet sent, at most one reply packet is generated:		o For every packet sent, at most one reply packet is generated:
	there is no amplification factor.		there is no amplification factor.
	Some of the mitigation methods for such attacks are:		Some of the mitigation methods for such attacks are:
	1. Ingress filtering in the IPv4 Internet to prevent packets with		1. Ingress filtering in the IPv4 Internet to prevent packets with
	spoofed IPv4 source being transmitted. As the relay checks that		spoofed IPv4 source being transmitted. As the relay checks that
	the 6to4 address embeds the IPv4 address, no spoofing can be		the 6to4 address embeds the IPv4 address, no spoofing can be
	achieved done unless IPv4 addresses can be spoofed.		achieved done unless IPv4 addresses can be spoofed. However,
			this would probably be an unfeasible requirement.
	2. Security checks in the 6to4 relay. The 6to4 relay must drop		2. Security checks in the 6to4 relay. The 6to4 relay must drop
	traffic (from 6to4 nodes, or IPv4 nodes) that has non-6to4		traffic (from 6to4 nodes, or IPv4 nodes) that has non-6to4
	addresses as source address, or where the source IPv4 address		addresses as source address, or where the source IPv4 address
	does not match the address embebdded in the source IPv6 address.		does not match the address embebdded in the source IPv6 address.
	COMPARISON TO SITUATION WITHOUT 6to4		COMPARISON TO SITUATION WITHOUT 6to4
	Compared to Section 4.1.2, which is more serious, this threat appears		Compared to Section 4.1.2, which is more serious, this threat appears
	to be slightly more manageable. If the relays perform proper		to be slightly more manageable. If the relays perform proper
	skipping to change at page 23, line 22		skipping to change at page 24, line 4
	from a 6to4/IPv4 node, the traffic goes through a relay only after		from a 6to4/IPv4 node, the traffic goes through a relay only after
	the reflection.		the reflection.
	EXTENSIONS		EXTENSIONS
	A distributed Reflection DoS can be performed if a large number of		A distributed Reflection DoS can be performed if a large number of
	native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed		native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed
	traffic with the same source IPv6 address.		traffic with the same source IPv6 address.
	THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS		THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
	Some of the mitigation methods for such attacks are:		Some of the mitigation methods for such attacks are:
	1. Attacks from the native IPv6 nodes could be stopped by		1. Attacks from the native IPv6 nodes could be stopped by
	implementing ingress filtering in the IPv6 Internet.		implementing ingress filtering in the IPv6 Internet; hopefully
			this will become commonplace, but past experience of IPv4 ingress
			filtering deployment (or lack thereof) does not promise much.
	2. Two measures are needed to stop or mitigate the attacks from IPv4		2. Two measures are needed to stop or mitigate the attacks from IPv4
	nodes: 1) Implementing ingress filtering in the IPv4 internet,		nodes: 1) Implementing ingress filtering in the IPv4 internet,
	and 2) logging IPv4 source address in the 6to4 router.		and 2) logging IPv4 source address in the 6to4 router.
	3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4		3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4
	router in those sites implements egress filtering.		router in those sites implements egress filtering. This could be
			done by those sites, but the sites who are most likely to be
			abused are typically also most likely to be neglecting to
			installing appropriate filtering at their edges.
	4. The traffic passes through one or two relays, and traffic rate		4. The traffic passes through one or two relays, and traffic rate
	limiting in the 6to4 relays might help tone down the reflection		limiting in the 6to4 relays might help tone down the reflection
	attack.		attack.
	COMPARISON TO SITUATION WITHOUT 6to4		COMPARISON TO SITUATION WITHOUT 6to4
	Even thought there are means to mitigate the attack, it is still		Even thought there are means to mitigate the attack, it is still
	rather efficient, especially when used by native IPv6 nodes with		rather efficient, especially when used by native IPv6 nodes with
	spoofed addresses. Using 6to4 relays and routers could easily take		spoofed addresses. Using 6to4 relays and routers could easily take
	skipping to change at page 25, line 49		skipping to change at page 26, line 35
	1. Usage of access lists in the relay to limit access.		1. Usage of access lists in the relay to limit access.
	2. Filtering out the packets with a routing header (may have other		2. Filtering out the packets with a routing header (may have other
	implications).		implications).
	3. Monitoring the source addresses going through the relay, to		3. Monitoring the source addresses going through the relay, to
	detect e.g. peers setting up static routes.		detect e.g. peers setting up static routes.
	Routing Header is not specific to 6to4, the main things one could do		Routing Header is not specific to 6to4, the main things one could do
	here with it would be to select the relay; some generic threats about		here with it would be to select the relay; some generic threats about
	Routing Header use are described in [10].		Routing Header use are described in [11].
	As this threat does not have implications on other than the		As this threat does not have implications on other than the
	organization providing 6to4 relay, it is not analyzed any further.		organization providing 6to4 relay, it is not analyzed any further.
	COMPARISON TO SITUATION WITHOUT 6to4		COMPARISON TO SITUATION WITHOUT 6to4
	These threats are specific to 6to4 relays (or in general, anycast		These threats are specific to 6to4 relays (or in general, anycast
	services), and do not exist in networks without 6to4.		services), and do not exist in networks without 6to4.
	4.2.6 Relay Operators Seen as Source of Abuse		4.2.6 Relay Operators Seen as Source of Abuse
	skipping to change at page 26, line 51		skipping to change at page 27, line 37
	None.		None.
	THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS		THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
	This problem can be avoided (or really, "made someone else's		This problem can be avoided (or really, "made someone else's
	problem") by using the 6to4 anycast address in 192.88.99.0/24 as the		problem") by using the 6to4 anycast address in 192.88.99.0/24 as the
	source address: blacklisting or rejecting that should not cause		source address: blacklisting or rejecting that should not cause
	problems to the other operations.		problems to the other operations.
	Further, when someone is filing complaints to the owner of		Further, when someone is filing complaints to the owner of
	192.88.99.0/24, they notice multiple WHOIS records and see a pointer		192.88.99.0/24, depending on which registry they are querying, they
	to [3], and may learn that the 6to4 relay is in fact innocent. Of		might get, for example:
	course, this could result in these reports going to the closest
	anycast 6to4 relay as well, which in fact had nothing to do with the		o Knowledge that this is a special IANA address block, with no real
	incident.		contact person,
			o Knowledge that this is a special address block for RFC 3068, or
			o Knowledge that this is a special address block for RFC 3068, and
			that there are multiple entries in the database by relay
			operators.
			Any of these, at least when processed by a human, should make one
			learn that the 6to4 relay is in fact innocent. Of course, this could
			result in these reports going to the closest anycast 6to4 relay as
			well, which in fact had nothing to do with the incident.
	However, the wide-spread usage of 192.88.99.1 as the source address		However, the wide-spread usage of 192.88.99.1 as the source address
	may make it more difficult to disambiguate the relays, which might be		may make it more difficult to disambiguate the relays, which might be
	a useful feature for debugging purposes.		a useful feature for debugging purposes.
	COMPARISON TO SITUATION WITHOUT 6to4		COMPARISON TO SITUATION WITHOUT 6to4
	This threat is caused by 6to4 deployment, but can be avoided, at		This threat is caused by 6to4 deployment, but can be avoided, at
	least in the short-term, by using the use of 192.88.99.1 as the		least in the short-term, by using the use of 192.88.99.1 as the
	source address.		source address.
	skipping to change at page 31, line 31		skipping to change at page 32, line 31
	5.3 IPv4 and IPv6 Sanity Checks		5.3 IPv4 and IPv6 Sanity Checks
	The encapsulation and decapsulation checks included certain sanity		The encapsulation and decapsulation checks included certain sanity
	checks for both IPv4 and IPv6. These are described here in detail.		checks for both IPv4 and IPv6. These are described here in detail.
	5.3.1 IPv4		5.3.1 IPv4
	IPv4 address MUST be a global unicast address, as required by the		IPv4 address MUST be a global unicast address, as required by the
	6to4 specification. The disallowed addresses include those defined		6to4 specification. The disallowed addresses include those defined
	in [13], and others widely used and known not to be global. These		in [14], and others widely used and known not to be global. These
	are:		are:
	o 0.0.0.0/8 (the system has no address assigned yet)		o 0.0.0.0/8 (the system has no address assigned yet)
	o 10.0.0.0/8 (private)		o 10.0.0.0/8 (private)
	o 127.0.0.0/8 (loopback)		o 127.0.0.0/8 (loopback)
	o 172.16.0.0/12 (private)		o 172.16.0.0/12 (private)
	skipping to change at page 33, line 26		skipping to change at page 34, line 26
	implementations are faced with, and the kind of generic problems the		implementations are faced with, and the kind of generic problems the
	6to4 users could come up with.		6to4 users could come up with.
	6.1 Implementation Considerations with Automatic Tunnels		6.1 Implementation Considerations with Automatic Tunnels
	There is a problem with multiple transition mechanisms if strict		There is a problem with multiple transition mechanisms if strict
	security checks are implemented. This may vary a bit from		security checks are implemented. This may vary a bit from
	implementation to implementation.		implementation to implementation.
	Consider three mechanisms using automatic tunneling: 6to4, ISATAP		Consider three mechanisms using automatic tunneling: 6to4, ISATAP
	[14] and Automatic Tunneling using Compatible Addresses [4]		[15] and Automatic Tunneling using Compatible Addresses [4]
	(currently removed [9] but typically still supported). All of these		(currently removed [10] but typically still supported). All of these
	use IP-IP (protocol 41) [15] IPv4 encapsulation with, more or less, a		use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a
	pseudo-interface.		pseudo-interface.
	When a router, which has any two of these enabled, receives an IPv4		When a router, which has any two of these enabled, receives an IPv4
	encapsulated IPv6 packet:		encapsulated IPv6 packet:
	src_v6 = 2001:db8::1		src_v6 = 2001:db8::1
	dst_v6 = 2002:1010:1010::2		dst_v6 = 2002:1010:1010::2
	src_v4 = 10.0.0.1		src_v4 = 10.0.0.1
	dst_v4 = 20.20.20.20		dst_v4 = 20.20.20.20
	skipping to change at page 35, line 44		skipping to change at page 36, line 44
	These are analyzed in detail in Threat Analysis, in Section 4.		These are analyzed in detail in Threat Analysis, in Section 4.
	8. IANA Considerations		8. IANA Considerations
	This memo makes no requet to IANA. (RFC-editor note: please remove		This memo makes no requet to IANA. (RFC-editor note: please remove
	this section on publication.)		this section on publication.)
	9. Acknowledgments		9. Acknowledgments
	Some issues were first brought up by Itojun Hagino in [16], and Alain		Some issues were first brought up by Itojun Hagino in [17], and Alain
	Durand introduced one specific problem at IETF51 in August 2001		Durand introduced one specific problem at IETF51 in August 2001
	(though there was some discussion on the list prior to that); these		(though there was some discussion on the list prior to that); these
	gave the author the push to start looking into the details of		gave the author the push to start looking into the details of
	securing 6to4.		securing 6to4.
	Alexey Kuznetsov brought up the implementation problem with IPv6		Alexey Kuznetsov brought up the implementation problem with IPv6
	martian checks. Christian Huitema formulated the rules that rely on		martian checks. Christian Huitema formulated the rules that rely on
	6to4 relays using only anycast. Keith Moore brought up the point		6to4 relays using only anycast. Keith Moore brought up the point
	about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav		about reduced flexibility. Brian Carpenter, Tony Hain and Vladislav
	Yasevich are acknowledged for lengthy discussions. Alain Durand		Yasevich are acknowledged for lengthy discussions. Alain Durand
	skipping to change at page 36, line 37		skipping to change at page 37, line 37
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC		[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
	3068, June 2001.		3068, June 2001.
	10.2 Informative References		10.2 Informative References
	[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6		[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
	Hosts and Routers", RFC 2893, August 2000.		Hosts and Routers", RFC 2893, August 2000.
	[5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",		[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
			[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
	RFC 1771, March 1995.		RFC 1771, March 1995.
	[6] Draves, R., "Default Address Selection for Internet Protocol		[7] Draves, R., "Default Address Selection for Internet Protocol
	version 6 (IPv6)", RFC 3484, February 2003.		version 6 (IPv6)", RFC 3484, February 2003.
	[7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor		[8] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
	Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.		Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
	[8] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,		[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05		"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
	(work in progress), April 2004.		(work in progress), April 2004.
	[9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for		[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
	IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in		IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in
	progress), June 2004.		progress), June 2004.
	[10] Savola, P., "Security of IPv6 Routing Header and Home Address		[11] Savola, P., "Security of IPv6 Routing Header and Home Address
	Options", draft-savola-ipv6-rh-ha-security-02 (work in		Options", draft-savola-ipv6-rh-ha-security-02 (work in
	progress), March 2002.		progress), March 2002.
	[11] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[12] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
	[12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback		[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback
	Messages", draft-ietf-itrace-04 (work in progress), February		Messages", draft-ietf-itrace-04 (work in progress), February
	2003.		2003.
	[13] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,		[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
	June 1995.		June 1995.
	[14] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site		[15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
	Automatic Tunnel Addressing Protocol (ISATAP)",		Automatic Tunnel Addressing Protocol (ISATAP)",
	draft-ietf-ngtrans-isatap-22 (work in progress), May 2004.		draft-ietf-ngtrans-isatap-22 (work in progress), May 2004.
	[15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.		[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
	[16] Hagino, J., "Possible abuse against IPv6 transition		[17] Hagino, J., "Possible abuse against IPv6 transition
	technologies", draft-itojun-ipv6-transition-abuse-01.txt		technologies", draft-itojun-ipv6-transition-abuse-01.txt
	(expired, work-in-progress) , July 2000.		(expired, work-in-progress) , July 2000.
	Authors' Addresses		Authors' Addresses
	Pekka Savola		Pekka Savola
	CSC/FUNET		CSC/FUNET
	Espoo		Espoo
	Finland		Finland
	skipping to change at page 38, line 11		skipping to change at page 39, line 20
	Phone: +91-98452-88078		Phone: +91-98452-88078
	EMail: chirayu@chirayu.org		EMail: chirayu@chirayu.org
	URI: http://www.chirayu.org		URI: http://www.chirayu.org
	Appendix A. Some Trivial Attack Scenarios Outlined		Appendix A. Some Trivial Attack Scenarios Outlined
	Here, a few trivial attack scenarios are outlined -- ones that are		Here, a few trivial attack scenarios are outlined -- ones that are
	prevented by implementing checks listed in [1] or in section 6.		prevented by implementing checks listed in [1] or in section 6.
	When two 6to4 routers send traffic to each others' domains, packet		When two 6to4 routers send traffic to each others' domains, packet
	sent by RA to RB is like (note: addresses from 8.0.0.0/24 are just		sent by RA to RB is like:
	examples of global IPv4 addresses):
	src_v6 = 2002:0800:0001::aaaa		src_v6 = 2002:0800:0001::aaaa
	dst_v6 = 2002:0800:0002::bbbb		dst_v6 = 2002:0800:0002::bbbb
	src_v4 = 8.0.0.1 (added when encapsulated to IPv4)		src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
	dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)		dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
	When the packet is received by IPv4 stack on RB, it will be		When the packet is received by IPv4 stack on RB, it will be
	decapsulated so that only src_v6 and dst_v6 remain, as originally		decapsulated so that only src_v6 and dst_v6 remain, as originally
	sent by RA:		sent by RA:
	skipping to change at page 39, line 11		skipping to change at page 40, line 20
	src_v6/dst_v6 = ...		src_v6/dst_v6 = ...
	Some implementations might have been careful enough to have designed		Some implementations might have been careful enough to have designed
	the stack to as to avoid the incoming (or reply) packets going to		the stack to as to avoid the incoming (or reply) packets going to
	IPv4 packet processing through special addresses (e.g., IPv4-mapped		IPv4 packet processing through special addresses (e.g., IPv4-mapped
	addresses), but who can say for all ...		addresses), but who can say for all ...
	Appendix B. Change Log		Appendix B. Change Log
	[[ RFC-EDITOR note: to be removed before publication ]]		[[ RFC-EDITOR note: to be removed before publication ]]
			Changes from -03 to -04
			1. Some editorial fixes; resolve IESG evaluation comments.
	Changes from -02 to -03		Changes from -02 to -03
	1. Only rather minor editorial changes.		1. Only rather minor editorial changes.
	Changes from -01 to -02		Changes from -01 to -02
	1. Incorporate Iljitsch's feedback		1. Incorporate Iljitsch's feedback
	2. Clean up section 6.2		2. Clean up section 6.2
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/