draft-ietf-dhc-topo-conf-08.txt		draft-ietf-dhc-topo-conf-09.txt
	Network Working Group T. Lemon		Network Working Group T. Lemon
	Internet-Draft Nominum, Inc.		Internet-Draft Nominum, Inc.
	Intended status: Informational T. Mrugalski		Intended status: Informational T. Mrugalski
	Expires: November 7, 2016 ISC		Expires: January 9, 2017 ISC
	May 6, 2016		July 8, 2016
	Customizing DHCP Configuration on the Basis of Network Topology		Customizing DHCP Configuration on the Basis of Network Topology
	draft-ietf-dhc-topo-conf-08		draft-ietf-dhc-topo-conf-09
	Abstract		Abstract
	DHCP servers have evolved over the years to provide significant		DHCP servers have evolved over the years to provide significant
	functionality beyond that which is described in the DHCP base		functionality beyond that which is described in the DHCP base
	specifications. One aspect of this functionality is support for		specifications. One aspect of this functionality is support for
	context-specific configuration information. This memo describes some		context-specific configuration information. This memo describes some
	such features and explains their operation.		such features and explains their operation.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 7, 2016.		This Internet-Draft will expire on January 9, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 21 ¶		skipping to change at page 2, line 21 ¶
	3. Identifying Client's Location by DHCP Servers . . . . . . . . 3		3. Identifying Client's Location by DHCP Servers . . . . . . . . 3
	3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 7		3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 7
	3.2. DHCPv6 Specific Behavior . . . . . . . . . . . . . . . . 7		3.2. DHCPv6 Specific Behavior . . . . . . . . . . . . . . . . 7
	4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 9		4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 9
	5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 11		5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 11
	6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 11		6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Regional Configuration Example . . . . . . . . . . . . . . . 12		7. Regional Configuration Example . . . . . . . . . . . . . . . 12
	8. Multiple subnets on the same link . . . . . . . . . . . . . . 14		8. Multiple subnets on the same link . . . . . . . . . . . . . . 14
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 15		10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	12.1. Normative References . . . . . . . . . . . . . . . . . . 16		12.1. Normative References . . . . . . . . . . . . . . . . . . 17
	12.2. Informative References . . . . . . . . . . . . . . . . . 16		12.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications		The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications
	describe how addresses can be allocated to clients based on network		describe how addresses can be allocated to clients based on network
	topology information provided by the DHCP relay infrastructure.		topology information provided by the DHCP relay infrastructure.
	Address allocation decisions are integral to the allocation of		Address allocation decisions are integral to the allocation of
	addresses and prefixes in DHCP.		addresses and prefixes in DHCP.
	The DHCP protocol also describes mechanisms for provisioning devices		The DHCP protocol also describes mechanisms for provisioning devices
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	DHCPv4 or DHCPv6 protocols and is implementation dependent.		DHCPv4 or DHCPv6 protocols and is implementation dependent.
	9. Acknowledgments		9. Acknowledgments
	Thanks to Dave Thaler for suggesting that even though "everybody		Thanks to Dave Thaler for suggesting that even though "everybody
	knows" how DHCP servers are deployed in the real world, it might be		knows" how DHCP servers are deployed in the real world, it might be
	worthwhile to have an IETF document that explains what everybody		worthwhile to have an IETF document that explains what everybody
	knows, because in reality not everybody is an expert in how DHCP		knows, because in reality not everybody is an expert in how DHCP
	servers are administered. Thanks to Andre Kostur, Carsten Strotmann,		servers are administered. Thanks to Andre Kostur, Carsten Strotmann,
	Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-		Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-
	Francois Tremblay, Marcin Siodelski and Bernie Volz for their		Francois Tremblay, Marcin Siodelski, Bernie Volz and Yaron Sheffer
	reviews, comments and feedback.		for their reviews, comments and feedback.
	10. Security Considerations		10. Security Considerations
	This document explains existing practice with respect to the use of		This document explains existing practice with respect to the use of
	Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host		Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host
	Configuration Protocol Version 6 [RFC3315]. The security		Configuration Protocol Version 6 [RFC3315]. The security
	considerations for these protocols are described in their		considerations for these protocols are described in their
	specifications and in related documents that extend these protocols.		specifications and in related documents that extend these protocols.
	This document introduces no new functionality, and hence no new
	security considerations.		The mechanisms described in this document could possibly be exploited
			by an attacker to misrepresent its point of attachment in the
			network. This would cause the server to assign addresses, prefixes
			and other configuration options, which can be considered a leak of
			information. In particular, this could be used a preliminary stage
			of an attack, when the DHCP server leaks information about available
			services in parts of the network the attacker does not have access
			to.
			There are several ways how such an attack can be prevented. First,
			it seems to be a common practice to filter out DHCP traffic coming in
			from outside of the network and one that is directed to clients
			outside of the network. Second, the DHCP servers can be configured
			to not respond to traffic that is coming from unknown (i.e. those
			subnets the server is not configured to serve) subnets. Third, some
			relays provide the ability to reject messages that do not fit
			expected characteristics. For example CMTS (Cable Modem Termination
			System) acting as a DHCP relay detects if the MAC address specified
			in chaddr in incoming DHCP messages matches the MAC address of the
			cable modem it came from and can alter its behavior accordingly.
			Also, relay agents and servers that are connected to clients directly
			can reject traffic that looks as if it has passed a relay (this could
			indicate the client is attempting to spoof a relay, possibly to
			inject forged relay options).
			There are a number of general DHCP recommendations that should be
			considered in all DHCP deployments. While not strictly related to
			the mechanisms described in this document, they may be useful in
			certain deployment scenarios. [RFC7819] and [RFC7824] provide an
			analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If
			those are of concern, [RFC7844] offers mitigation steps.
			Current DHCPv4 and DHCPv6 standards lack strong cryptographic
			protection. There is an ongoing effort in DHC working group to
			address this. [I-D.ietf-dhc-sedhcpv6] attempts to provide mechanism
			for strong authentication and encryption between DHCPv6 clients and
			servers. [I-D.volz-dhc-relay-server-security] attempts to improve
			security of exchanges between DHCP relay agents and servers.
			Another possible attack vector is to set up a rogue DHCP server and
			provide clients with false information, either as a denial of service
			or to execute man in the middle type of attack. This can be
			mitigated by deplyoing DHCPv6-shield [RFC7610].
			Finally, there is an ongoing effort to update DHCPv6 specification,
			that is currently 13 years old. Sections 23 (Security
			Considerations) and 24 (Privacy Considerations) of
			[I-D.ietf-dhc-rfc3315bis] contain more recent analysis of the
			security and privacy considerations.
	11. IANA Considerations		11. IANA Considerations
	The IANA is hereby absolved of any requirement to take any action in		The IANA is hereby absolved of any requirement to take any action in
	relation to this document.		relation to this document.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, DOI 10.17487/RFC2131, March 1997,		RFC 2131, DOI 10.17487/RFC2131, March 1997,
	<http://www.rfc-editor.org/info/rfc2131>.		<http://www.rfc-editor.org/info/rfc2131>.
	[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	C., and M. Carney, "Dynamic Host Configuration Protocol		C., and M. Carney, "Dynamic Host Configuration Protocol
	for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July		for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
	2003, <http://www.rfc-editor.org/info/rfc3315>.		2003, <http://www.rfc-editor.org/info/rfc3315>.
	12.2. Informative References		12.2. Informative References
			[I-D.ietf-dhc-rfc3315bis]
			Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
			Richardson, M., Jiang, S., Lemon, T., and T. Winters,
			"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
			bis", draft-ietf-dhc-rfc3315bis-05 (work in progress),
			June 2016.
			[I-D.ietf-dhc-sedhcpv6]
			Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D.
			Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-12 (work
			in progress), April 2016.
			[I-D.volz-dhc-relay-server-security]
			Volz, B. and Y. Pal, "Security of Messages Exchanged
			Between Servers and Relay Agents", draft-volz-dhc-relay-
			server-security-01 (work in progress), June 2016.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<http://www.rfc-editor.org/info/rfc1034>.		<http://www.rfc-editor.org/info/rfc1034>.
	[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",		[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
	RFC 3011, DOI 10.17487/RFC3011, November 2000,		RFC 3011, DOI 10.17487/RFC3011, November 2000,
	<http://www.rfc-editor.org/info/rfc3011>.		<http://www.rfc-editor.org/info/rfc3011>.
	[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",		[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
	RFC 3046, DOI 10.17487/RFC3046, January 2001,		RFC 3046, DOI 10.17487/RFC3046, January 2001,
	skipping to change at page 17, line 14 ¶		skipping to change at page 18, line 33 ¶
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <http://www.rfc-editor.org/info/rfc7159>.		2014, <http://www.rfc-editor.org/info/rfc7159>.
	[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and		[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
	S. Krishnan, "Guidelines for Creating New DHCPv6 Options",		S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
	BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,		BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
	<http://www.rfc-editor.org/info/rfc7227>.		<http://www.rfc-editor.org/info/rfc7227>.
			[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
			Protecting against Rogue DHCPv6 Servers", BCP 199,
			RFC 7610, DOI 10.17487/RFC7610, August 2015,
			<http://www.rfc-editor.org/info/rfc7610>.
			[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
			Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
			April 2016, <http://www.rfc-editor.org/info/rfc7819>.
			[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
			Considerations for DHCPv6", RFC 7824,
			DOI 10.17487/RFC7824, May 2016,
			<http://www.rfc-editor.org/info/rfc7824>.
			[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
			Profiles for DHCP Clients", RFC 7844,
			DOI 10.17487/RFC7844, May 2016,
			<http://www.rfc-editor.org/info/rfc7844>.
	Authors' Addresses		Authors' Addresses
	Ted Lemon		Ted Lemon
	Nominum, Inc.		Nominum, Inc.
	2000 Seaport Blvd		2000 Seaport Blvd
	Redwood City, CA 94063		Redwood City, CA 94063
	USA		USA
	Phone: +1-650-381-6000		Phone: +1-650-381-6000
	Email: Ted.Lemon@nominum.com		Email: Ted.Lemon@nominum.com
End of changes. 8 change blocks.
	13 lines changed or deleted		97 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/