< draft-huitema-v6ops-teredo-04.txt		draft-huitema-v6ops-teredo-05.txt >
	INTERNET DRAFT C. Huitema		INTERNET DRAFT C. Huitema
	<draft-huitema-v6ops-teredo-04.txt> Microsoft		<draft-huitema-v6ops-teredo-05.txt> Microsoft
	Expires July 17, 2005 January 17, 2005		Expires October 5, 2005 April 5, 2005
	Teredo: Tunneling IPv6 over UDP through NATs		Teredo: Tunneling IPv6 over UDP through NATs
	Status of this memo		Status of this memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		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		and any of which I become aware will be disclosed, in accordance
	with RFC 3668.		with RFC 3668.
	skipping to change at page 10, line ? ¶		skipping to change at page 10, line ? ¶
	2.8 Teredo bubble ................................................. 5		2.8 Teredo bubble ................................................. 5
	2.9 Teredo service port ........................................... 5		2.9 Teredo service port ........................................... 5
	2.10 Teredo server address ........................................ 6		2.10 Teredo server address ........................................ 6
	2.11 Teredo mapped address and Teredo mapped port ................. 6		2.11 Teredo mapped address and Teredo mapped port ................. 6
	2.12 Teredo IPv6 client prefix .................................... 6		2.12 Teredo IPv6 client prefix .................................... 6
	2.13 Teredo node identifier ....................................... 6		2.13 Teredo node identifier ....................................... 6
	2.14 Teredo IPv6 address .......................................... 6		2.14 Teredo IPv6 address .......................................... 6
	2.15 Teredo Refresh Interval ...................................... 6		2.15 Teredo Refresh Interval ...................................... 6
	2.16 Teredo secondary port ........................................ 6		2.16 Teredo secondary port ........................................ 6
	2.17 Teredo IPv4 Discovery Address ................................ 6		2.17 Teredo IPv4 Discovery Address ................................ 6
	3 Design goals, requirements, and model of operation .............. 6		3 Design goals, requirements, and model of operation .............. 7
	3.1 Hypotheses about NAT behavior ................................. 7		3.1 Hypotheses about NAT behavior ................................. 7
	3.2 IPv6 provider of last resort .................................. 8		3.2 IPv6 provider of last resort .................................. 8
	3.2.1 When to use Teredo? ......................................... 9		3.2.1 When to use Teredo? ......................................... 9
	3.2.2 Autonomous deployment ....................................... 9		3.2.2 Autonomous deployment ....................................... 9
	3.2.3 Minimal load on servers ..................................... 9		3.2.3 Minimal load on servers ..................................... 9
	3.2.4 Automatic sunset ............................................ 9		3.2.4 Automatic sunset ............................................ 9
	3.3 Operational Requirements ...................................... 10		3.3 Operational Requirements ...................................... 10
	3.3.1 Robustness requirement ...................................... 10		3.3.1 Robustness requirement ...................................... 10
	3.3.2 Minimal support cost ........................................ 10		3.3.2 Minimal support cost ........................................ 10
	3.3.3 Protection against denial of service attacks ................ 10		3.3.3 Protection against denial of service attacks ................ 10
	3.3.4 Protection against distributed denial of service attacks .... 10		3.3.4 Protection against distributed denial of service attacks .... 10
	3.3.5 Compatibility with ingress filtering ........................ 10		3.3.5 Compatibility with ingress filtering ........................ 10
	3.4 Model of operation ............................................ 10		3.4 Model of operation ............................................ 11
	4 Teredo Addresses ................................................ 12		4 Teredo Addresses ................................................ 12
	5 Specification of clients, servers and relays .................... 13		5 Specification of clients, servers and relays .................... 13
	5.1 Message formats ............................................... 13		5.1 Message formats ............................................... 13
	5.1.1 Teredo IPv6 packet encapsulation ............................ 13		5.1.1 Teredo IPv6 packet encapsulation ............................ 13
	5.1.2 Maximum Transmission Unit ................................... 15		5.1.2 Maximum Transmission Unit ................................... 15
	5.2 Teredo Client specification ................................... 16		5.2 Teredo Client specification ................................... 16
	5.2.1 Qualification procedure ..................................... 17		5.2.1 Qualification procedure ..................................... 17
	5.2.2 Secure qualification ........................................ 20		5.2.2 Secure qualification ........................................ 20
	5.2.3 Packet reception ............................................ 21		5.2.3 Packet reception ............................................ 21
	5.2.4 Packet transmission ......................................... 23		5.2.4 Packet transmission ......................................... 23
	skipping to change at page 10, line ? ¶		skipping to change at page 10, line ? ¶
	5.2.8 Optional local client discovery procedure ................... 27		5.2.8 Optional local client discovery procedure ................... 27
	5.2.9 Direct IPv6 connectivity test ............................... 28		5.2.9 Direct IPv6 connectivity test ............................... 28
	5.2.10 Working around symmetric NAT ............................... 29		5.2.10 Working around symmetric NAT ............................... 29
	Huitema [Page 2]		Huitema [Page 2]
	5.3 Teredo Server specification ................................... 29		5.3 Teredo Server specification ................................... 29
	5.3.1 Processing of Teredo IPv6 packets ........................... 30		5.3.1 Processing of Teredo IPv6 packets ........................... 30
	5.3.2 Processing of router solicitations .......................... 31		5.3.2 Processing of router solicitations .......................... 31
	5.4 Teredo Relay specification .................................... 32		5.4 Teredo Relay specification .................................... 32
	5.4.1 Transmission by relays to Teredo clients .................... 32		5.4.1 Transmission by relays to Teredo clients .................... 32
	5.4.2 Reception from Teredo clients ............................... 33		5.4.2 Reception from Teredo clients ............................... 34
	5.4.3 Difference between Teredo Relays and Teredo Servers ......... 34		5.4.3 Difference between Teredo Relays and Teredo Servers ......... 34
	5.5 Implementation of automatic sunset ............................ 34		5.5 Implementation of automatic sunset ............................ 35
	6 Further study, use of Teredo to implement a tunnel service ...... 35		6 Further study, use of Teredo to implement a tunnel service ...... 35
	7 Security Considerations ......................................... 36		7 Security Considerations ......................................... 36
	7.1 Opening a hole in the NAT ..................................... 36		7.1 Opening a hole in the NAT ..................................... 37
	7.2 Using the Teredo service for a man-in-the-middle attack ....... 37		7.2 Using the Teredo service for a man-in-the-middle attack ....... 37
	7.2.1 Attacker spoofing the Teredo Server ......................... 37		7.2.1 Attacker spoofing the Teredo Server ......................... 37
	7.2.2 Attacker spoofing a Teredo relay ............................ 38		7.2.2 Attacker spoofing a Teredo relay ............................ 39
	7.2.3 End-to-end security ......................................... 39		7.2.3 End-to-end security ......................................... 39
	7.3 Denial of the Teredo service .................................. 39		7.3 Denial of the Teredo service .................................. 40
	7.3.1 Denial of service by a rogue relay .......................... 39		7.3.1 Denial of service by a rogue relay .......................... 40
	7.3.2 Denial of service by server spoofing ........................ 40		7.3.2 Denial of service by server spoofing ........................ 40
	7.3.3 Denial of service by exceeding the number of peers .......... 40		7.3.3 Denial of service by exceeding the number of peers .......... 40
	7.3.4 Attacks against the local discovery procedure ............... 40		7.3.4 Attacks against the local discovery procedure ............... 40
	7.3.5 Attacking the Teredo servers and relays ..................... 40		7.3.5 Attacking the Teredo servers and relays ..................... 41
	7.4 Denial of service against non-Teredo nodes .................... 41		7.4 Denial of service against non-Teredo nodes .................... 41
	7.4.1 Laundering DoS attacks from IPv4 to IPv4 .................... 41		7.4.1 Laundering DoS attacks from IPv4 to IPv4 .................... 41
	7.4.2 DOS attacks from IPv4 to IPv6 ............................... 41		7.4.2 DOS attacks from IPv4 to IPv6 ............................... 42
	7.4.3 DOS attacks from IPv6 to IPv4 ............................... 42		7.4.3 DOS attacks from IPv6 to IPv4 ............................... 42
	8 IAB considerations .............................................. 43		8 IAB considerations .............................................. 44
	8.1 Problem Definition ............................................ 43		8.1 Problem Definition ............................................ 44
	8.2 Exit Strategy ................................................. 44		8.2 Exit Strategy ................................................. 44
	8.3 Brittleness Introduced by Teredo .............................. 45		8.3 Brittleness Introduced by Teredo .............................. 45
	8.4 Requirements for a Long Term Solution ......................... 46		8.4 Requirements for a Long Term Solution ......................... 47
	9 IANA Considerations ............................................. 47		9 IANA Considerations ............................................. 47
	10 Acknowledgements ............................................... 47		10 Acknowledgements ............................................... 47
	11 References ..................................................... 47		11 References ..................................................... 47
	12 Authors' Addresses ............................................. 49		12 Authors' Addresses ............................................. 49
	13 Intellectual Property Statement ................................ 49		13 Intellectual Property Statement ................................ 49
	14 Copyright ...................................................... 49		14 Copyright ...................................................... 50
	Huitema [Page 3]		Huitema [Page 3]
	1 Introduction		1 Introduction
	Classic tunneling methods envisaged for IPv6 transition operate by		Classic tunneling methods envisaged for IPv6 transition operate by
	sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal		sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal
	[RFC3056] proposes automatic discovery in this context. A problem		[RFC3056] proposes automatic discovery in this context. A problem
	with these methods is that they don't work when the IPv6 candidate		with these methods is that they don't work when the IPv6 candidate
	node is isolated behind a Network Address Translator (NAT) device:		node is isolated behind a Network Address Translator (NAT) device:
	NATs are typically not programmed to allow the transmission of		NATs are typically not programmed to allow the transmission of
	skipping to change at page 10, line ? ¶		skipping to change at page 10, line ? ¶
	2.9 Teredo service port		2.9 Teredo service port
	The port from which the Teredo client sends Teredo packets. This		The port from which the Teredo client sends Teredo packets. This
	port is attached to one of the client's IPv4 addresses. The IPv4		port is attached to one of the client's IPv4 addresses. The IPv4
	address may or may not be globally routable, as the client may be		address may or may not be globally routable, as the client may be
	located behind one or more NAT.		located behind one or more NAT.
	Huitema [Page 5]		Huitema [Page 5]
	2.10 Teredo server address		2.10 Teredo server address
	The IPv4 address of the Teredo server selected by a particular user.		The IPv4 address of the Teredo server selected by a particular
			client.
	2.11 Teredo mapped address and Teredo mapped port		2.11 Teredo mapped address and Teredo mapped port
	A global IPv4 address and a UDP port that results from the		A global IPv4 address and a UDP port that results from the
	translation of the IPv4 address and UDP port of a client's Teredo		translation of the IPv4 address and UDP port of a client's Teredo
	service port by one or more NATs. The client learns these values		service port by one or more NATs. The client learns these values
	through the Teredo protocol described in this memo.		through the Teredo protocol described in this memo.
	2.12 Teredo IPv6 client prefix		2.12 Teredo IPv6 client prefix
	A global scope IPv6 prefix composed of the Teredo IPv6 service		A global scope IPv6 prefix composed of the Teredo IPv6 service
	prefix and the Teredo server address.		prefix and the Teredo server address.
	2.13 Teredo node identifier		2.13 Teredo node identifier
	A 64 bit identifier that contains the UDP port and IPv4 address at		A 64 bit identifier that contains the UDP port and IPv4 address at
	which a client can be joined through the Teredo service, as well as		which a client can be reached through the Teredo service, as well
	a flag indicating the type of NAT through which the client accesses		as a flag indicating the type of NAT through which the client
	the IPv4 Internet.		accesses the IPv4 Internet.
	2.14 Teredo IPv6 address		2.14 Teredo IPv6 address
	A Teredo IPv6 address obtained by combining a Teredo IPv6 client		A Teredo IPv6 address obtained by combining a Teredo IPv6 client
	prefix and a Teredo node identifier.		prefix and a Teredo node identifier.
	2.15 Teredo Refresh Interval		2.15 Teredo Refresh Interval
	The interval during which a Teredo IPv6 Address is expected to		The interval during which a Teredo IPv6 Address is expected to
	remain valid in the absence of "refresh" traffic. For a client		remain valid in the absence of "refresh" traffic. For a client
	located behind a NAT, the interval depends on configuration		located behind a NAT, the interval depends on configuration
	parameters of the local NAT, or the combination of NATs in the path		parameters of the local NAT, or the combination of NATs in the path
	to the Teredo server. By default, clients assume an interval value		to the Teredo server. By default, clients assume an interval value
	of 30 seconds; a longer value may be determined by local tests, as		of 30 seconds; a longer value may be determined by local tests, as
	described in section 5.		described in section 5.
	2.16 Teredo secondary port		2.16 Teredo secondary port
	A UDP port used to determine the appropriate value of the refresh		A UDP port used to send or receive packets in order to determine the
	interval, but not used to carry any Teredo traffic.		appropriate value of the refresh interval, but not used to carry any
			Teredo traffic.
	2.17 Teredo IPv4 Discovery Address		2.17 Teredo IPv4 Discovery Address
	An IPv4 multicast address used to discover other Teredo clients on		An IPv4 multicast address used to discover other Teredo clients on
	the same IPv4 subnet. The value of this address is X.X.X.X.		the same IPv4 subnet. The value of this address is X.X.X.X.
	(TBD IANA; experiments use the value 224.0.0.252.)		(TBD IANA; experiments use the value 224.0.0.252.)
			Huitema [Page 6]
	3 Design goals, requirements, and model of operation		3 Design goals, requirements, and model of operation
	Huitema [Page 6]
	The proposed solution transports IPv6 packets as the payload of UDP		The proposed solution transports IPv6 packets as the payload of UDP
	packets. This is based on the observation that TCP and UDP are the		packets. This is based on the observation that TCP and UDP are the
	only protocols guaranteed to cross the majority of NAT devices.		only protocols guaranteed to cross the majority of NAT devices.
	Tunneling packets over TCP would be possible, but would result in a		Tunneling packets over TCP would be possible, but would result in a
	poor quality of service; encapsulation over UDP is a better choice.		poor quality of service; encapsulation over UDP is a better choice.
	The design of our solution is based on a set of hypotheses and		The design of our solution is based on a set of hypotheses and
	observations on the behavior of NATs, our desire to provide an "IPv6		observations on the behavior of NATs, our desire to provide an "IPv6
	provider of last resort", and a list of operational requirements. It		provider of last resort", and a list of operational requirements. It
	results in a model of operation in which the Teredo service is		results in a model of operation in which the Teredo service is
	enabled by a set of servers and relays.		enabled by a set of servers and relays.
	3.1 Hypotheses about NAT behavior		3.1 Hypotheses about NAT behavior
	NAT devices typically incorporate some support for UDP, in order to		NAT devices typically incorporate some support for UDP, in order to
	enable users in the natted domain to use UDP based applications. The		enable users in the natted domain to use UDP based applications. The
	NAT will typically allocate a "mapping" when it sees an UDP packet		NAT will typically allocate a "mapping" when it sees a UDP packet
	coming through for which there is not yet an existing mapping. The		coming through for which there is not yet an existing mapping. The
	handling of UDP "sessions" by NAT devices differs by two important		handling of UDP "sessions" by NAT devices differs by two important
	parameters, the type and the duration of the mappings.		parameters, the type and the duration of the mappings.
	The type of mappings is analyzed in [RFC3489], which distinguishes		The type of mappings is analyzed in [RFC3489], which distinguishes
	between "Cone NAT", "restricted cone NAT", "port restricted cone		between "Cone NAT", "restricted cone NAT", "port restricted cone
	NAT" and "symmetric NAT". The Teredo solution ensures connectivity		NAT" and "symmetric NAT". The Teredo solution ensures connectivity
	for clients located behind cone NATs, restricted cone NATs or port-		for clients located behind cone NATs, restricted cone NATs or port-
	restricted cone NATs.		restricted cone NATs.
	Packet transmission only takes places after an exchange of "bubbles"		Transmission of regular IPv6 packets only takes places after an
	between the parties. This exchange would often fail for clients		exchange of "bubbles" between the parties. This exchange would often
	behind symmetric NAT, because their peer cannot predict the UDP port		fail for clients behind symmetric NAT, because their peer cannot
	number that the NAT expect.		predict the UDP port number that the NAT expect.
	Clients located behind a symmetric NAT will only be able to use		Clients located behind a symmetric NAT will only be able to use
	Teredo if they can somehow program the NAT and reserve a Teredo		Teredo if they can somehow program the NAT and reserve a Teredo
	service port for each client, for example using the DMZ functions of		service port for each client, for example using the DMZ functions of
	the NAT. This is obviously an onerous requirement, at odds with the		the NAT. This is obviously an onerous requirement, at odds with the
	design goal of an automatic solution. However, measurement campaigns		design goal of an automatic solution. However, measurement campaigns
	and studies of documentations have shown that, at least in simple		and studies of documentations have shown that, at least in simple
	"unmanaged" networks, symmetric NATs are a small minority; moreover,		"unmanaged" networks, symmetric NATs are a small minority; moreover,
	it seems that new NAT models or firmware upgrades avoid the		it seems that new NAT models or firmware upgrades avoid the
	"symmetric" design.		"symmetric" design.
	Investigations on the performance of [RFC3489] have shown the		Investigations on the performance of [RFC3489] have shown the
	relative frequency of a particular NAT design, which we might call		relative frequency of a particular NAT design, which we might call
	"port conserving". In this design, the NAT tries to keep the same		"port conserving". In this design, the NAT tries to keep the same
	port number inside and outside, unless the "outside" port number is		port number inside and outside, unless the "outside" port number is
	already in use for another mapping with the same host. Port		already in use for another mapping with the same host. Port
	conserving NAT appear as "cone" or "restricted cone NAT" most of the		conserving NAT appear as "cone" or "restricted cone NAT" most of the
	time, but they will behave as "symmetric NAT" when multiple internal		time, but they will behave as "symmetric NAT" when multiple internal
	hosts use the same port number to communicate to the same server.		hosts use the same port number to communicate to the same server.
	The Teredo design minimizes the risk of encountering the "symmetric"
	behavior by asking multiple hosts located behind the same NAT to use
	Huitema [Page 7]		Huitema [Page 7]
			The Teredo design minimizes the risk of encountering the "symmetric"
			behavior by asking multiple hosts located behind the same NAT to use
	different Teredo service ports.		different Teredo service ports.
	Other investigation in the behavior of NAT also outlined the		Other investigation in the behavior of NAT also outlined the
	"probabilistic rewrite" behavior. Some brands of NAT will examine		"probabilistic rewrite" behavior. Some brands of NAT will examine
	all packets for "embedded addresses", IP addresses and port numbers		all packets for "embedded addresses", IP addresses and port numbers
	present in application payloads. They will systematically replace 32		present in application payloads. They will systematically replace 32
	bits value that match a local address by the corresponding mapped		bits value that match a local address by the corresponding mapped
	address. We had to include an "obfuscation" procedure in TCP to		address. The Teredo specification includes an "obfuscation"
	avoid this behavior.		procedure in order to avoid this behavior.
	Regardless of their types, UDP mappings are not kept forever. The		Regardless of their types, UDP mappings are not kept forever. The
	typical algorithm is to remove the mapping if no traffic is observed		typical algorithm is to remove the mapping if no traffic is observed
	on the specified port for a "lifetime" period. The Teredo client		on the specified port for a "lifetime" period. The Teredo client
	that wants to maintain a mapping open in the NAT will have to send		that wants to maintain a mapping open in the NAT will have to send
	some "keep alive" traffic before the lifetime expires. For that, it		some "keep alive" traffic before the lifetime expires. For that, it
	needs an estimate of the "lifetime" parameter used in the NAT. We		needs an estimate of the "lifetime" parameter used in the NAT. We
	observed that the implementation of lifetime control can vary in		observed that the implementation of lifetime control can vary in
	several ways.		several ways.
	skipping to change at page 10, line ? ¶		skipping to change at page 10, line ? ¶
	multiple NATs and clients "on the other side" of these NAT. They		multiple NATs and clients "on the other side" of these NAT. They
	will also ensure communication when clients are located in a single		will also ensure communication when clients are located in a single
	subnet behind the same NAT.		subnet behind the same NAT.
	The procedures do not make any hypothesis about the type of IPv4		The procedures do not make any hypothesis about the type of IPv4
	address used behind a NAT, and in particular do not assume that		address used behind a NAT, and in particular do not assume that
	these are private addresses defined in [RFC1918].		these are private addresses defined in [RFC1918].
	3.2 IPv6 provider of last resort		3.2 IPv6 provider of last resort
			Huitema [Page 8]
	Teredo is designed to provide an "IPv6 access of last resort" to		Teredo is designed to provide an "IPv6 access of last resort" to
	nodes that need IPv6 connectivity but cannot use any of the other		nodes that need IPv6 connectivity but cannot use any of the other
	Huitema [Page 8]
	IPv6 transition schemes. This design objective has several		IPv6 transition schemes. This design objective has several
	consequences on when to use Teredo, how to program clients, and what		consequences on when to use Teredo, how to program clients, and what
	to expect of servers. Another consequence is that we expect to see a		to expect of servers. Another consequence is that we expect to see a
	point in time at which the Teredo technology ceases to be used.		point in time at which the Teredo technology ceases to be used.
	3.2.1 When to use Teredo?		3.2.1 When to use Teredo?
	Teredo is designed to robustly enable IPv6 traffic through NATs, and		Teredo is designed to robustly enable IPv6 traffic through NATs, and
	the price of robustness is a reasonable amount of overhead, due to		the price of robustness is a reasonable amount of overhead, due to
	UDP encapsulation and transmission of bubbles. Nodes that want to		UDP encapsulation and transmission of bubbles. Nodes that want to
	skipping to change at page 10, line ? ¶		skipping to change at page 10, line ? ¶
	automatically, by using mechanisms such as IPv6 Stateless Address		automatically, by using mechanisms such as IPv6 Stateless Address
	Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A		Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A
	design objective is to configure the Teredo service as automatically		design objective is to configure the Teredo service as automatically
	as possible. In practice, it is however required that the client		as possible. In practice, it is however required that the client
	learn the IPv4 address of a server that is willing to serve them;		learn the IPv4 address of a server that is willing to serve them;
	some servers may also require some form of access control.		some servers may also require some form of access control.
	3.2.3 Minimal load on servers		3.2.3 Minimal load on servers
	During the peak of the transition, there will be a requirement to		During the peak of the transition, there will be a requirement to
	deploy a large number of servers throughout the Internet. Minimizing		deploy Teredo servers supporting a large number of Teredo clients.
	the load on the server is a good way to facilitate this deployment.		Minimizing the load on the server is a good way to facilitate this
	To achieve this goal, servers should be as stateless as possible,		deployment. To achieve this goal, servers should be as stateless as
	and they should also not be required to carry any more traffic than		possible, and they should also not be required to carry any more
	necessary. To achieve this objective, we require only that servers		traffic than necessary. To achieve this objective, we require only
	enable the packet exchange between clients, but we don't require		that servers enable the packet exchange between clients, but we
	servers to carry the actual data packets: these packets will have to		don't require servers to carry the actual data packets: these
	be exchanged directly between the Teredo clients, or through a		packets will have to be exchanged directly between the Teredo
	destination-selected relay for exchanges between Teredo clients and		clients, or through a destination-selected relay for exchanges
	other IPv6 clients.		between Teredo clients and other IPv6 clients.
	3.2.4 Automatic sunset		3.2.4 Automatic sunset
	Teredo is meant as a short-term solution to the specific problem of		Teredo is meant as a short-term solution to the specific problem of
	providing IPv6 service to nodes located behind a NAT. The problem is		providing IPv6 service to nodes located behind a NAT. The problem is
	expected to be resolved over time by transforming the "IPv4 NAT"		expected to be resolved over time by transforming the "IPv4 NAT"
	into an "IPv6 router". This can be done in one of two ways:		into an "IPv6 router". This can be done in one of two ways:
	upgrading the NAT to provide 6to4 functions, or upgrading the		upgrading the NAT to provide 6to4 functions, or upgrading the
	Internet connection used by the NAT to a native IPv6 service, and		Internet connection used by the NAT to a native IPv6 service, and
	then adding IPv6 router functionality in the NAT. In either case,		then adding IPv6 router functionality in the NAT. In either case,
	the former NAT can present itself as an IPv6 router to the systems
	behind it. These systems will start receiving the "router
	Huitema [Page 9]		Huitema [Page 9]
			the former NAT can present itself as an IPv6 router to the systems
			behind it. These systems will start receiving the "router
	advertisements"; they will notice that they have IPv6 connectivity,		advertisements"; they will notice that they have IPv6 connectivity,
	and will stop using Teredo.		and will stop using Teredo.
	3.3 Operational Requirements		3.3 Operational Requirements
	3.3.1 Robustness requirement		3.3.1 Robustness requirement
	The Teredo service is designed primarily for robustness: packets are		The Teredo service is designed primarily for robustness: packets are
	carried over UDP in order to cross as many NAT implementations as		carried over UDP in order to cross as many NAT implementations as
	possible. The servers are designed to be stateless, which means that		possible. The servers are designed to be stateless, which means that
	they can easily be replicated. We expect indeed to find many such		they can easily be replicated. We expect indeed to find many such
	servers replicated at multiple Internet locations.		servers replicated at multiple Internet locations.
	3.3.2 Minimal support cost		3.3.2 Minimal support cost
	The service requires the support of servers and relays. In order to		The service requires the support of Teredo servers and Teredo
	facilitate the deployment of these servers, the Teredo procedures		relays. In order to facilitate the deployment of these servers and
	are designed to minimize the fraction of traffic that has to be		relays, the Teredo procedures are designed to minimize the amount of
	routed through the servers.		coordination required between servers and relays.
	Meeting this objective implies that the Teredo addresses will		Meeting this objective implies that the Teredo addresses will
	incorporate the IPv4 address and UDP port through which a Teredo		incorporate the IPv4 address and UDP port through which a Teredo
	client can be reached. This creates an implicit limit on the		client can be reached. This creates an implicit limit on the
	stability of the Teredo addresses, which can only remain valid as		stability of the Teredo addresses, which can only remain valid as
	long as the underlying IPv4 address and UDP port remains valid.		long as the underlying IPv4 address and UDP port remains valid.
	3.3.3 Protection against denial of service attacks		3.3.3 Protection against denial of service attacks
	The Teredo clients obtain mapped addresses and ports from the Teredo		The Teredo clients obtain mapped addresses and ports from the Teredo
	servers. The service must be protected against denial of service		servers. The service must be protected against denial of service
	attacks in which a third party spoofs a Teredo server and sends		attacks in which a third party spoofs a Teredo server and sends
	improper information to the client.		improper information to the client.
	3.3.4 Protection against distributed denial of service attacks		3.3.4 Protection against distributed denial of service attacks
	Teredo servers will act as a relay for IPv6 packets. Improperly		Teredo relays will act as a relay for IPv6 packets. Improperly
	designed packet relays can be used by denial of service attackers to		designed packet relays can be used by denial of service attackers to
	hide their address, making the attack untraceable. The Teredo		hide their address, making the attack untraceable. The Teredo
	service must include adequate protection against such misuse.		service must include adequate protection against such misuse.
	3.3.5 Compatibility with ingress filtering		3.3.5 Compatibility with ingress filtering
	Routers may perform ingress filtering by checking that the source		Routers may perform ingress filtering by checking that the source
	address of the packets received on a given interface is		address of the packets received on a given interface is
	"legitimate", i.e. belongs to network prefixes from which traffic is		"legitimate", i.e. belongs to network prefixes from which traffic is
	expected at a network interface. Ingress filtering is a recommended		expected at a network interface. Ingress filtering is a recommended
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 6 ¶
	Routers may perform ingress filtering by checking that the source		Routers may perform ingress filtering by checking that the source
	address of the packets received on a given interface is		address of the packets received on a given interface is
	"legitimate", i.e. belongs to network prefixes from which traffic is		"legitimate", i.e. belongs to network prefixes from which traffic is
	expected at a network interface. Ingress filtering is a recommended		expected at a network interface. Ingress filtering is a recommended
	practice, as it thwarts the use of forged source IP addresses by		practice, as it thwarts the use of forged source IP addresses by
	malfeasant hackers, notably to cover their tracks during denial of		malfeasant hackers, notably to cover their tracks during denial of
	service attacks. The Teredo specification must not force networks to		service attacks. The Teredo specification must not force networks to
	disable ingress filtering.		disable ingress filtering.
	3.4 Model of operation		3.4 Model of operation
	The operation of Teredo involves four types of nodes: Teredo		The operation of Teredo involves four types of nodes: Teredo
	clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes.		clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes.
	Teredo clients start operation by interacting with a Teredo server,		Teredo clients start operation by interacting with a Teredo server,
	performing a "qualification procedure". During this procedure, the		performing a "qualification procedure". During this procedure, the
	client will discover whether it is behind a cone, restricted cone or		client will discover whether it is behind a cone, restricted cone or
	symmetric NAT. If the client is not located behind a symmetric NAT,		symmetric NAT. If the client is not located behind a symmetric NAT,
	the procedure will be successful and the client will configure a		the procedure will be successful and the client will configure a
	"Teredo address".		"Teredo address".
	The Teredo IPv6 address embeds the "mapped address and port" through		The Teredo IPv6 address embeds the "mapped address and port" through
	which the client can receive IPv4/UDP packets encapsulating IPv6		which the client can receive IPv4/UDP packets encapsulating IPv6
	packets. If the client is not located behind a cone NAT, packet		packets. If the client is not located behind a cone NAT,
	transmission must be preceded by an exchange of "bubbles" that will		transmission of regular IPv6 packets must be preceded by an exchange
	install a mapping in the NAT. This document specifies how the		of "bubbles" that will install a mapping in the NAT. This document
	bubbles can be exchanged between Teredo clients in order to enable		specifies how the bubbles can be exchanged between Teredo clients in
	transmission along a direct path.		order to enable transmission along a direct path.
	Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g.		Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g.
	native nodes or 6to4 nodes) through Teredo relays. Teredo relays		native nodes or 6to4 nodes) through Teredo relays. Teredo relays
	advertise reachability of the Teredo prefix to a certain subset of		advertise reachability of the Teredo prefix to a certain subset of
	the IPv6 Internet: a relay set up by an ISP will typically serve		the IPv6 Internet: a relay set up by an ISP will typically serve
	only the IPv6 customers of this ISP; a relay set-up for a site will		only the IPv6 customers of this ISP; a relay set-up for a site will
	only serve the IPv6 hosts of this site. Dual-stack hosts may		only serve the IPv6 hosts of this site. Dual-stack hosts may
	implement a "local relay", allowing them to communicate directly		implement a "local relay", allowing them to communicate directly
	with Teredo hosts by sending IPv6 packets over UDP and IPv4 without		with Teredo hosts by sending IPv6 packets over UDP and IPv4 without
	having to advertise a Teredo IPv6 address.		having to advertise a Teredo IPv6 address.
	Teredo clients have to discover the relay that is closest to each		Teredo clients have to discover the relay that is closest to each
	native IPv6 peer. In order to prevent spoofing, the Teredo clients		native IPv6 or 6to4 peer. They have to perform this discovery for
	perform a relay discovery procedure by sending an ICMP echo request		each native IPv6 or 6to4 peer with which they communicate. In order
	to the native host, through the Teredo server. The payload of the		to prevent spoofing, the Teredo clients perform a relay discovery
	echo request contains a large random number. The echo reply is		procedure by sending an ICMP echo request to the native host. This
	forwarded by the relay closest to the native or 6to4 peer, enabling		message is a regularly formatted IPv6 ICMP packet, which is
	the Teredo client to discover this relay. In order to prevent		encapsulated in UDP and sent by te client to its Teredo server; the
	spoofing, the Teredo client verifies that the payload of the echo		server decapsulates the IPv6 message and forwards it to the intended
	reply contains the proper random number.		IPv6 destination. The payload of the echo request contains a large
			random number. The echo reply is sent by the peer to the IPv6
			address of the client, and is forwarded through standard IPv6
			routing mechanisms. It will naturally reach the Teredo relay closest
			to the native or 6to4 peer, and will be forwarded by this relay
			using the Teredo mechanisms. The Teredo client will discover the
			IPv4 address and UDP port used by the relay to send the echo reply,
			and will send further IPv6 packets to the peer by encapsulating them
			in UDP packets sent to this IPv4 address and port. In order to
			prevent spoofing, the Teredo client verifies that the payload of the
			echo reply contains the proper random number.
	The procedures are designed so that the Teredo server only		The procedures are designed so that the Teredo server only
	participates in the qualification procedure and in the exchange of		participates in the qualification procedure and in the exchange of
	bubbles and ICMP echo requests. The Teredo server never carries		bubbles and ICMP echo requests. The Teredo server never carries
	actual data traffic. There are two rationales for this design:		actual data traffic. There are two rationales for this design:
	reduce the load on the server in order to enable scaling; and avoid		reduce the load on the server in order to enable scaling; and avoid
	privacy issues that could occur if a Teredo server kept copies of		privacy issues that could occur if a Teredo server kept copies of
	the client's data packets.		the client's data packets.
	4 Teredo Addresses		4 Teredo Addresses
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 10 ¶
	different server behavior during the qualification procedure, as		different server behavior during the qualification procedure, as
	specified in section 5.2.1, as well as different bubble processing		specified in section 5.2.1, as well as different bubble processing
	by clients and relays.		by clients and relays.
	- The bits indicated with "z" must be set to sent as zero and		- The bits indicated with "z" must be set to sent as zero and
	ignored on receipt.		ignored on receipt.
	There are thus two currently specified values of the Flags field:		There are thus two currently specified values of the Flags field:
	"0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the		"0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the
	cone bit is set to 1. (Further versions of this specification may		cone bit is set to 1. (Further versions of this specification may
	assign new values to the reserved bits.)		assign new values to the reserved bits.)
	In some cases, Teredo nodes use link-local addresses. These		In some cases, Teredo nodes use link-local addresses. These
	addresses contain a link local prefix (FE80::/64) and a 64 bit		addresses contain a link local prefix (FE80::/64) and a 64 bit
	identifier, constructed using the same format as presented above. A		identifier, constructed using the same format as presented above. A
	difference between link-local addresses and global addresses is that		difference between link-local addresses and global addresses is that
	the identifiers used in global addresses MUST include a global scope		the identifiers used in global addresses MUST include a global scope
	unicast IPv4 address, while the identifiers used in link-local		unicast IPv4 address, while the identifiers used in link-local
	addresses MAY include a private IPv4 address.		addresses MAY include a private IPv4 address.
	5 Specification of clients, servers and relays		5 Specification of clients, servers and relays
	The Teredo service is realized by having clients interact with		The Teredo service is realized by having clients interact with
	Teredo servers through the Teredo service protocol. The clients will		Teredo servers through the Teredo service protocol. The clients will
	also receive IPv6 packets through Teredo relays.		also receive IPv6 packets through Teredo relays. The client behavior
			is specified in section 5.2.
	The Teredo server is designed to be stateless. It waits for Teredo		The Teredo server is designed to be stateless. It waits for Teredo
	requests and for IPv6 packets on the Teredo UDP port; it processes		requests and for IPv6 packets on the Teredo UDP port; it processes
	the requests by sending a response to the appropriate address and		the requests by sending a response to the appropriate address and
	port; it forwards Teredo IPv6 packets to the appropriate IPv4		port; it forwards some Teredo IPv6 packets to the appropriate IPv4
	address and UDP port.		address and UDP port, or to native IPv6 peers of Teredo clients. The
			precise behavior of the server is specified in section 5.3.
	The Teredo relay advertises reachability of the Teredo service		The Teredo relay advertises reachability of the Teredo service
	prefix over IPv6. The scope of advertisement may be the entire		prefix over IPv6. The scope of advertisement may be the entire
	Internet, or a smaller subset such as an ISP network or an IPv6		Internet, or a smaller subset such as an ISP network or an IPv6
	site; it may even be as small as a single host in the case of "local		site; it may even be as small as a single host in the case of "local
	relays". The relay forwards Teredo IPv6 packets to the appropriate		relays". The relay forwards Teredo IPv6 packets to the appropriate
	IPv4 address and UDP port.		IPv4 address and UDP port. The relay behavior is specified in
			section 5.3.
	Teredo clients, servers and relays must implement the sunset		Teredo clients, servers and relays must implement the sunset
	procedure defined in section 5.5.		procedure defined in section 5.5.
	5.1 Message formats		5.1 Message formats
	5.1.1 Teredo IPv6 packet encapsulation		5.1.1 Teredo IPv6 packet encapsulation
	Teredo IPv6 packets are transmitted as UDP packets [RFC768] within		Teredo IPv6 packets are transmitted as UDP packets [RFC768] within
	IPv4 [RFC791]. The source and destination IP addresses and UDP		IPv4 [RFC791]. The source and destination IP addresses and UDP
	skipping to change at page 13, line 52 ¶		skipping to change at page 14, line 13 ¶
	with origin indication.		with origin indication.
	When simple encapsulation is used, the packet will have a simple		When simple encapsulation is used, the packet will have a simple
	format, in which the IPv6 packet is carried as the payload of a UDP		format, in which the IPv6 packet is carried as the payload of a UDP
	datagram:		datagram:
	+------+-----+-------------+		+------+-----+-------------+
	| IPv4 | UDP | IPv6 packet |		| IPv4 | UDP | IPv6 packet |
	+------+-----+-------------+		+------+-----+-------------+
	When relaying packets received from third parties, the server may		When relaying some packets received from third parties, the server
	insert an origin indication in the first bytes of the UDP payload:		may insert an origin indication in the first bytes of the UDP
			payload:
	+------+-----+-------------------+-------------+		+------+-----+-------------------+-------------+
	| IPv4 | UDP | Origin indication | IPv6 packet |		| IPv4 | UDP | Origin indication | IPv6 packet |
	+------+-----+-------------------+-------------+		+------+-----+-------------------+-------------+
	The origin indication encapsulation is an 8-octet element, with the		The origin indication encapsulation is an 8-octet element, with the
	following content:		following content:
	+--------+--------+-----------------+		+--------+--------+-----------------+
	| 0x00 | 0x00 | Origin port # |		| 0x00 | 0x00 | Origin port # |
	skipping to change at page 16, line 10 ¶		skipping to change at page 16, line 13 ¶
	to the minimum IPv6 MTU size of 1280 bytes [RFC2460].		to the minimum IPv6 MTU size of 1280 bytes [RFC2460].
	Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of		Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of
	the encapsulating IPv4 header.		the encapsulating IPv4 header.
	5.2 Teredo Client specification		5.2 Teredo Client specification
	Before using the Teredo service, the client must be configured with:		Before using the Teredo service, the client must be configured with:
	- the IPv4 address of a server.		- the IPv4 address of a server.
			- a secondary IPv4 address of that server.
	If secure discovery is required, the client must also be configured		If secure discovery is required, the client must also be configured
	with:		with:
	- a client identifier,		- a client identifier,
	- a secret value, shared with the server,		- a secret value, shared with the server,
	- an authentication algorithm, shared with the server.		- an authentication algorithm, shared with the server.
	A Teredo client expects to exchange IPv6 packets through an UDP		A Teredo client expects to exchange IPv6 packets through a UDP port,
	port, the Teredo service port. To avoid problems when operating		the Teredo service port. To avoid problems when operating behind a
	behind a "port conserving" NAT, different clients operating behind		"port conserving" NAT, different clients operating behind the same
	the same NAT should use different service port numbers. This can be		NAT should use different service port numbers. This can be achieved
	achieved through explicit configuration or, in the absence of		through explicit configuration or, in the absence of configuration,
	configuration, by picking the service port number at random.		by picking the service port number at random.
	The client will maintain the following variables that reflect the		The client will maintain the following variables that reflect the
	state of the Teredo service:		state of the Teredo service:
	- Teredo connectivity status,		- Teredo connectivity status,
	- Mapped address and port number associated with the Teredo service		- Mapped address and port number associated with the Teredo service
	port,		port,
	- Teredo IPv6 prefix associated with the Teredo service port,		- Teredo IPv6 prefix associated with the Teredo service port,
	- Teredo IPv6 address or addresses derived from the prefix,		- Teredo IPv6 address or addresses derived from the prefix,
	- Link local address,		- Link local address,
	skipping to change at page 19, line 47 ¶		skipping to change at page 19, line 47 ¶
	this is the case, the client learns the Teredo mapped address and		this is the case, the client learns the Teredo mapped address and
	Teredo mapped port from the origin indication. The IPv6 source		Teredo mapped port from the origin indication. The IPv6 source
	address of the Router Advertisement is a link-local server address		address of the Router Advertisement is a link-local server address
	of the Teredo server. (Responses that are not valid advertisements		of the Teredo server. (Responses that are not valid advertisements
	are simply discarded.)		are simply discarded.)
	If the client has received an RA with the "Cone" bit in the IPv6		If the client has received an RA with the "Cone" bit in the IPv6
	destination address set to 1, it is behind a cone NAT and is fully		destination address set to 1, it is behind a cone NAT and is fully
	qualified. If the RA is received with the Cone bit set to 0, the		qualified. If the RA is received with the Cone bit set to 0, the
	client does not know whether the local NAT is restricted or		client does not know whether the local NAT is restricted or
	symmetric. The client selects a secondary IPv4 server address, and		symmetric. The client selects the secondary IPv4 server address, and
	repeats the procedure, the cone bit remaining to the value zero. If		repeats the procedure, the cone bit remaining to the value zero. If
	the client does not receive a response, it detects that the service		the client does not receive a response, it detects that the service
	is not usable. If the client receives a response, it compares the		is not usable. If the client receives a response, it compares the
	mapped address and mapped port in this second response to the first		mapped address and mapped port in this second response to the first
	received values. If the values are different, the client detects a		received values. If the values are different, the client detects a
	symmetric NAT: it cannot use the Teredo service. If the values are		symmetric NAT: it cannot use the Teredo service. If the values are
	the same, the client detects a port-restricted or restricted cone		the same, the client detects a port-restricted or restricted cone
	NAT: the client is qualified to use the service. (Teredo operates		NAT: the client is qualified to use the service. (Teredo operates
	the same way for restricted and port-restricted NAT.)		the same way for restricted and port-restricted NAT.)
	skipping to change at page 24, line 43 ¶		skipping to change at page 24, line 43 ¶
	- the local addressing ranges 172.16.0.0/12,		- the local addressing ranges 172.16.0.0/12,
	- the local addressing ranges 192.168.0.0/16,		- the local addressing ranges 192.168.0.0/16,
	- the link local block 169.254.0.0/16,		- the link local block 169.254.0.0/16,
	- the block reserved for 6to4 anycast addresses 192.88.99.0/24,		- the block reserved for 6to4 anycast addresses 192.88.99.0/24,
	- the multicast address block 224.0.0.0/4,		- the multicast address block 224.0.0.0/4,
	- the "limited broadcast" destination address 255.255.255.255,		- the "limited broadcast" destination address 255.255.255.255,
	- the directed broadcast addresses corresponding to the subnets to		- the directed broadcast addresses corresponding to the subnets to
	which the host is attached.		which the host is attached.
	A list of special-use IPv4 addresses is provided in [RFC3330].		A list of special-use IPv4 addresses is provided in [RFC3330].
	5.2.5 Maintenance		For reliability reasons, clients MAY decide to ignore the value of
			the "cone" bit in the flag, skip the "case 4" test and always
			perform the "case 5", i.e. treat all Teredo peers as if they were
			located behind non-cone NAT. This will result in some increase in
			traffic, but may avoid reliability issues if the determination of
			the NAT status was for some reason erroneous. For the same reason,
			clients MAY also decide to always send a direct bubble in case 5,
			even if they do not believe that they are located behind a non-cone
			NAT.
			5.2.5 Maintenance
	The Teredo client must ensure that the mappings that it uses remain		The Teredo client must ensure that the mappings that it uses remain
	valid. It does so by checking that packets are regularly received		valid. It does so by checking that packets are regularly received
	from the Teredo server.		from the Teredo server.
	At regular intervals, the client MUST check the "date and time of		At regular intervals, the client MUST check the "date and time of
	the last interaction with the Teredo server", to ensure that at		the last interaction with the Teredo server", to ensure that at
	least one packet has been received in the last Randomized Teredo		least one packet has been received in the last Randomized Teredo
	Refresh Interval. If this is not the case, the client SHOULD send a		Refresh Interval. If this is not the case, the client SHOULD send a
	router solicitation message to the server, as specified in 5.2.1;		router solicitation message to the server, as specified in 5.2.1;
	the client should use the same value of the "cone" bit that resulted		the client should use the same value of the "cone" bit that resulted
	skipping to change at page 28, line 52 ¶		skipping to change at page 29, line 11 ¶
	spoofed by a malevolent party. Teredo hosts must make two decisions,		spoofed by a malevolent party. Teredo hosts must make two decisions,
	whether to accept the packet for local processing, and whether to		whether to accept the packet for local processing, and whether to
	transmit further packets to the IPv6 address through the newly		transmit further packets to the IPv6 address through the newly
	learned IPv4 address and UDP port. The basic rule is that the hosts		learned IPv4 address and UDP port. The basic rule is that the hosts
	should be generous in what they accept, and careful in what they		should be generous in what they accept, and careful in what they
	send. Refusing to accept packets due to spoofing concerns would		send. Refusing to accept packets due to spoofing concerns would
	compromise connectivity, and should only be done when there is a		compromise connectivity, and should only be done when there is a
	near certainty that the source address is spoofed; on the other		near certainty that the source address is spoofed; on the other
	hand, sending packets to the wrong address should be avoided.		hand, sending packets to the wrong address should be avoided.
	When the client wants to send a packet to an IPv6 node on the IPv6		When the client wants to send a packet to a native IPv6 node or a
	Internet, it should check whether a valid peer entry already exists		6to4 node, it should check whether a valid peer entry already exists
	for the IPv6 address of the destination. If this is not the case,		for the IPv6 address of the destination. If this is not the case,
	the client will pick a random number (a nonce) and format an ICMPv6		the client will pick a random number (a nonce) and format an ICMPv6
	Echo Request message whose source is the local Teredo address, whose		Echo Request message whose source is the local Teredo address, whose
	destination is the address of the IPv6 node, and whose Data field is		destination is the address of the IPv6 node, and whose Data field is
	set to the nonce. (It is recommended to use a random number at least		set to the nonce. (It is recommended to use a random number at least
	64 bit long.) The nonce value and the date at which the packet was		64 bit long.) The nonce value and the date at which the packet was
	sent will be documented in a provisional peer entry for the IPV6		sent will be documented in a provisional peer entry for the IPV6
	destination. The ICMPv6 packet will then be sent encapsulated in a		destination. The ICMPv6 packet will then be sent encapsulated in a
	UDP packet destined to the Teredo server IPv4 address, and to the		UDP packet destined to the Teredo server IPv4 address, and to the
	Teredo port. The rules of section 5.2.3 specify how the reply to		Teredo port. The rules of section 5.2.3 specify how the reply to
	skipping to change at page 29, line 55 ¶		skipping to change at page 30, line 14 ¶
	server is able to receive and transmit some packets using a		server is able to receive and transmit some packets using a
	different IPv4 address and a different port number.		different IPv4 address and a different port number.
	The Teredo server acts as an IPv6 router. As such, it will receive		The Teredo server acts as an IPv6 router. As such, it will receive
	Router Solicitation messages, to which it will respond with Router		Router Solicitation messages, to which it will respond with Router
	Advertisement messages as explained in section 5.3.2; it may also		Advertisement messages as explained in section 5.3.2; it may also
	receive other packets, for example ICMPv6 messages and Teredo		receive other packets, for example ICMPv6 messages and Teredo
	bubbles, which are processed according to the IPv6 specification.		bubbles, which are processed according to the IPv6 specification.
	By default, the routing functions of the Teredo server are limited.		By default, the routing functions of the Teredo server are limited.
	Teredo servers are expected to relay Teredo bubbles and ICMPv6		Teredo servers are expected to relay Teredo bubbles, ICMPv6 Echo
	messages, but they are not expected to relay other types of IPv6		requests and ICMPv6 Echo replies, but they are not expected to relay
	packets. Operators may however decide to combine the functions of		other types of IPv6 packets. Operators may however decide to combine
	"Teredo server" and "Teredo relay", as explained in section 5.4.		the functions of "Teredo server" and "Teredo relay", as explained in
			section 5.4.
	5.3.1 Processing of Teredo IPv6 packets		5.3.1 Processing of Teredo IPv6 packets
	Before processing the packet, the Teredo server MUST check the		Before processing the packet, the Teredo server MUST check the
	validity of the encapsulated IPv6 source address, the IPv4 source		validity of the encapsulated IPv6 source address, the IPv4 source
	address and the UDP source port:		address and the UDP source port:
	1) If the UDP content is not a well formed Teredo IPv6 packet, as		1) If the UDP content is not a well formed Teredo IPv6 packet, as
	defined in section 5.1.1, the packet MUST be silently discarded.		defined in section 5.1.1, the packet MUST be silently discarded.
	skipping to change at page 33, line 41 ¶		skipping to change at page 33, line 52 ¶
	such queues.		such queues.
	In cases 2 and 3, the Teredo relay should create a peer entry for		In cases 2 and 3, the Teredo relay should create a peer entry for
	the IPv6 address; the entry status is marked as trusted in case 2		the IPv6 address; the entry status is marked as trusted in case 2
	(cone NAT), not trusted in case 3. In case 3, if the Teredo relay		(cone NAT), not trusted in case 3. In case 3, if the Teredo relay
	happens to be located behind a non-cone NAT, it should also send a		happens to be located behind a non-cone NAT, it should also send a
	bubble directly to the mapped IPv4 address and mapped port number of		bubble directly to the mapped IPv4 address and mapped port number of
	the Teredo destination; this will "open the path" for the return		the Teredo destination; this will "open the path" for the return
	bubble from the Teredo client.		bubble from the Teredo client.
			For reliability reasons, relays MAY decide to ignore the value of
			the "cone" bit in the flag, and always perform the "case 3", i.e.
			treat all Teredo peers as if they were located behind non-cone NAT.
			This will result in some increase in traffic, but may avoid
			reliability issues if the determination of the NAT status was for
			some reason erroneous. For the same reason, relays MAY also decide
			to always send a direct bubble to the mapped IPv4 address and mapped
			port number of the Teredo destination, even if they do not believe
			that they are located behind a non-cone NAT.
	5.4.2 Reception from Teredo clients		5.4.2 Reception from Teredo clients
	The Teredo relay may receive packets from Teredo clients; the		The Teredo relay may receive packets from Teredo clients; the
	packets should normally only be sent by clients to which the relay		packets should normally only be sent by clients to which the relay
	previously transmitted packets, i.e. clients whose IPv6 address is		previously transmitted packets, i.e. clients whose IPv6 address is
	present in the list of peers. Relays, like clients, use the packet		present in the list of peers. Relays, like clients, use the packet
	reception procedure to maintain the date and time of the last		reception procedure to maintain the date and time of the last
	interaction with the Teredo server, and the "list of recent peers."		interaction with the Teredo server, and the "list of recent peers."
	When a UDP packet is received over the Teredo service port, the		When a UDP packet is received over the Teredo service port, the
	skipping to change at page 37, line 52 ¶		skipping to change at page 38, line 23 ¶
	some automated procedure for provisioning the shared secret and the		some automated procedure for provisioning the shared secret and the
	algorithm.)		algorithm.)
	If the shared secret contains sufficient entropy, the attacker would		If the shared secret contains sufficient entropy, the attacker would
	have to defeat the one-way function used to compute the		have to defeat the one-way function used to compute the
	authentication value. This specification suggests a default		authentication value. This specification suggests a default
	algorithm combining HMAC and MD5. If the protection afforded by MD5		algorithm combining HMAC and MD5. If the protection afforded by MD5
	was not deemed sufficient, clients and servers can be agree to use a		was not deemed sufficient, clients and servers can be agree to use a
	different algorithm, e.g. SHA1.		different algorithm, e.g. SHA1.
	Another way to defeat the protection afforded by the signature		Another way to defeat the protection afforded by the authentication
	procedure is to mount a complex attack, as follows:		procedure is to mount a complex attack, as follows:
	1) Client prepares router solicitation, including authentication		1) Client prepares router solicitation, including authentication
	encapsulation.		encapsulation.
	2) Attacker intercepts the solicitation, and somehow manages to		2) Attacker intercepts the solicitation, and somehow manages to
	prevent it from reaching the server, for example by mounting a short		prevent it from reaching the server, for example by mounting a short
	duration DoS attack against the server.		duration DoS attack against the server.
	3) Attacker replaces the source IPv4 address and source UDP port of		3) Attacker replaces the source IPv4 address and source UDP port of
End of changes. 47 change blocks.
	85 lines changed or deleted		123 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/