< draft-andrews-v6ops-6to4-router-option-01.txt		draft-andrews-v6ops-6to4-router-option-02.txt >
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Intended status: Standards Track May 9, 2011		Intended status: Standards Track May 10, 2011
	Expires: November 10, 2011		Expires: November 11, 2011
	6to4 DHCP Relay Router Option		6to4 DHCP Relay Router Option
	draft-andrews-v6ops-6to4-router-option-01		draft-andrews-v6ops-6to4-router-option-02
	Abstract		Abstract
	Provides a DHCP 6to4 Relay Router option.		Provides a DHCP 6to4 Relay Router option.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 10, 2011.		This Internet-Draft will expire on November 11, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 11 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
	2. 6to4 Relay Router Option . . . . . . . . . . . . . . . . . . . 3		2. 6to4 Relay Router Option . . . . . . . . . . . . . . . . . . . 3
	3. CPE Equipment . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. CPE Equipment . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Deployment Senarios . . . . . . . . . . . . . . . . . . . . . . 4		4. Comparision of 6to4RRO vs 192.88.99.1 . . . . . . . . . . . . . 4
	4.1. Enterprise Deployment . . . . . . . . . . . . . . . . . . . 4		5. Comparision of 6to4 and 6to4RRO to 6rd . . . . . . . . . . . . 4
	4.2. ISP Deployment . . . . . . . . . . . . . . . . . . . . . . 4		6. Deployment Senarios . . . . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		6.1. Enterprise Deployment . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		6.2. ISP Deployment . . . . . . . . . . . . . . . . . . . . . . 5
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
			9.2. Informative References . . . . . . . . . . . . . . . . . . 6
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	Using 6to4 [RFC3056] currently requires manual configuration of the		Using 6to4 [RFC3056] currently requires manual configuration of the
	relay router or the use of a anycast relay router [RFC3068]. The		relay router or the use of a anycast relay router [RFC3068]. The
	latter has a number of well known issues (add reference).		latter has a number of well known issues (add reference).
	This document attempts to address some of those issues by providing a		This document attempts to address some of those issues by providing a
	method for clients to discover the address of a 6to4 relay router.		method for clients to discover the address of a 6to4 relay router.
	It is expected that the 6to4 relay router will be managed and that it		It is expected that the 6to4 relay router will be managed and that it
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	6to4 will not work for returned lease address.		6to4 will not work for returned lease address.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TBD | 4 | relay router ~		| TBD | 4 | relay router ~
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	~ address |		~ address |
	+-------------------------------+		+-------------------------------+
	The presence of a 6to4RRO in a reply MUST NOT be used as a indication		The presence of a 6to4RRO option in the reply MUST NOT be used as a
	that the client should use 6to4. It is only a instruction to client		indication that the client should use 6to4. It is only a instruction
	of how it should do 6to4 if it is otherwise configured to use 6to4.		to the client of how it should do 6to4 if it is otherwise configured
			to use 6to4.
	3. CPE Equipment		3. CPE Equipment
	CPE equipment SHOULD be configured to request the 6to4RRO option if		CPE equipment SHOULD be configured to request the 6to4RRO option if
	6to4 has been enabled. If 0.0.0.0 is returned in response to the		6to4 has been enabled. If 0.0.0.0 is returned in response to the
	6to4RRO option the CPE SHOULD disable 6to4 and withdraw any		6to4RRO option the CPE SHOULD disable 6to4 and withdraw any
	advertised 6to4 prefixes.		advertised 6to4 prefixes.
	4. Deployment Senarios		The 6to4RRO SHOULD be requested even if a 6to4 relay router has been
			manually configured. This is done so that the CPE can see if 6to4
			needs to be disabled if it is moved between networks. Returned
			values other than 0.0.0.0 MAY be ignored.
	4.1. Enterprise Deployment		CPE equipement MAY have a configuration knob to disable requesting
			the 6to4RRO. This knob MUST default to OFF.
			4. Comparision of 6to4RRO vs 192.88.99.1
			Provides a way to distribute load independent of the routing table.
			Using a unicast adddress rather than a anycast address allows for
			reliable reassembly of the IPv4 encapsulating packet.
			Provides a way to supply 6to4 decapsulation service which is unlikely
			to leak to unexpected clients.
			5. Comparision of 6to4 and 6to4RRO to 6rd
			6rd [RFC5969] works well as a replacement for 6to4 when the ISP
			controls the CPE equipment and is willing to deploy 6rd border
			routers. 6rd does not work so well as a replacement if any these
			conditions are not met for logistical reasons and may require
			parallel deployment with 6to4 until the CPE equipement is updated.
			6rd requires active participation of the ISP. 6to4 does not.
			6rd does not provide a signal to tell the CPE/host not to use 6to4.
			The 6to4RRO can often be deployed without requiring additional vendor
			support with existing equipment.
			6to4RRO should not be seen as a reason to not support 6rd in CPE/
			hosts. 6to4RRO and 6rd have different deployment senarios.
			6. Deployment Senarios
			6.1. Enterprise Deployment
	To prevent accidental 6to4 tunnels a enterprise would set 6to4RRO to		To prevent accidental 6to4 tunnels a enterprise would set 6to4RRO to
	0.0.0.0. This is intended to turn off mobile clients that have		0.0.0.0. This is intended to turn off mobile clients that have
	accidently left 6to4 enabled when connecting to the enterpises		accidently left 6to4 enabled when connecting to the enterprises
	network.		network.
	4.2. ISP Deployment		6.2. ISP Deployment
	ISPs, with a IPv6 connection to the public Internet, would set		ISPs, with a IPv6 connection to the public Internet, would set
	6to4RRO to point to 6to4 relay routers run by the ISP. This will		6to4RRO to point to 6to4 relay routers run by the ISP. This will
	provide their customers with a managed 6to4 routers which are		provide their customers with a managed 6to4 routers which are
	topologically close to the client. If the ISP does not have IPv6		topologically close to the client. If the ISP does not have IPv6
	connectivity it SHOULD NOT set the 6to4RRO option unless it knows the		connectivity it SHOULD NOT set the 6to4RRO option unless it knows the
	addresses it it returning will not work with 6to4.		addresses it it returning will not work with 6to4.
	If the ISP is returning a IPv4 addresses which will be subject to		If the ISP is returning a IPv4 addresses which will be subject to
	network address translation, regardless of whether they have IPv6		network address translation, regardless of whether they have IPv6
	connectivity or not, it SHOULD set the returned 6to4RRO option to		connectivity or not, it SHOULD set the returned 6to4RRO option to
	0.0.0.0. This is intended stop clients using IPv4 addresses which		0.0.0.0. This is intended to stop clients using IPv4 addresses which
	will not work with 6to4.		will not work with 6to4.
	5. IANA Considerations		7. IANA Considerations
	IANA is requested to allocate a DHCP option code point.		IANA is requested to allocate a DHCP option code point.
	6. Security Considerations		8. Security Considerations
	A rogue DHCP server advertising this option can cause 6to4 traffic to		A rogue DHCP server advertising this option can cause 6to4 traffic to
	be redirected anywhere in the world.		be redirected anywhere in the world.
	Setting the returned address to 0.0.0.0 can be used to deny 6to4		Setting the returned address to 0.0.0.0 can be used to deny 6to4
	service when it would otherwise work.		service when it would otherwise work.
	7. Normative References		9. References
			9.1. Normative References
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	and E. Lear, "Address Allocation for Private Internets",		and E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains		[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
	via IPv4 Clouds", RFC 3056, February 2001.		via IPv4 Clouds", RFC 3056, February 2001.
	[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",		[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
	RFC 3068, June 2001.		RFC 3068, June 2001.
			9.2. Informative References
			[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
			Infrastructures (6rd) -- Protocol Specification",
			RFC 5969, August 2010.
	Author's Address		Author's Address
	Mark P. Andrews		Mark P. Andrews
	Internet Systems Consortium		Internet Systems Consortium
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	US		US
	Email: marka@isc.org		Email: marka@isc.org
End of changes. 14 change blocks.
	22 lines changed or deleted		71 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/