< draft-ietf-dhc-v4configuration-05.txt		draft-ietf-dhc-v4configuration-06.txt >
	DHC WG B. Rajtar		DHC WG B. Rajtar
	Internet-Draft Hrvatski Telekom		Internet-Draft Hrvatski Telekom
	Intended status: Informational I. Farrer		Intended status: Informational I. Farrer
	Expires: August 16, 2014 Deutsche Telekom AG		Expires: January 2, 2015 Deutsche Telekom AG
	February 12, 2014		July 01, 2014
	Provisioning IPv4 Configuration Over IPv6 Only Networks		Provisioning IPv4 Configuration Over IPv6 Only Networks
	draft-ietf-dhc-v4configuration-05		draft-ietf-dhc-v4configuration-06
	Abstract		Abstract
	As IPv6 becomes more widely adopted, some service providers are		As IPv6 becomes more widely adopted, some service providers are
	choosing to deploy IPv6 only networks without dual-stack		choosing to deploy IPv6 only networks without dual-stack
	functionality for IPv4. However, as access to IPv4 based services		functionality for IPv4. However, as access to IPv4 based services
	will continue to be a requirement for the foreseeable future, IPv4		will continue to be a requirement for the foreseeable future, IPv4
	over IPv6 mechanisms, such as softwire tunnels are being developed.		over IPv6 mechanisms, such as softwire tunnels are being developed.
	In order to provision end-user's hosts with the IPv4 configuration		In order to provision end-user's hosts with the IPv4 configuration
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 August 16, 2014.		This Internet-Draft will expire on January 2, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	capable link-layer, depending on the underlying IPv4 in IPv6		capable link-layer, depending on the underlying IPv4 in IPv6
	technology, network topology and DHCPv4 client capabilities. A		technology, network topology and DHCPv4 client capabilities. A
	functional description of how unmodified DHCPv4 can be used is		functional description of how unmodified DHCPv4 can be used is
	provided in Section 5. This approach is recommended for service		provided in Section 5. This approach is recommended for service
	providers whose network and clients can support this DHCPv4		providers whose network and clients can support this DHCPv4
	architecture.		architecture.
	For the most simple IPv4 provisioning case, where the client only		For the most simple IPv4 provisioning case, where the client only
	needs to receive a static IPv4 address assignment (with no dynamic		needs to receive a static IPv4 address assignment (with no dynamic
	address leasing or additional IPv4 configuration), a DHCPv6 based		address leasing or additional IPv4 configuration), a DHCPv6 based
	approach (e.g. [I-D.ietf-softwire-map-dhcp]) may provide a suitable		approach (e.g. [I-D.ietf-softwire-map-dhcp]) may provide a suitable
	solution.		solution.
	This document is concerned with more complex IPv4 configuration		This document is concerned with more complex IPv4 configuration
	scenarios, to bring IPv4 configuration over IPv6-only networks in		scenarios, to bring IPv4 configuration over IPv6-only networks in
	line with the functionality offered by DHCPv4 in IPv4 native		line with the functionality offered by DHCPv4 in IPv4 native
	networks. DHCPv4 options may also need to be conveyed to clients for		networks. DHCPv4 options may also need to be conveyed to clients for
	configuring IPv4 based services, e.g., SIP server addresses.		configuring IPv4 based services, e.g., SIP server addresses.
	Although IPv4-in-IPv6 softwire tunnel and translation clients are		Although IPv4-in-IPv6 softwire tunnel and translation clients are
	currently the only use-case for DHCP based configuration of IPv4		currently the only use-case for DHCP based configuration of IPv4
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	parameters over IPv6 only networks have been suggested:		parameters over IPv6 only networks have been suggested:
	1. Adapt DHCPv4 format messages to be transported over IPv6 as		1. Adapt DHCPv4 format messages to be transported over IPv6 as
	described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this		described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this
	is referred to as DHCPv4o6.		is referred to as DHCPv4o6.
	2. Extend DHCPv6 to support IPv4 address leasing and other DHCPv4		2. Extend DHCPv6 to support IPv4 address leasing and other DHCPv4
	options.		options.
	3. Use DHCPv6 for external IPv4 address and source port		3. Use DHCPv6 for external IPv4 address and source port
	configuration (e.g. [I-D.ietf-softwire-map-dhcp]. Use DHCPv4		configuration (e.g. [I-D.ietf-softwire-map-dhcp]. Use DHCPv4
	over IPv4 messages within an IPv6 softwire for configuring		over IPv4 messages within an IPv6 softwire for configuring
	additional parameters. This is referred to as DHCPv6 + Stateless		additional parameters. This is referred to as DHCPv6 + Stateless
	DHCPv4oSW.		DHCPv4oSW.
	4. Use DHCPv4 format messages, transporting them within a new DHCPv6		4. Use DHCPv4 format messages, transporting them within a new DHCPv6
	message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6].		message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6].
	This is referred to as DHCPv4oDHCPv6.		This is referred to as DHCPv4oDHCPv6.
	At the time of writing, working examples of the first two methods		At the time of writing, working examples of all but the third method
	have been developed and successfully tested in several different		have been developed and successfully tested in several different
	operators networks.		operators networks.
	The following sections provide describe each of the approaches in		The following sections describe each of the approaches in more
	more detail.		detail.
	1.2. DHCPv4o6 Based Provisioning - Functional Overview		1.2. DHCPv4o6 Based Provisioning - Functional Overview
	In order to receive IPv4 configuration parameters, IPv4-only clients		In order to receive IPv4 configuration parameters, IPv4-only clients
	initiate and exchange DHCPv4 messages with the DHCPv4 server. To		initiate and exchange DHCPv4 messages with the DHCPv4 server. To
	adapt this for an IPv6-only network, an existing DHCPv4 client		adapt this for an IPv6-only network, an existing DHCPv4 client
	implements a Host Client Relay Agent (HCRA) function, which takes		implements a Host Client Relay Agent (HCRA) function, which takes
	DHCPv4 messages and puts them into UDP and IPv6.		DHCPv4 messages and puts them into UDP and IPv6.
	As the mechanism involves unicast IPv6 based communications, the IPv6		As the mechanism involves unicast IPv6 based communications, the IPv6
	address of the server must be provisioned to the client. A DHCPv6		address of the server must be provisioned to the client. A DHCPv6
	option for provisioning clients with this address is described in		option for provisioning clients with this address is described in
	[I-D.mrugalski-softwire-dhcpv4-over-v6-option].		[I-D.mrugalski-softwire-dhcpv4-over-v6-option].
	The IPv6 Transport Server (TSV) provides an IPv6 interface to the		The IPv6 Transport Server (TSV) provides an IPv6 interface to the
	client. This interface may be implemented directly on the server and		client. This interface may be implemented directly on the server
	/or via an intermediary 'Transport Relay Agent' (TRA) device which		and/or via an intermediary 'Transport Relay Agent' (TRA) device which
	acts as the gateway between the IPv4 and IPv6 domains.		acts as the gateway between the IPv4 and IPv6 domains.
	For the dynamic allocation of IPv4 addresses, the DHCPv4 server		For the dynamic allocation of IPv4 addresses, the DHCPv4 server
	function needs to be extended to add DHCPv4o6 TSV capabilities, such		function needs to be extended to add DHCPv4o6 TSV capabilities, such
	as the storing the IPv6 address of DHCPv4o6 clients and implementing		as the storing the IPv6 address of DHCPv4o6 clients and implementing
	the CRA6ADDR option.		the CRA6ADDR option.
	This approach currently uses functional elements for ingress and		This approach currently uses functional elements for ingress and
	egress of the IPv6-only transport domain - the HCRA on the host and		egress of the IPv6-only transport domain - the HCRA on the host and
	the TRA or TSV on the server. As a result, this has sometimes been		the TRA or TSV on the server. As a result, this has sometimes been
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	the same manner as any other IPv4 based traffic. Broadcast based		the same manner as any other IPv4 based traffic. Broadcast based
	DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment)		DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment)
	can not be transported as some softwire mechanisms implement NBMA		can not be transported as some softwire mechanisms implement NBMA
	links, where broadcast isn't supported. Additionally, there is a		links, where broadcast isn't supported. Additionally, there is a
	more general issue with the use of fixed L4 ports in A+P [RFC6346]		more general issue with the use of fixed L4 ports in A+P [RFC6346]
	based approaches. Here, a single IPv4 address is shared among		based approaches. Here, a single IPv4 address is shared among
	multiple users, each using a unique set of ports for differentiation		multiple users, each using a unique set of ports for differentiation
	meaning that it is not possible for every client to be allocated a		meaning that it is not possible for every client to be allocated a
	fixed L4 within its unique port set.		fixed L4 within its unique port set.
	On receipt by the tunnel concentrator (e.g. MAP Border Router or a		On receipt by the tunnel concentrator (e.g. MAP Border Router or a
	Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the		Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the
	IPv6 packet and forwarded to the DHCPv4 server in the same way as any		IPv6 packet and forwarded to the DHCPv4 server in the same way as any
	other IPv4 forwarding plane packet is handled.		other IPv4 forwarding plane packet is handled.
	As the client is already configured with its external IPv4 address		As the client is already configured with its external IPv4 address
	and source ports (using DHCPv6 or a well-known IPv4 address for DS-		and source ports (using DHCPv6 or a well-known IPv4 address for DS-
	Lite clients), the messages exchanged between the DHCPv4 client and		Lite clients), the messages exchanged between the DHCPv4 client and
	server would be strictly DHCPINFORM/DHCPACK messages. These can be		server would be strictly DHCPINFORM/DHCPACK messages. These can be
	used for conveying additional DHCPv4 based options.		used for conveying additional DHCPv4 based options.
	skipping to change at page 7, line 45 ¶		skipping to change at page 7, line 45 ¶
	DHCPv4/UDP/IPv6		DHCPv4/UDP/IPv6
	1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview		1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview
	[I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes transporting DHCPv4		[I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes transporting DHCPv4
	messages within two new DHCPv6 messages types: DHCPV4-QUERY and		messages within two new DHCPv6 messages types: DHCPV4-QUERY and
	DHCPV4-RESPONSE. These new messages types must be implemented in		DHCPV4-RESPONSE. These new messages types must be implemented in
	both the DHCPv4oDHCPv6 client and server.		both the DHCPv4oDHCPv6 client and server.
	In this approach, the configuration of stateless IPv4 addresses and		In this approach, dynamic IPv4 addressing, and/or any additional IPv4
	source ports (if required) is carried out using DHCPv6 as described		configuration, is provided using DHCPv4 messages carried (without
	in section 1.3 above. Dynamic IPv4 addressing, and/or any additional		IPv4/UDP headers) within a new OPTION_DHCPV4_MSG DHCPv6 option.
	IPv4 configuration, is provided using DHCPv4 messages carried
	(without IPv4/UDP headers) within a new OPTION_DHCPV4_MSG DHCPv6
	option.
	OPTION_DHCPV4_MSG enables the client and server to send BOOTP/DHCPv4		OPTION_DHCPV4_MSG enables the client and server to send BOOTP/DHCPv4
	messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6		messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6
	server receives a DHCPv6 request containing OPTION_BOOT_MSG within a		server receives a DHCPv6 request containing OPTION_DHCPV4_MSG within
	DHCPV4-QUERY message, it passes it to the DHCPv4 server engine.		a DHCPV4-QUERY message, it passes it to the DHCPv4 server engine.
	Likewise, the DHCPv4 server place its DHCPv4 response in the payload		Likewise, the DHCPv4 server place its DHCPv4 response in the payload
	of OPTION_DHCPV4_MSG and puts this into a DHCPV4-RESPONSE message.		of OPTION_DHCPV4_MSG and puts this into a DHCPV4-RESPONSE message.
	DHCPv4 messages can be carried within DHCPv6 multicast messages,		DHCPv4 messages can be carried within DHCPv6 multicast messages,
	using the All_DHCP_Relay_Agents_and_Servers multicast address. These		using the All_DHCP_Relay_Agents_and_Servers multicast address. These
	can be relayed in exactly the same way as any other DHCPv6		can be relayed in exactly the same way as any other DHCPv6
	multicasted messages.		multicasted messages.
	Optionally, DHCPv6 relays could be updated so that they forward the		Optionally, DHCPv6 relays could be updated so that they forward the
	DHCPV4-QUERY message to a different destination address, allowing for		DHCPV4-QUERY message to a different destination address, allowing for
	skipping to change at page 13, line 26 ¶		skipping to change at page 13, line 23 ¶
	implementations and include them as new DHCPv6 message types. The		implementations and include them as new DHCPv6 message types. The
	main rationale for this is that it enables all of DHCPv4's existing		main rationale for this is that it enables all of DHCPv4's existing
	options to be migrated for use over IPv6 in a single step.		options to be migrated for use over IPv6 in a single step.
	Porting of all necessary DHCPv4 options to DHCPv6 would require		Porting of all necessary DHCPv4 options to DHCPv6 would require
	ongoing development work, re-implementing existing DHCPv4		ongoing development work, re-implementing existing DHCPv4
	functionality in DHCPv6. This will result in having legacy DHCPv4		functionality in DHCPv6. This will result in having legacy DHCPv4
	options in DHCPv6, which will no longer be useful once IPv4 is		options in DHCPv6, which will no longer be useful once IPv4 is
	completely abandoned.		completely abandoned.
	Therefore, the DHCPv6 approach is not suitable for delivering IPv4		Therefore, the DHCPv6 approach is not appropriate for delivering IPv4
	configuration parameters in an efficient, ongoing manner.		configuration parameters.
	The dynamic leasing of IPv4 addresses is fundamental to the efficient		The dynamic leasing of IPv4 addresses is fundamental to the efficient
	use of remaining IPv4 resources. This will become increasingly		use of remaining IPv4 resources. This will become increasingly
	important in the future, so a mechanism which supports this is		important in the future, so a mechanism which supports this is
	necessary. DHCPv6 + Stateless DHCPv4oSW does not provide this		necessary. DHCPv6 + Stateless DHCPv4oSW does not provide this
	function and so is not recommended.		function and so is not recommended.
	The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6		The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6
	functionality) for all deployment scenarios, even when DHCPv4		functionality) for all deployment scenarios, even when DHCPv4
	specific functionality (e.g. sending DHCPv4 options) is not required		specific functionality (e.g. sending DHCPv4 options) is not required
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	in Section 23 of [RFC3315].		in Section 23 of [RFC3315].
	7.3. DHCPv6+DHCPv4oSW		7.3. DHCPv6+DHCPv4oSW
	There is currently no document describing this mechanism, so no		There is currently no document describing this mechanism, so no
	security considerations have been documented.		security considerations have been documented.
	7.4. DHCPv4oDHCPv6		7.4. DHCPv4oDHCPv6
	Security considerations associated with this approach are described		Security considerations associated with this approach are described
	in Section 11 of [I-D.ietf-dhc-dhcpv4-over-dhcpv6].		in [I-D.ietf-dhc-dhcpv4-over-dhcpv6].
	8. Acknowledgements		8. Acknowledgements
	Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan, Bernie Volz and		Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan, Bernie Volz and
	Francis Dupont for their input and reviews.		Francis Dupont for their input and reviews.
	9. Informative References		9. Informative References
	[I-D.ietf-dhc-dhcpinform-clarify]		[I-D.ietf-dhc-dhcpinform-clarify]
	Hankins, D., "Dynamic Host Configuration Protocol		Hankins, D., "Dynamic Host Configuration Protocol
	DHCPINFORM Message Clarifications", draft-ietf-dhc-		DHCPINFORM Message Clarifications", draft-ietf-dhc-
	dhcpinform-clarify-06 (work in progress), October 2011.		dhcpinform-clarify-06 (work in progress), October 2011.
	[I-D.ietf-dhc-dhcpv4-over-dhcpv6]		[I-D.ietf-dhc-dhcpv4-over-dhcpv6]
	Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.		Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
	Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-		Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
	dhcpv4-over-dhcpv6-04 (work in progress), January 2014.		dhcpv4-over-dhcpv6-09 (work in progress), June 2014.
	[I-D.ietf-dhc-dhcpv4-over-ipv6]		[I-D.ietf-dhc-dhcpv4-over-ipv6]
	Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4		Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4
	over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08		over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-09
	(work in progress), October 2013.		(work in progress), April 2014.
	[I-D.ietf-softwire-lw4over6]		[I-D.ietf-softwire-lw4over6]
	Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and		Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
	I. Farrer, "Lightweight 4over6: An Extension to the DS-		I. Farrer, "Lightweight 4over6: An Extension to the DS-
	Lite Architecture", draft-ietf-softwire-lw4over6-06 (work		Lite Architecture", draft-ietf-softwire-lw4over6-10 (work
	in progress), February 2014.		in progress), June 2014.
			[I-D.ietf-softwire-map]
			Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
			Murakami, T., and T. Taylor, "Mapping of Address and Port
			with Encapsulation (MAP)", draft-ietf-softwire-map-10
			(work in progress), January 2014.
	[I-D.ietf-softwire-map-dhcp]		[I-D.ietf-softwire-map-dhcp]
	Mrugalski, T., Troan, O., Dec, W., Bao, C.,		Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
	leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options		W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng,
	for configuration of Softwire Address and Port Mapped		"DHCPv6 Options for configuration of Softwire Address and
	Clients", draft-ietf-softwire-map-dhcp-06 (work in		Port Mapped Clients", draft-ietf-softwire-map-dhcp-07
	progress), November 2013.		(work in progress), March 2014.
	[I-D.ietf-softwire-map-t]		[I-D.ietf-softwire-map-t]
	Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and		Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
	T. Murakami, "Mapping of Address and Port using		T. Murakami, "Mapping of Address and Port using
	Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work		Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work
	in progress), February 2014.		in progress), February 2014.
	[I-D.ietf-softwire-map]
	Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
	Murakami, T., and T. Taylor, "Mapping of Address and Port
	with Encapsulation (MAP)", draft-ietf-softwire-map-10
	(work in progress), January 2014.
	[I-D.mrugalski-softwire-dhcpv4-over-v6-option]		[I-D.mrugalski-softwire-dhcpv4-over-v6-option]
	Mrugalski, T. and P. Wu, "Dynamic Host Configuration		Mrugalski, T. and P. Wu, "Dynamic Host Configuration
	Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6		Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6
	Endpoint", draft-mrugalski-softwire-		Endpoint", draft-mrugalski-softwire-dhcpv4-over-
	dhcpv4-over-v6-option-01 (work in progress), September		v6-option-01 (work in progress), September 2012.
	2012.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, March 1997.		2131, March 1997.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,		[RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
	"DHCP Server Identifier Override Suboption", RFC 5107,		"DHCP Server Identifier Override Suboption", RFC 5107,
End of changes. 19 change blocks.
	42 lines changed or deleted		39 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/