draft-ietf-v6ops-6to4-security-01.txt		draft-ietf-v6ops-6to4-security-02.txt
	v6ops Working Group P. Savola		v6ops Working Group P. Savola
	Internet-Draft CSC/FUNET		Internet-Draft CSC/FUNET
	Expires: August 10, 2004 C. Patel		Expires: September 7, 2004 C. Patel
	All Play, No Work		All Play, No Work
	Feb 10, 2004		Mar 9, 2004
	Security Considerations for 6to4		Security Considerations for 6to4
	draft-ietf-v6ops-6to4-security-01.txt		draft-ietf-v6ops-6to4-security-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3667.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as 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 http://		The list of current Internet-Drafts can be accessed at 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 August 10, 2004.		This Internet-Draft will expire on September 7, 2004.
	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
	accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from		accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from
	any node in the IPv4 internet. This characteristic enable ones to go		any node in the IPv4 internet. This characteristic enables a number
	around access controls and perform Denial of Service attacks using		of security threats, mainly Denial of Service. It also makes it
	6to4 relays or 6to4 routers. It also makes it easier for nodes to		easier for nodes to spoof IPv6 addresses. This document discusses
	spoof IPv6 addresses. This document discusses these issues in more		these issues in more detail and suggests enhancements to alleviate
	detail and suggests enhancements to alleviate the problems.		the problems.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . 5		2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . 4
	2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . . . 5		2.1 From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . 4
	2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . . . . 5		2.2 From Native to 6to4 . . . . . . . . . . . . . . . . . 4
	2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . . . . 6		2.3 From 6to4 to Native . . . . . . . . . . . . . . . . . 5
	2.4 Other Models . . . . . . . . . . . . . . . . . . . . . . . . 6		2.4 Other Models . . . . . . . . . . . . . . . . . . . . . 5
	2.4.1 BGP Between 6to4 Routers and Relays . . . . . . . . . . . . 7		2.4.1 BGP Between 6to4 Routers and Relays . . . . . . 6
	2.4.2 6to4 as an Optimization Method . . . . . . . . . . . . . . . 7		2.4.2 6to4 as an Optimization Method . . . . . . . . . 6
	2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . . . . . . . 7		2.4.3 6to4 as Tunnel End-Point Addressing Mechanism . 6
	3. Functionalities of 6to4 Network Components . . . . . . . . . 9		3. Functionalities of 6to4 Network Components . . . . . . . . . 8
	3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1 6to4 Routers . . . . . . . . . . . . . . . . . . . . . 8
	3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . . . 10		3.2 6to4 Relay Routers . . . . . . . . . . . . . . . . . . 9
	4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . 11		4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . 10
	4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . . . . 12		4.1 Attacks on 6to4 Networks . . . . . . . . . . . . . . . 11
	4.1.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 13		4.1.1 Attacks with ND Messages . . . . . . . . . . . . 12
	4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . . . . . . . 14		4.1.2 Spoofing Traffic to 6to4 Nodes . . . . . . . . . 13
	4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . . . . . . . 16		4.1.3 Reflecting Traffic to 6to4 Nodes . . . . . . . . 16
	4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . . . . 18		4.1.4 Local IPv4 Broadcast Attack . . . . . . . . . . 17
	4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . . . . 19		4.2 Attacks on Native IPv6 Internet . . . . . . . . . . . 19
	4.2.1 Attacks with ND Messages . . . . . . . . . . . . . . . . . . 20		4.2.1 Attacks with ND Messages . . . . . . . . . . . . 19
	4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . . . . . . . 20		4.2.2 Spoofing Traffic to Native IPv6 node . . . . . . 20
	4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . . . . . . . 22		4.2.3 Reflecting Traffic to Native IPv6 nodes . . . . 21
	4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . . . . . . . 23		4.2.4 Local IPv4 Broadcast Attack . . . . . . . . . . 23
	4.2.5 Theft of Service . . . . . . . . . . . . . . . . . . . . . . 24		4.2.5 Theft of Service . . . . . . . . . . . . . . . . 23
	4.2.6 Relay Operators Seen as Source of Abuse . . . . . . . . . . 25		4.2.6 Relay Operators Seen as Source of Abuse . . . . 25
	4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . . . . 26		4.3 Attacks on IPv4 Internet . . . . . . . . . . . . . . . 26
	4.4 Summary of the Attacks . . . . . . . . . . . . . . . . . . . 27		4.4 Summary of the Attacks . . . . . . . . . . . . . . . . 26
	5. Implementing Proper Security Checks in 6to4 . . . . . . . . 29		5. Implementing Proper Security Checks in 6to4 . . . . . . . . 28
	5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . . . 29		5.1 Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . 29
	5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . . . 30		5.2 Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . 29
	5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . . . 30		5.3 IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . 30
	5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30		5.3.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . 30
	5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31		5.3.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . 31
	5.3.3 Optional Ingress Filtering . . . . . . . . . . . . . . . . . 32		5.3.3 Optional Ingress Filtering . . . . . . . . . . . 31
	5.3.4 Notes About the Checks . . . . . . . . . . . . . . . . . . . 32		5.3.4 Notes About the Checks . . . . . . . . . . . . . 31
	6. Issues in 6to4 Implementation and Use . . . . . . . . . . . 32		6. Issues in 6to4 Implementation and Use . . . . . . . . . . . 32
	6.1 Implementation Considerations with Automatic Tunnels . . . . 32		6.1 Implementation Considerations with Automatic Tunnels . 32
	6.2 Anyone Pretending to Be a 6to4 Relay . . . . . . . . . . . . 33		6.2 A Different Model for 6to4 Deployment . . . . . . . . 33
	6.2.1 Limited Distribution of More Specific Routes . . . . . . . . 34		7. Security Considerations . . . . . . . . . . . . . . . . . . 34
	6.2.2 A Different Model for 6to4 Deployment . . . . . . . . . . . 35		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 34
	7. Security Considerations . . . . . . . . . . . . . . . . . . 35		Normative References . . . . . . . . . . . . . . . . . . . . 35
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36		Informative References . . . . . . . . . . . . . . . . . . . 35
	Normative References . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36
	Informative References . . . . . . . . . . . . . . . . . . . 37		A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38		B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
	A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . 38		Intellectual Property and Copyright Statements . . . . . . . 39
	B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
	Intellectual Property and Copyright Statements . . . . . . . 40
	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 from traffic from any other 6to4
	router or relay, it implies a certain level of trust, and there are		router or relay, a certain requirement for trust is implied, and
	no strict constraints on what the IPv6 packet may contain. Thus,		there are no strict constraints on what the IPv6 packet may contain.
	addresses within the IPv4, and IPv6 header may be spoofed, and this		Thus, addresses within the IPv4, and IPv6 header may be spoofed, and
	property leads to various types of threats including DoS, and		this property leads to various types of threats including different
	reflection DoS.		flavors of Denial of Service -attacks.
	The 6to4 specification outlined quite a few security considerations,		The 6to4 specification outlined a few security considerations and
	but it has been shown that in practice some of them have been		rules, but was very ambiguous on their exact requirement level.
	difficult to get implemented due to their abstract nature.		Further, the description of the considerations was rather short, and
			in fact, some of them have been proven to be difficult to understand
			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.
	Section 2, and Section 3 are more or less introductory in nature,		Section 2, and Section 3 are more or less introductory in nature,
	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 introduces some		implement most of the security checks. Section 5 describes the
	filtering rules for 6to4 implementations, and Section 6 provides		optimal decapsulation/encapsulation rules for 6to4 implementations,
	further discussion on a few issues which have proven to be difficult.		and Section 6 provides further discussion on a few issues which have
	Appendix A outlines a few possible trivial attack scenarios in the		proven to be difficult to implement. Appendix A outlines a few
	case that very little or no security has been implemented.		possible trivial attack scenarios in the case that very little or no
			security has been implemented.
	For the sake of simplicity, in this document, native IPv6 Internet is		For the sake of simplicity, in this document, native IPv6 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 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].
	skipping to change at page 7, line 17		skipping to change at page 6, line 17
	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 [5] is used between 6to4 relay routers and 6to4
	routers.		routers.
	If the 6to4 router established a BGP session between all the possible		If the 6to4 router established a BGP session between all the possible
	6to4 relays, and advertised its /48 prefix to them, the traffic from		6to4 relays, and advertised its /48 prefix to them, the traffic from
	non-6to4 sites would always come from a "known" relay.		non-6to4 sites would always come from a "known" relay.
	Alternatively, the 6to4 relays might advertise the more specific 6to4		Alternatively, the 6to4 relays might advertise the more specific 6to4
	routes between 6to4 relays, as described in Section 6.2.1 in this		routes between 6to4 relays.
	memo.
			Both of these approaches are more or less obviously infeasible due to
			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
	skipping to change at page 9, line 27		skipping to change at page 8, line 29
	provided in Section 5.		provided in Section 5.
	This section summarizes the main functions of the various components		This section summarizes the main functions of the various components
	that are part of a 6to4 network - 6to4 relay routers, and 6to4		that are part of a 6to4 network - 6to4 relay routers, and 6to4
	routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related		routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4 related
	definitions.		definitions.
	3.1 6to4 Routers		3.1 6to4 Routers
	The 6to4 routers acts as the border router of a 6to4 domain. It does		The 6to4 routers acts as the border router of a 6to4 domain. It does
	not have a native, global IPv6 address. The main functions of the		not have a native, global IPv6 address except in certain special
	6to4 router are:		cases. Since the specification [1] uses the term "6to4 router", this
			memo does the same; however, note that we also include a single host
			with a 6to4 pseudo-interface, which doesn't otherwise act as a
			router, in this definition. The main functions of the 6to4 router
			are:
	o Provide IPv6 connectivity to local clients and routers.		o Provide IPv6 connectivity to local clients and routers.
	o Tunnel packets sent to foreign 6to4 addresses to the destination		o Tunnel packets sent to foreign 6to4 addresses to the destination
	6to4 router using IPv4.		6to4 router using IPv4.
	o Forward packets sent to locally configured 6to4 addresses to the		o Forward packets sent to locally configured 6to4 addresses to the
	6to4 network.		6to4 network.
	o Tunnel packets sent to non-6to4 addresses, to the configured/		o Tunnel packets sent to non-6to4 addresses, to the configured/
	closest-by-anycast 6to4 relay router.		closest-by-anycast 6to4 relay router.
	o Decapsulate directly received IPv4 packets from foreign 6to4		o Decapsulate directly received IPv4 packets from foreign 6to4
	addresses.		addresses.
	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 will also perform security checks on traffic that it		The 6to4 router should also perform security checks on traffic that
	will receive from other 6to4 relays, or 6to4 routers, or from within		it will receive from other 6to4 relays, or 6to4 routers, or from
	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 reserved IPv4
	addresses in tunnels, or the matching 6to4 prefixes.		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.		address does not match the 6to4 prefix. (Note that the
			pseudo-interface must pick the IPv4 address corresponding to the
			prefix when encapsulating, or else problems may ensue on e.g.,
			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.
	o Disallow traffic transmission to other 6to4 domains through 6to4		o Disallow traffic transmission to other 6to4 domains through 6to4
	relay router or via some third party 6to4 router.		relay router or via some third party 6to4 router. (To avoid
			transmission to the relay router, the pseudo-interface prefix
			length must be configured correctly to be /16. Further, to avoid
			the traffic being discarded, 6to4 source addresses must always
			correspond to the IPv4 address encapsulating the traffic.)
	o Discard traffic received from other 6to4 domains via a 6to4 relay		o Discard traffic received from other 6to4 domains via a 6to4 relay
	router.		router.
	o Discard traffic received for prefixes other than self 6to4		o Discard traffic received for prefixes other than your own 6to4
	prefix(es).		prefix(es).
	3.2 6to4 Relay Routers		3.2 6to4 Relay Routers
	The 6to4 relay router acts as a relay between all 6to4 domains and		The 6to4 relay router acts as a relay between all 6to4 domains and
	native IPv6 networks; more specifically:		native IPv6 networks; more specifically:
	o It advertises the reachability of the 2002::/16 prefix to native		o It advertises the reachability of the 2002::/16 prefix to native
	IPv6 routing, thus receiving traffic to all 6to4 addresses from		IPv6 routing, thus receiving traffic to all 6to4 addresses from
	closest native IPv6 nodes.		closest native IPv6 nodes.
	skipping to change at page 10, line 45		skipping to change at page 10, line 12
	thus receiving some tunneled traffic to native IPv6 nodes from		thus receiving some tunneled traffic to native IPv6 nodes from
	6to4 routers.		6to4 routers.
	o Decapsulate, and forward packets received from 6to4 addresses		o Decapsulate, and forward packets received from 6to4 addresses
	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 will 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 reserved IPv4
	addresses in tunnels, or the matching 6to4 prefixes.		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.		address does not match the 6to4 prefix. (Note that the
			pseudo-interface must pick the IPv4 address corresponding to the
			prefix when encapsulating, or else problems may ensue on e.g.,
			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. Note, this check might be		addresses and such should not be used.
	incorrect if 6to4 were to be used.
	o Discard traffic received from 6to4 routers with the destination as		o Discard traffic received from 6to4 routers with the destination as
	a 6to4 prefix.		a 6to4 prefix.
	4. Threat Analysis		4. Threat Analysis
	This section discusses attacks against the 6to4 network or attacks		This section discusses attacks against the 6to4 network or attacks
	that are caused by the 6to4 network. The threats are discussed in		that are caused by the 6to4 network. The threats are discussed in
	light of the 6to4 deployment models defined in the Section 2.		light of the 6to4 deployment models defined in the Section 2.
	skipping to change at page 12, line 27		skipping to change at page 11, line 44
	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 will a 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
	legerate 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.
	6to4 relays and routers are IPv4 nodes, and there is no way for any		6to4 relays and routers are IPv4 nodes, and there is no way for any
	6to4 router to confirm the identity of the IPv4 node from which it is		6to4 router to confirm the identity of the IPv4 node from which it is
	receiving traffic -- whether it is a legitimate 6to4 relay or some		receiving traffic -- whether it is a legitimate 6to4 relay or some
	other node. A 6to4 router has to process traffic from all IPv4		other node. A 6to4 router has to process traffic from all IPv4
	nodes. Malicious IPv4 nodes can exploit this property and attack		nodes. Malicious IPv4 nodes can exploit this property and attack
	nodes within the 6to4 network.		nodes within the 6to4 network.
	skipping to change at page 13, line 19		skipping to change at page 12, line 31
	Since the 6to4 router assumes all the other 6to4 routers, and 6to4		Since the 6to4 router assumes all the other 6to4 routers, and 6to4
	relays are "on-link" it is possible to attack the 6to4 router using		relays are "on-link" it is possible to attack the 6to4 router using
	ND messages from any node in the IPv4 network, unless a prior trust		ND messages from any node in the IPv4 network, unless a prior trust
	relationship has been established.		relationship has been established.
	The attacks are targeting the 6to4 pseudo-interface. As long as the		The attacks are targeting the 6to4 pseudo-interface. As long as the
	6to4 addresses are not used in the source or destination address, the		6to4 addresses are not used in the source or destination address, the
	security checks specified by 6to4 take no stance on these packets.		security checks specified by 6to4 take no stance on these packets.
	Typically these use link-local addresses.		Typically these use link-local addresses.
			For example, a possible attack could be a Route Advertisement or
			Neighor Advertisement message, crafted specifically to cause havoc;
			the addresses in such a packet could be like:
			src_v6 = fe80::2 (forged address)
			dst_v6 = fe80::1 (valid or invalid address)
			src_v4 = 8.0.0.1 (valid or forged address)
			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 [7]. 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.
	skipping to change at page 14, line 16		skipping to change at page 13, line 40
	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 [9], 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 with		The attacker - a malicious IPv4 or IPv6 node - can send packets which
	spoofed source address to a 6to4 node to accomplish a DoS attack.		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
			attack.
	The IPv6 and IPv4 addresses of the packets will be similar to:		The IPv6 and IPv4 addresses of the packets will be similar to:
	src_v6 = 2001:db8::1 (forged address)		src_v6 = 2001:db8::1 (forged address)
	dst_v6 = 2002:0900:0002::1 (valid address)		dst_v6 = 2002:0900:0002::1 (valid 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)
	For attacks launched from a native IPv6 node, the src_v4 will be the		For attacks launched from a native IPv6 node, the src_v4 will be the
	address of the relay through which the traffic will reach the 6to4		address of the relay through which the traffic will reach the 6to4
	skipping to change at page 18, line 27		skipping to change at page 18, line 4
	implemented, it's typically easier to attack directly than through		implemented, it's typically easier to attack directly than through
	reflection -- unless "traffic laundering" is an explicit goal in the		reflection -- unless "traffic laundering" is an explicit goal in the
	attack. Therefore, this attack does not seem very serious.		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. This threat is		local broadcast address, or a multicast address.
	mentioned in the specification [1].
			This threat is described in the specification [1], and implementing
			the checks eliminates this threat. However, as this has not been
			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
	address, or when someone is able to do that remotely.		address, or when someone is able to do that remotely.
	In the first option, assume that 9.0.0.255 is the 6to4 router's		In the first option, assume that 9.0.0.255 is the 6to4 router's
	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
	skipping to change at page 20, line 5		skipping to change at page 19, line 33
	This section describes attacks against native IPv6 Internet which		This section describes attacks against native IPv6 Internet which
	leverage 6to4 architecture somehow. Attacks against 6to4 nodes were		leverage 6to4 architecture somehow. Attacks against 6to4 nodes were
	described in the previous section.		described in the previous section.
	Native IPv6 nodes can be accessed by 6to4 and IPv4 nodes through the		Native IPv6 nodes can be accessed by 6to4 and IPv4 nodes through the
	6to4 relay routers. Thus the 6to4 relays play a crucial role in any		6to4 relay routers. Thus the 6to4 relays play a crucial role in any
	attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.		attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.
	6to4 relays have only one significant security check they must		6to4 relays have only one significant security check they must
	perform for general safety: when decapsulating IPv4 packets, check		perform for general safety: when decapsulating IPv4 packets, check
	that 2002:V4ADDR::/48 and V4ADDR match. If this is not done, several		that 2002:V4ADDR::/48 and V4ADDR match in the source address. If
	threats become more serious; in the following analysis, it is assumed		this is not done, several threats become more serious; in the
	that such checks are implemented.		following analysis, it is assumed that such checks are implemented.
	6to4 relay should not relay packets between 6to4 addresses. In		6to4 relay should not relay packets between 6to4 addresses. In
	particular, packets decapsulated from 6to4 routers should not be		particular, packets decapsulated from 6to4 routers should not be
	encapsulated again towards 6to4 routers, as described in rules in		encapsulated again towards 6to4 routers, as described in rules in
	Section 5. Similarly, packets with 6to4 source and destination		Section 5. Similarly, packets with 6to4 source and destination
	address sent from IPv6 nodes should not be relayed. It is not clear		address sent from IPv6 nodes should not be relayed. It is not clear
	whether this kind of check is typically implemented. The attacks		whether this kind of check is typically implemented. The attacks
	described below assume that such checks are not implemented.		described below assume that such checks are not implemented.
	4.2.1 Attacks with ND Messages		4.2.1 Attacks with ND Messages
	skipping to change at page 27, line 5		skipping to change at page 26, line 35
	Attacks initiated by IPv4 nodes that send spoofed traffic that will		Attacks initiated by IPv4 nodes that send spoofed traffic that will
	not utilize the 6to4 infrastructure are considered out of scope of		not utilize the 6to4 infrastructure are considered out of scope of
	this document. 6to4 infrastructure may be utilized in reflection		this document. 6to4 infrastructure may be utilized in reflection
	attacks that are initiated by IPv4 nodes.		attacks that are initiated by IPv4 nodes.
	It is difficult for these attacks to be effective as the traffic sent		It is difficult for these attacks to be effective as the traffic sent
	out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4		out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4
	nodes unless they have implemented some sort of IPv6-in-IPv4		nodes unless they have implemented some sort of IPv6-in-IPv4
	tunneling.		tunneling.
	Such attacks can easily be thwarted by implementing protocol-41
	filtering in IPv4 nodes or sites that do not implement IPv6 over IPv4
	tunneling. Such filters should not be made permanent, as they would
	act as a hurdle if IPv6 over IPv4 tunneling mechanisms were ever to
	be implemented by the IPv4 node or site.
	XXX: do these need to be spelled out, as in previous sections?		XXX: do these need to be spelled out, as in previous sections?
	4.4 Summary of the Attacks		4.4 Summary of the Attacks
	Columns:		Columns:
	o Section number. The section that describes the attack.		o Section number. The section that describes the attack.
	o Attack name.		o Attack name.
	skipping to change at page 28, line 28		skipping to change at page 27, line 51
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |		| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |		| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |		| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |		| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	Figure 8		Figure 9
	Summary of attacks on the native IPv6 internet:		Summary of attacks on the native IPv6 internet:
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| Sec | Attack name |Initiator| Victim | ToA | Fix |		| Sec | Attack name |Initiator| Victim | ToA | Fix |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |		| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |		| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |		| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |		| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |		| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.2.6 | Relay Operators ... | - | - | D | 1) |		| 4.2.6 | Relay Operators ... | - | - | D | 1) |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	Figure 9		Figure 10
	Notes:		Notes:
	1) This attack is a side-effect of the other attacks, and thus does		1) This attack is a side-effect of the other attacks, and thus does
	not have any Initiator, Victim, and Fix. It is a Denial of Service		not have any Initiator, Victim, and Fix. It is a Denial of Service
	attack not on the network but on the organization in-charge of the		attack not on the network but on the organization in-charge of the
	relay.		relay.
	Summary of attacks on IPv4 internet:		Summary of attacks on IPv4 internet:
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| Sec | Attack name |Initiator| Victim | ToA | Fix |		| Sec | Attack name |Initiator| Victim | ToA | Fix |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |		| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	| 4.3 | Reflection Attacks | * | I_4 | R | 6* |		| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
	+-------+----------------------+---------+----------+-----+-----+		+-------+----------------------+---------+----------+-----+-----+
	Figure 10		Figure 11
	5. Implementing Proper Security Checks in 6to4		5. Implementing Proper Security Checks in 6to4
	In this section, several ways to implement the security checks		In this section, several ways to implement the security checks
	required or implied by the specification [1] or augmented by this		required or implied by the specification [1] or augmented by this
	memo are described. These do not, in general, protect against the		memo are described. These do not, in general, protect against the
	majority of the threats listed above in the "Threat Analysis"		majority of the threats listed above in the "Threat Analysis"
	section. They're just prerequisites for a relatively safe and simple		section. They're just prerequisites for a relatively safe and simple
	6to4 implementation.		6to4 implementation.
	skipping to change at page 30, line 5		skipping to change at page 29, line 18
	interface is brought up, but at least in February 2004, no		interface is brought up, but at least in February 2004, no
	implementations were known to do that. Due to that, the checks are		implementations were known to do that. Due to that, the checks are
	described as one -- which works independent of whether the node is a		described as one -- which works independent of whether the node is a
	router or relay.		router or relay.
	5.1 Encapsulating IPv6 into IPv4		5.1 Encapsulating IPv6 into IPv4
	The checks described in this section are to be performed when		The checks described in this section are to be performed when
	encapsulating IPv6 into IPv4.		encapsulating IPv6 into IPv4.
			The encapsulation rules are mainly designed to keep one from
			"shooting yourself on the foot" -- for example, the source address
			check verifies that the packet will be acceptable to the
			decapsulator, or the sanity checks ensure that addresses derived from
			private addresses are not used (which would be equally unacceptable).
	src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below), else drop		src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below), else drop
	if prefix (src_v6) == 2002::/16		if prefix (src_v6) == 2002::/16
	ipv4 address embedded in src_v6 MUST match src_v4		ipv4 address embedded in src_v6 MUST match src_v4
	if prefix (dst_v6) == 2002::/16		else if prefix (dst_v6) == 2002::/16
	dst_v4 SHOULD NOT be assigned to the router		dst_v4 SHOULD NOT be assigned to the router
	fi
	else		else
	drop		drop
	/* we somehow got a native-native ipv6 packet */		/* we somehow got a native-native ipv6 packet */
	fi		fi
	accept		accept
	5.2 Decapsulating IPv4 into IPv6		5.2 Decapsulating IPv4 into IPv6
	The checks described in this section are to be performed when		The checks described in this section are to be performed when
	decapsulating IPv4 into IPv6. They will be performed in both the		decapsulating IPv4 into IPv6. They will be performed in both the
	skipping to change at page 33, line 28		skipping to change at page 33, line 7
	Configured tunneling [4] does not suffer from this as it is		Configured tunneling [4] does not suffer from this as it is
	point-to-point, and based on src_v6/dst_v6 pairs of both IPv4 and		point-to-point, and based on src_v6/dst_v6 pairs of both IPv4 and
	IPv6 addresses it can be deduced which logical tunnel interface is in		IPv6 addresses it can be deduced which logical tunnel interface is in
	the question.		the question.
	Solutions for this include 1) not using more than one automatic		Solutions for this include 1) not using more than one automatic
	tunneling mechanism in a node or 2) binding different mechanisms to		tunneling mechanism in a node or 2) binding different mechanisms to
	different IPv4 addresses.		different IPv4 addresses.
	6.2 Anyone Pretending to Be a 6to4 Relay		6.2 A Different Model for 6to4 Deployment
	Even though this was already discussed in Section 4.1.2, it bears		Even though this was already discussed in Section 4.1.2, it bears
	some additional elaboration as it was the only problem which cannot		some additional elaboration as it was the only problem which cannot
	be even partially solved.		be even partially solved using the current deployment model -- but
			there are some mitigation methods.
	That is, 6to4 routers receive traffic from non-6to4 ("native")		That is, 6to4 routers receive traffic from non-6to4 ("native")
	sources via 6to4 relays. 6to4 routers have no way of matching IPv4		sources via 6to4 relays. 6to4 routers have no way of matching IPv4
	source address of the relay with non-6to4 IPv6 address of the source.		source address of the relay with non-6to4 IPv6 address of the source.
	Consequently, anyone can spoof any non-6to4 IPv6 address he wants by		Consequently, anyone can spoof any non-6to4 IPv6 address he wants by
	sending traffic, encapsulated, directly to 6to4 routers.		sending traffic, encapsulated, directly to 6to4 routers.
	Two different models of thinking have been proposed to fix this
	problem if it is considered to be important:
	o Every 6to4 relay must participate in an eBGP multi-hop peering
	mesh (which can be hierarchical); it would be used to advertise
	more specific routes.
	o The 6to4 usage model would be turned upside-down, and the
	deployment of 6to4 would be have to be borne by native IPv6 users.
	These are described at a bit more length below.
	6.2.1 Limited Distribution of More Specific Routes
	If 6to4 prefixes more specific than 2002::/16 could be advertised,
	the traffic model between native to 6to4 and 6to4 to native could be
	changed so that only one 6to4 relay would always be used, most often
	the one closest to the 6to4 router.
	This model was rejected in the base specification, as IPv6 routing
	table was not to be polluted by 6to4 prefixes derived of IPv4
	prefixes.
	However, the problem could be avoided with some effort: creating a
	separate, possibly hierarchical based on IPv6 connections, peering
	mesh for 6to4 relay routers. This could be done by forming eBGP [5]
	multi-hop peerings between 6to4 relays, and advertising more specific
	routes (e.g., the same superblocks of IPv4 addresses one expects to
	service) to all the other routers.
	In that way, the global routing table would not be impacted at all.
	This seems to have at least three potential issues:
	1. Every 6to4 relay should be part of this (if one wants to have
	some extra safety that the addresses haven't been spoofed),
	2. The route from a native source takes the path to the first 6to4
	relay, and there (possibly through other Relays) to the last 6to4
	relay to tunnel the packet to the 6to4 router; this adds at least
	some latency, and
	3. The mechanism of redistributing IPv4 6to4 client addresses to
	other relays as 6to4 prefixes needs work.
	Of these, only the last requires more discussion. It could be argued
	that this advertising should either be manually configured once
	(i.e., relatively static prefixes, or generated from IPv4
	route-objects in RADB [16] or generated automatically (e.g., when a
	6to4 router first sends a "triggering" packet through the 6to4
	relay). Of course, this data could even be derived in some form from
	the IPv4 routing tables. Further analysis on this is TBD if
	necessary.
	Even if the traffic to 6to4 routers is limited to few relays, other
	IPv4 nodes can still spoof both IPv4, and IPv6 address and perform
	the spoofing attack. Hence, a necessary step is to use strong
	cryptography-based mechanisms to ensure the 6to4 router - 6to4 relay
	relationship. Alternatively, some sort of infrastructure (e.g.,
	small-scale PKI) would have to be established which would have to
	include all the possible 6to4 relays in the Internet.
	6.2.2 A Different Model for 6to4 Deployment
	It could be possible to turn the deployment assumptions of 6to4		It could be possible to turn the deployment assumptions of 6to4
	around a bit to eliminate some threats caused by untrusted 6to4		around a bit to eliminate some threats caused by untrusted 6to4
	relays. That is:		relays. That is:
	o Every dual-stack site (or even ISP) would be required to have		o Every dual-stack site (or even ISP) would be required to have
	their own 6to4 relay. That is, there would not be third-party		their own 6to4 relay. (This assumes that IPv6-only is so long away
	relays, and the 2002::/16 route would not need to be advertised		that 6to4 would be hopefully retired at that point.) That is,
	globally, and		there would not be third-party relays, and the 2002::/16 route
			would not need to be advertised globally, and
	o The security implications of 6to4 use could be pushed back to the		o The security implications of 6to4 use could be pushed back to the
	level of trust inside the site or ISP (or their acceptable use		level of trust inside the site or ISP (or their acceptable use
	policies) -- this is something that the sites and ISP's should be		policies) -- this is something that the sites and ISP's should be
	familiar with already.		familiar with already.
	However, this has a number of problems:		However, this has a number of problems:
	This model would shift the majority of burden of supporting 6to4 to		This model would shift the majority of burden of supporting 6to4 to
	IPv6 sites which don't employ or use 6to4 at all, i.e., "those who		IPv6 sites which don't employ or use 6to4 at all, i.e., "those who
	skipping to change at page 36, line 24		skipping to change at page 34, line 39
	can be fixed by ensuring the correctness of implementations; this is		can be fixed by ensuring the correctness of implementations; this is
	important. The third is also a very difficult problem, and		important. The third is also a very difficult problem, and
	impossible to solve completely -- therefore it is important to be		impossible to solve completely -- therefore it is important to be
	able to analyze whether this results in a significant increase of		able to analyze whether this results in a significant increase of
	threats. The fourth problem seems to have feasible solutions.		threats. The fourth problem seems to have feasible solutions.
	These are analyzed in detail in Threat Analysis, in Section 4.		These are analyzed in detail in Threat Analysis, in Section 4.
	8. Acknowledgments		8. Acknowledgments
	Some issues were first brought up by Itojun Hagino in [17], and Alain		Some issues were first brought up by Itojun Hagino in [16], 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
	reminded of relay spoofing problems. Brian Carpenter reminded of the		reminded of relay spoofing problems. Brian Carpenter reminded of the
	BGP-based 6to4 router model. Christian Huitema gave a push to a more		BGP-based 6to4 router model. Christian Huitema gave a push to a more
	complete threat analysis. Itojun Hagino spelled out the operators'		complete threat analysis. Itojun Hagino spelled out the operators'
	fears about 6to4 relay abuse. Rob Austein brought up the idea of a		fears about 6to4 relay abuse. Rob Austein brought up the idea of a
	different 6to4 deployment model.		different 6to4 deployment model.
	In the latter phase, especially discussions with Christian Huitema,		In the latter phase, especially discussions with Christian Huitema,
	Brian Carpenter and Alain Durand were helpful when improving the		Brian Carpenter and Alain Durand were helpful when improving the
	document.		document.
	David Malone and [your name could be here] gave feedback on the		David Malone and Iljitsch van Beijnum gave feedback on the document.
	document.
	Normative References		Normative References
	[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4		[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
	Clouds", RFC 3056, February 2001.		Clouds", RFC 3056, February 2001.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	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
	skipping to change at page 37, line 27		skipping to change at page 35, line 40
	RFC 1771, March 1995.		RFC 1771, March 1995.
	[6] Draves, R., "Default Address Selection for Internet Protocol		[6] 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., "IPv6 Neighbor Discovery trust models and		[7] Nikander, P., "IPv6 Neighbor Discovery trust models and
	threats", draft-ietf-send-psreq-04 (work in progress), October		threats", draft-ietf-send-psreq-04 (work in progress), October
	2003.		2003.
	[8] Arkko, J., "SEcure Neighbor Discovery (SEND)",		[8] Arkko, J., "SEcure Neighbor Discovery (SEND)",
	draft-ietf-send-ndopt-03 (work in progress), January 2004.		draft-ietf-send-ndopt-04 (work in progress), February 2004.
	[9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for		[9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
	IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in		IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in
	progress), February 2004.		progress), February 2004.
	[10] Savola, P., "Security of IPv6 Routing Header and Home Address		[10] 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:		[11] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	skipping to change at page 37, line 50		skipping to change at page 36, line 15
	[12] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback		[12] 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,		[13] 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		[14] 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-18 (work in progress), February 2004.		draft-ietf-ngtrans-isatap-20 (work in progress), February 2004.
	[15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.		[15] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
	[16] Merit Network Inc., "Routing Assets Database (http://		[16] Hagino, J., "Possible abuse against IPv6 transition
	www.radb.net)".
	[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.
	[18] Barros, C., "Proposal for ICMP Traceback Messages", http://		[17] Barros, C., "Proposal for ICMP Traceback Messages", http://
	www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html .		www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html .
			[18] Merit Network Inc., "Routing Assets Database (http://
			www.radb.net)".
	Authors' Addresses		Authors' Addresses
	Pekka Savola		Pekka Savola
	CSC/FUNET		CSC/FUNET
	Espoo		Espoo
	Finland		Finland
	EMail: psavola@funet.fi		EMail: psavola@funet.fi
	Chirayu Patel		Chirayu Patel
	skipping to change at page 39, line 43		skipping to change at page 38, line 12
	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 -01 to -02
			1. Incorporate Iljitsch's feedback
			2. Clean up section 6.2
			3. Fix encapsulation code (had been munged in -01)
	Changes from -00 to -01		Changes from -00 to -01
	1. Lots of editorial changes in other sections		1. Lots of editorial changes in other sections
	2. Revamped the "Threat Analysis" section completely; ripple the		2. Revamped the "Threat Analysis" section completely; ripple the
	effects elsewhere in the document as well.		effects elsewhere in the document as well.
	3. Added Chirayu Patel as a co-author.		3. Added Chirayu Patel as a co-author.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the IETF's procedures with respect to rights in IETF Documents can
	standards-related documentation can be found in BCP-11. Copies of		be found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/