draft-ietf-dhc-mdhcp-02.txt		draft-ietf-dhc-mdhcp-03.txt
	Dynamic Host Configuration working group Baiju V. Patel,		Dynamic Host Configuration working group Baiju V. Patel,
	Internet Draft Intel Corp,		Internet Draft Intel Corp,
	Munil Shah		Munil Shah
	Microsoft Corp.		Microsoft Corp.
	September 16, 1997		November 20, 1997
	Multicast address allocation extensions to the		Multicast address allocation extensions to the
	Dynamic Host Configuration Protocol		Dynamic Host Configuration Protocol
	<draft-ietf-dhc-mdhcp-02.txt>
			<draft-ietf-dhc-mdhcp-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its Areas,
	and its Working Groups. Note that other groups may also distribute		and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet Drafts.
	Internet Drafts are draft documents valid for a maximum of six		Internet Drafts are draft documents valid for a maximum of six
	months. Internet Drafts may be updated, replaced, or obsoleted by		months. Internet Drafts may be updated, replaced, or obsoleted by
	skipping to change at line 45		skipping to change at line 47
	Abstract		Abstract
	The Dynamic Host Configuration Protocol (DHCP) provides a framework		The Dynamic Host Configuration Protocol (DHCP) provides a framework
	for passing configuration information to hosts on a TCP/IP network.		for passing configuration information to hosts on a TCP/IP network.
	The multicast extensions to DHCP add additional capability of		The multicast extensions to DHCP add additional capability of
	dynamic allocation of the multicast addresses and additional		dynamic allocation of the multicast addresses and additional
	configuration options.		configuration options.
	1. Introduction		1. Introduction
	The multicast extensions to DHCP (MDHCP) provide configuration
			The multicast extensions to DHCP (MDHCP) provide configuration
	parameters to the multicast applications. MDHCP is built on a		parameters to the multicast applications. MDHCP is built on a
	client-server model, where designated DHCP server allocate		client-server model, where designated DHCP server allocates
	multicast addresses and deliver parameters associated with the MDHCP 09/16/97		multicast addresses and delivers parameters associated with the
	address to dynamically configured hosts. Throughout the remainder		address to dynamically configured hosts. Throughout the remainder
			Patel and Shah 1
			MDHCP 11/20/97
	of this document, the term "server" refers to a host providing		of this document, the term "server" refers to a host providing
	multicast address(es) and parameters through DHCP, and the term		multicast address(es) and parameters through DHCP, and the term
	"client" refers to a host requesting multicast address(es) and		"client" refers to a host requesting multicast address(es) and
	parameters from a DHCP server. MDHCP server is used at times, to		parameters from a DHCP server. MDHCP server is used at times, to
	indicate a DHCP server capable of handling MDHCP extensions to the		indicate a DHCP server capable of handling MDHCP extensions to the
	DHCP protocol and the MDHCP client is used to indicate the MDHCP		DHCP protocol and the MDHCP client is used to indicate the MDHCP
	capable DHCP client. MDHCP is not a separate protocol, but is		capable DHCP client. MDHCP is not a separate protocol, but is
	simply extensions to the DHCP protocol.		simply an extension to the DHCP protocol.
	MDHCP supports two mechanisms for multicast address allocation. In
	"automatic allocation", MDHCP assigns a permanent multicast address
	to a client. In "dynamic allocation", MDHCP assigns a multicast
	address to a client for a limited period of time (or until the
	client explicitly relinquishes the address). In "manual
	allocation", a client's IP address is assigned by the network
	administrator, and DHCP is used simply to convey the assigned
	address to the client. A particular network will use one or more
	of these mechanisms, depending on the policies of the network
	administrator.
	Like DHCP, MDHCP should be a mechanism rather than a policy. MDHCP		Like DHCP, MDHCP should be a mechanism rather than a policy. MDHCP
	must allow local system administrators control over configuration		must allow local system administrators control over configuration
	parameters where desired; e.g., local system administrators should		parameters where desired; e.g., local system administrators should
	be able to enforce local policies concerning allocation and access		be able to enforce local policies concerning allocation and access
	to local resources where desired.		to local resources where desired.
	The MDHCP client is not required to obtain IP address from a DHCP		The MDHCP client is not required to obtain IP address from a DHCP
	server in order to use MDHCP protocol.		server in order to use MDHCP protocol.
	skipping to change at line 97		skipping to change at line 88
	Throughout this document, the words that are used to define the		Throughout this document, the words that are used to define the
	significance of particular requirements are capitalized. These		significance of particular requirements are capitalized. These
	words are:		words are:
	o "MUST"		o "MUST"
	This word or the adjective "REQUIRED" means that the		This word or the adjective "REQUIRED" means that the
	item is an absolute requirement of this specification.		item is an absolute requirement of this specification.
	o "MUST NOT" MDHCP 09/16/97		o "MUST NOT"
	This phrase means that the item is an absolute prohibition		This phrase means that the item is an absolute prohibition
	of this specification.		of this specification.
	o "SHOULD"		o "SHOULD"
	This word or the adjective "RECOMMENDED" means that there		This word or the adjective "RECOMMENDED" means that there
	may exist valid reasons in particular circumstances to ignore		may exist valid reasons in particular circumstances to
	this item, but the full implications should be understood and		ignore this item, but the full implications should be
	the case carefully weighed before choosing a different course.		understood and the case carefully weighed before choosing a
			different course.
	o "SHOULD NOT"		o "SHOULD NOT"
	This phrase means that there may exist valid reasons in		This phrase means that there may exist valid reasons in
	particular circumstances when the listed behavior is acceptable		particular circumstances when the listed behavior is
	or even useful, but the full implications should be understood		acceptable or even useful, but the full implications should
	and the case carefully weighed before implementing any behavior
	described with this label.		Patel and Shah 2
			MDHCP 11/20/97
			be understood and the case carefully weighed before
			implementing any behavior described with this label.
	o "MAY"		o "MAY"
	This word or the adjective "OPTIONAL" means that this item is		This word or the adjective "OPTIONAL" means that this item
	truly optional. One vendor may choose to include the item		is truly optional. One vendor may choose to include the
	because a particular marketplace requires it or because it		item because a particular marketplace requires it or because
	enhances the product, for example; another vendor may omit the		it enhances the product, for example; another vendor may
	same item.		omit the same item.
	1.2. Terminology		1.2. Terminology
	This document uses the following terms[1]:		This document uses the following terms[1]:
	o "DHCP client"		o "DHCP client"
	A DHCP client is an Internet host using DHCP to obtain		A DHCP client is an Internet host that obtains configuration
	configuration parameters such as a network address.		parameters (e.g., network address) using DHCP protocol
	o "DHCP server"		o "DHCP server"
	A DHCP server is an Internet host that returns configuration		A DHCP server is an Internet host that provides
	parameters to DHCP clients.		configuration parameters to DHCP clients.
	o "MDHCP client"		o "MDHCP client"
	A MDHCP client is a DHCP client that supports MDHCP extensions.		A MDHCP client is a DHCP client that supports MDHCP
			extensions.
	o "MDHCP server" MDHCP 09/16/97
	A MDHCP server is a DHCP server that supports MDHCP extensions.
	o "BOOTP relay agent"
	A BOOTP relay agent or relay agent is an Internet host or
	router that passes DHCP messages between DHCP clients and DHCP
	servers. DHCP is designed to use the same relay agent behavior
	as specified in the BOOTP protocol specification.
	o "binding"		o "MDHCP server"
	A binding is a collection of configuration parameters,		A MDHCP server is a DHCP server that supports MDHCP
	including at least an IP address, associated with or "bound to"		extensions.
	a DHCP client. Bindings are managed by DHCP servers.
	1.3. Motivation and protocol requirements.		1.3. Motivation and protocol requirements.
	For multicast applications to be ubiquitous, there is a need to		For multicast applications to be ubiquitous, there is a need to
	standardize on a protocol to allocate multicast addresses to the		standardize on a protocol to allocate multicast addresses to an
	applications. Following are the set of requirements on such a		application. Following are the set of requirements on such a
	protocol.		protocol.
	Conflict Free Allocation: When two applications obtain a		Conflict Free Allocation: When two applications obtain a multicast
	multicast address (using a common multicast address allocation		address (using a common multicast address allocation protocol), both
			applications may be allocated identical addresses only if it can be
	protocol), both applications are allocated identical addresses		guaranteed that no hosts will receive multicasts using same address
	only if it can be guaranteed that no hosts will receive multicasts		from both the applications on the same network interface provided
	using same address from both the applications on the same network		that the multicast scoping is implemented correctly.
	interface provided that the multicast scoping is implemented
	correctly.
	Session protocol independence: The address allocation protocol
	should be independent of existing and future session control
	protocol. For example, it must be suitable for applications that
	use SAP (session announcement protocol) and SIP (session invitation
	protocol).
	Small response time: The application should not have to wait for a		Patel and Shah 3
	long time before it can be sure that it can use a multicast		MDHCP 11/20/97
	address. The response time should be function of network and
			Quick response: The application should not have to wait for a long
			time before it able to determine if it can use a multicast address.
			The response time should primarily be a function of network and
	system delays only and should not be in the order of several		system delays only and should not be in the order of several
	minutes.		minutes.
	Low network load: The multicast address allocation protocol is a		Low network load: The multicast address allocation protocol is a
	control protocol. It should be designed to impose minimal load on		control protocol. Therefore, it should impose minimal load on the
	the network. In particular, it should not require periodic		network. Specifically, the address allocation protocol should not
	broadcast/multicast messages from every application. Specifically, MDHCP 09/16/97		overload a modem line when used by a dial-in user.
	the address allocation protocol should not overload a modem line
	when used by a dial-in user.
	Work with power managed systems: The protocol should not require
	the client systems to be on all the time. It is perfectly
	acceptable that once the multicast address is allocated, the system
	may suspend or turn off for some time. The system may come back to
	full power just before the application starts multicasting
	traffic.
	Multicast address scopes: The protocol must be able to		Work with power managed systems: System may be in on, off or low
			power state between the address allocation and usage period.
	allocate both the administratively scoped addresses and global		Multicast address scopes: The protocol must be able to allocate both
	addresses.		the administratively scoped and global addresses.
	Efficient use of address space: The multicast address space is		Efficient use of address space: The multicast address space is
	smaller then IP address space. Moreover, a host or application may		smaller then IP address space. Moreover, a host or application may
	require multiple address. Therefore, efficient use of address space		require multiple addresses. Therefore, efficient use of address
	is a design goad of multicast address allocation protocol.		space is a design goal of multicast address allocation protocol.
	1.4. MHDCP Protocol Summary		1.4. MHDCP Protocol Summary
	From the client's point of view, MDHCP is an extension of the DHCP		From the protocol standpoint, MDHCP is an extension of the DHCP. As
	mechanisms. The MDHCP servers assigns multicast addresses to the		in normal DHCP protocol, a MDHCP client requests multicast
	hosts to be used within a specific scope, and valid for a specific		address(es) from the MDHCP server for a specified multicast scope.
			The MDHCP servers assigns multicast address(es) to the hosts to be
	period. A client may request multiple multicast addresses.		used within the requested scope, and valid over a specific period.
			The DHCP server MUST provide TTL value of the address. The client,
	The client requests a multicast address(es) to be used for a		when using the assigned address should not use the TTL value larger
	specific multicast scope available to it, and for a specific lease		than the one provided. The lease period is defined by the duration
	period. The MDHCP server would ideally assign the address from the		of the lease and the time at which the lease becomes effective. The
	requested scope or may allocate it for a different scope. However,		DHCP server MUST NOT allocate the same address to different clients
	if it allocates the address from a different scope, it will provide		with overlapping lease period and scope. The protocol also allows
			client to request more than one address at a time.
	this information as an option. The DHCP server MUST provide a TTL
	value. The multicast packets using the assigned address MUST NOT
	use a TTL value larger then the one provided. The lease period is
	defined by the duration of the lease and the time at which the lease
	becomes effective. Since the client may want to extend lease
	at a later time, the DHCP server SHOULD make every attempt at
	allocating an address which is not currently allocated to any other
	client. The DHCP server MUST NOT allocate the same addresses to
	different clients with overlapping lease period. The multicast
	scope list is one of the DHCP configuration parameters.
			Before requesting a multicast address, a client needs to obtain the
			list of multicast scopes available on the MDHCP server. The
			multicast scope-list is one of the MDHCP configuration parameters.
	The scope list may be obtained through the DHCP option described in		The scope list may be obtained through the DHCP option described in
	[3], or may be obtained with some other means. Similarly, the MDHCP		[3], or may be obtained by some other means. Similarly, the MDHCP
	server address (unicast or multicast) may also be obtained by the		server address (multicast) may also be obtained by the option
	option described in [3] or by some other means. MDHCP 09/16/97		described in [3] or can be configured on the client.
			The MDHCP server is not required to be co-located with a DHCP
			server. Therefore, in a typical deployment, there may be fewer MDHCP
			servers then the DHCP servers.
	The MDHCP protocol uses M flag and a set of options defined below.		The MDHCP protocol uses M flag and a set of options defined below.
			Patel and Shah 4
			MDHCP 11/20/97
	2. MDHCP messages and options.		2. MDHCP messages and options.
	The following options and flags are used by MDHCP extensions.		The following options and flags are used by MDHCP extensions.
	2.1. M flag		2.1. M flag
	A new flag (M) is defined to differentiate the MDHCP messages from		A new flag (M) is defined to differentiate the MDHCP messages from
	DHCP messages. All the messages (DHCPDISCOVER, DHCPOFFER etc.) use		DHCP messages. All the messages (DHCPDISCOVER, DHCPOFFER etc.) use
	M flag (this is a new flag) defined below to indicate multicast		M flag defined below to indicate multicast address negotiations. The
	address negotiations. The second bit of the flag field (bit 1)		second bit of the flag field (bit 1) defines M (multicast) flag.
	defines M (multicast) flag. The M bit must be set for all the		The M bit must be set for all the message exchanges pertinent to the
	message exchanges pertinent to the multicast address assignment.		multicast address assignment. The client MUST obtain an IP address
	The client MUST obtain an IP address prior to requesting a		prior to requesting a multicast address. Therefore, B flag MUST not
			be set when M flag is set.
	multicast address. Therefore, B flag MUST not be set when M flag is
	set.
	1 1 1 1 1 1		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|B|M| MBZ |		|B|M| MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	B: BROADCAST flag		B: BROADCAST flag
	M: Multicast address request flag.		M: Multicast address request flag.
	MBZ: MUST BE ZERO (reserved for future use)		MBZ: MUST BE ZERO (reserved for future use)
	2.2. Multicast Scope Option		2.2. Multicast Scope Option
	This option is used by the client to indicate the multicast scope		This option is used by the client to indicate the multicast scope
	for the requested multicast address. It is also used to indicate		for the requested multicast address(es). It is also used to indicate
	the scope of the assigned address by the DHCP server. If this		the scope of the assigned address by the DHCP server. If this option
			is not specified, the DHCP server MAY allocate an address from a
			DEFAULT scope or reject the request.
	option is not specified, the DHCP server MAY allocate an address		Code Len Scope Id
	from a DEFAULT scope or reject the request. MDHCP 09/16/97
	1 1 1 1 1 1		+-----+-----+-----+-----+-----+-----+
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| 101 | 4 | i1 | i2 | i3 | i4 |
	| code | length=4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Scope id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Scope id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The client may obtain the scope list through the option described in
			+-----+-----+-----+-----+-----+-----+
			The client may obtain the scope list through the option described in
	[3] or using some other means. The scope id is the numeric		[3] or using some other means. The scope id is the numeric
	representation of the scope as described in [3]. The 'code' for this		representation of the scope as described in [3]. The 'code' for this
	option is 101.		option is 101 and the length is 4.
			Patel and Shah 5
			MDHCP 11/20/97
	2.3. Start time Option		2.3. Start time Option
	The start time is used in a client request (DHCPDISCOVER or		The start time is used in a client request (DHCPDISCOVER or
	DHCPREQUEST) to allow the client to request the starting time for		DHCPREQUEST) to allow the client to request the starting time for
	the use of the assigned address. This option allows client to		the use of the assigned address. This option allows client to
	request a multicast address for use at a future time.		request a multicast address for use at a future time.
	1 1 1 1 1 1		Code Len Time
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
	| code | length=4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| t1 | t2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| t3 | t4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| t5 | t6 |		| 102 | 8 | t1 | t2 | t3 | t4 | t5 | t6 | t7 | t8 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| t7 | t8 |		+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The time value is the decimal representation of Network Time		The time value is the decimal representation of Network Time
	Protocol (NTP) time values in seconds [5].		Protocol (NTP) time values in seconds [5].
	The 'code' for this option is 102.		The 'code' for this option is 102 and the length is 8.
	If IP Address Lease Time option specifies the duration of the lease		If IP Address Lease Time option specifies [2] the duration of the
	beginning at Start Time option value. MDHCP 09/16/97		lease beginning at Start Time option value.
	2.4. Multicast TTL Option		2.4. Multicast TTL Option
	This option specifies the TTL value to be used with the multicast		This option specifies the TTL value to be used with the multicast
	address. The TTL is specified as an octet with a value between 1		address. The TTL is specified as an octet with a value between 1
	and 255.		and 255. The implied value of this option is 255 when not included.
	1 1 1 1 1 1		Code Len Multicast TTL
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| code | length=1 |		+-----+-----+-----+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TTL |
	+-+-+-+-+-+-+-+-+
	The 'code' for this option is 103.		| 103 | 1 | n |
	2.5. Client Port Option		+-----+-----+-----+
			The 'code' for this option is 103 and the length is 1.
			2.5. Number of Addresses Requested Option
			This option specifies the number of addresses requested by the
			client. The client MAY obtain more than one address either by
			repeating the protocol for every address or by requesting all the
			addresses at the same time via this option. The server MAY use this
			option to indicate to the client the number of addresses it has
			allocated to the client. When the client is requesting only one
			address, this option need not be included.
			Code Len Number of Addresses
			+-----+-----+-----+-----+
			| 104 | 2 | n |
			+-----+-----+-----+-----+
			The 'code' for this option is 104 and the length is 2.
			Patel and Shah 6
			MDHCP 11/20/97
			2.6. Client Port Option
	In order to facilitate implementations outside the operating system		In order to facilitate implementations outside the operating system
	kernel, and to allow two separate client implementations: one for		kernel, and to allow two separate client implementations: one for
	DHCP and one for MDHCP, if this option is specified, the MDHCP		DHCP and one for MDHCP, if this option is specified, the MDHCP server
	server MUST use the source port number used in the		MUST use the source port number used in the DHCPDISCOVER,
			DHCPREQUEST, DHCPINFORM, and DHCPRESEASE as the destination port
			number in the response messages.
	DHCPDISCOVER, DHCPREQUEST, DHCPINFORM, and DHCPRESEASE		Code Len Port
	as the destination port number in the response messages.
	0 1 2 3 4 5 6 7		+-----+-----+-----+
	+-+-+-+-+-+-+-+-+
	| code |
	+-+-+-+-+-+-+-+-+
	The 'code' for this option is 105.		| 105 | 1 | n |
			+-----+-----+-----+
			The 'code' for this option is 105 and the length is 1.
			2.7. List of Address Ranges Allocated
			This option is used by the server to provide the list of all the
			address ranges allocated to the client when client requests more than
			one addresses. When a client requests only one address, the server
			uses the ‘yiaddr’ field specify the allocated address. When a client
			requests more than one address, additional address ranges are listed
			via this option.
			Code Len Address Range List
			+-----+-----+-----+-----+-...-+-----+
			| 105 | n | L1 | L2 | | Ln |
			+-----+-----+-----+-----+-----+-----+
			Where the Address Range List is of the follwing format.
			StartAddress1 BlockSize1 StartAddress2 BlockSize2 ...
			+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
			|S11|S12|S13|S14|B11|B12|S21|S22|S23|S24|B21|B22| |
			+---+---+---+---+---+---+---+---+---+---+---+---+-------+
			The 'code' for this option is TBD and the minimum length is 6.
	3. MDHP protocol		3. MDHP protocol
	The client needs to obtain the IP address of the MDHCP server (this		The client first needs to know the group multicast address of the
	may be a unicast or a multicast address for MDHCP group), and the		MDHCP servers, and the multicast scope list. This address and the
	multicast scope list. This list may be obtained as part of the		scope list may be obtained by requesting the options specified in
	normal DHCP protocol using the options specified in [3] or by some		[3] from DHCP servers via DHCPINFORM or from other repository of
	other means.		network configurations.
	The client selects one of multicast scopes and requests multicast		At this point, client has two ways of obtaining the multicast
	address(es) from the MDHCP servers. The fields and options that		address(es) from the server.
	are different from the normal DHCP message exchange are summarized		Patel and Shah 7
	in Table 1 to 3. details on rest of the parameters, please MDHCP 09/16/97		MDHCP 11/20/97
	consult DHCP RFC [1]. The multicast addresses are renewed or		In the first method [see Figure 1], the client is requesting
	released using the DHCP exchanges for network addresses as defined		address(es) from any of the MDHCP servers configured to hand out
	in the DHCP RFC [1].		addresses from a given scope. The client selects a scope and sends
			out a DHCPDISCOVER
			message to the multicast address of the MDHCP servers. The server
			responds by sending DHCPOFFER message directly to the client. The
			client then sends DHCPREQUEST messages to the multicast address.
			of the MDHCP servers. The selected server responds by sending
			DHCPACK message directly to the client as in normal DHCP protocol.
			The multicast DHCPDICOVER and DHCPREQUEST messages are received by
			only the multicast capable DHCP servers, and therefore, there is no
			conflict between the MDHCP and DHCP messages. Further, the messages
			for renewing and releasing lease are sent directly to the MDHCP
			servers only, and therefore, there is conflict between DHCP and
			MDHCP message interpretation by a non-MDHCP capable server. The
			fields and options that are different from the normal DHCP message
			exchange are summarized in Table 1 to 3. For details on rest of the
			fields, please refer DHCP RFC [1].
			The client can later renew or release the multicast address by using
			DHCPREQUEST and DHCPRELEASE message exchanges as defined in the DHCP
			RFC [1].
			At any time, if the MDHCP server is unable to satisfy the
			DHCPREQUEST message (e.g., the requested address has been
			allocated), the server MUST respond with a DHCPNAK message.
	Note that all the messages in this exchange have their M flag set		Note that all the messages in this exchange have their M flag set
	and B flag not set.		and B flag not set.
			In the second method [see Figure 2] the client is requesting
			address(es) directly from a specific MDHCP server. When a client
			knows the IP address of the MDHCP server from which it can obtain a
			multicast address(es) from a give scope, it MAY skip the discover
			phase ( i.e. DHCPDISCOVER and DHCPOFFER message exchange ) and
			directly start with unicasting DHCPREQUEST message to the server. If
			this fails, the client SHOULD revert back to the first method.
			The MDHCP client may need to be deployed on the client machines
			where DHCP client implementation is not capable of filtering out the
			MDHCP messages. In that case, the MDHCP client MUST use a port
			number different from ‘DHCP client port(68)’. The MDHCP client MUST
			specify this port in the DHCPDISCOVER and DHCPREQUEST messages via
			‘Client Port Option’.
	The MDHCP Client MUST provide client identifier option when sending		The MDHCP Client MUST provide client identifier option when sending
	messages for multicast address assignment. The client generates a		messages for multicast address assignment. The client generates a
	unique key and uses that as a client identifier in the DHCPDISCOVER		unique key and uses that as a client identifier in the DHCPDISCOVER
	message.		message. The client identifier is the key to distinguish the client
			request and to avoid duplicate address allocation.
	Each client may be running several different multicast enabled		Each client may be running several different multicast enabled
	applications, and each application may require separate multicast		applications, and each application may require separate multicast
	address(es). Client MUST use separate unique client identifier when		address(es). Client MUST use separate unique client identifier when
	requesting separate multicast address(es) for each application.
	A client implementation may choose to use hardware address, hardware		Patel and Shah 8
			MDHCP 11/20/97
	type and application instance number to generate unique client		requesting separate multicast address(es) for each request. A client
	identifier. MDHCP 09/16/97		implementation may choose to use hardware address, application
			instance and time of request to generate unique client identifiers.
			The following tables [Table 1, Table 2] describes the fields and
			options that are relavent to MDHCP protocol but are different from
			the normal DHCP protocol [1]
	Field DHCPOFFER DHCPACK DHCPNAK		Field DHCPOFFER DHCPACK DHCPNAK
	----- --------- ------- -------		----- --------- ------- -------
			'flags' Set 'M' Bit. set 'M' Bit set 'M' bit
			BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0
	'ciaddr' 'ciaddr' from 'ciaddr' from 0		'ciaddr' 'ciaddr' from 'ciaddr' from 0
	DHCPDISCOVER or 0 DHCPREQUEST or 0		DHCPDISCOVER or 0 DHCPREQUEST or 0
	'yiaddr' Starting address of Starting address of 0
	the multicast block the multicast block		'yiaddr' Multicast address Multicast address
	assigned to client assigned to client		assigned to client assigned to client
	'siaddr' Server's IP address Server's IP address 0		'siaddr' Server's IP address Server's IP address 0
	reachable from the reachable from the		reachable from the reachable from the
	client. client.		client. client.
	'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from		'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
	client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST		client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
	message message message		message message message
	'file' may contain options may contain options (unused)		'file' may contain options may contain options (unused)
	'options' options options		'options' options options
	Option DHCPOFFER DHCPACK DHCPNAK		Option DHCPOFFER DHCPACK DHCPNAK
	------ --------- ------- -------		------ --------- ------- -------
	IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
			IP address lease time MUST MUST MUST NOT
			Lease Start Time MUST MUST MUST NOT
	Server identifier MUST MUST MUST		Server identifier MUST MUST MUST
	Multicast TTL MUST MUST MUST NOT
	Multicast Block size MAY MAY MUST NOT		Multicast Scope MUST MUST MUST NOT
	Cookie MUST MAY MUST NOT
	Table 1: Fields and options that are different in		Table 1: Fields and options that are different in
	multicast DHCP server messages. MDHCP 09/16/97		multicast DHCP server messages.
	Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,		Patel and Shah 9
			MDHCP 11/20/97
			Field DHCPDISCOVER DHCPREQUEST DHCPRELEASE
	DHCPRELEASE
	----- ------------ ----------- -----------		----- ------------ ----------- -----------
	'flags' Set 'M' Bit. set 'M' Bit set 'M' bit		'flags' Set 'M' Bit. set 'M' Bit set 'M' bit
	BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0		BROADCAST bit 0 BROADCAST bit 0 BROADCAST bit 0
	'ciaddr' client's network client's network 0
	addr reachable addr reachable
	from the server from the server
	'chaddr' may contain may contain may contain
	hardware address hardware address hardware address		'ciaddr' 0 or client's 0 or client's 0
			network addr network addr
			'chaddr' ignored ignored ignored
	'options' options options (unused)		'options' options options (unused)
	Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,		Option DHCPDISCOVER DHCPREQUEST DHCPRELEASE
	DHCPRELEASE
	------ ------------ ----------- -----------		------ ------------ ----------- -----------
	Requested IP address MAY MUST (in MUST
	SELECTING or (DHCPDECLINE),
	INIT-REBOOT) MUST NOT
	MUST NOT (in (DHCPRELEASE)
	BOUND or
	RENEWING)
	Start time MAY MAY MUST NOT		Start time MAY MAY MUST NOT
	Client identifier MUST MUST MAY		Client identifier MUST MUST MAY
			Multicast Scope SHOULD SHOULD MAY
			Client Port MUST(if using MUST (if using MUST NOT
			a different a different
			port) port)
	Table 2: Fields and options that are different in		Table 2: Fields and options that are different in
	multicast DHCP client messages		multicast DHCP client messages
	--------------------------------------------------------------------		Patel and Shah 10
	| |INIT-REBOOT |SELECTING |RENEWING|REBINDING |		MDHCP 11/20/97
	--------------------------------------------------------------------		Server Client Server
	|multi/unicast |multicast |multicast if |unicast |multicast |
	| | |multicast DISCOVER| | |
	| | |unicast otherwise | | |
	|server-ip |MUST NOT |MUST |MUST NOT|MUST NOT |
	|requested-ip |MUST |MUST |MUST NOT|MUST NOT |
	|ciaddr |IP addr |IP addr |IP addr |IP address|
	---------------------------------------------------------------------
	Table 3: Client messages from different states MDHCP 09/16/97		(not selected) (selected)
	3.1. DHCPDISCOVER Message.		v v v
	If the unicast address of a MDHCP server is known and it supports		| | |
	the desired multicast scope, the MDHCP client SHOULD send a
	DHCPDISCOVER address to the MDHCP server. If the MDHCP server fails
	to allocate address(es) or fails to respond, the DHCP client SHOULD
	send a multicast DHCPDISCOVER message to the group address
	(multicast) of the MDHCP server. In both cases, if the client uses
	non-standard DHCP port number, it MUST specify the client port
	option. The client MUST also specify its IP address in the ciaddr		| Obtain IP address |
	field so that the MDHCP server and respond to the client request
	with a unicast message. The B flag must not be set and M flag MUST
	be set.
	The client MUST include client identifier option.		| | |
	In addition, the DHCPDISCOVER option SHOULD include the following
	options:		|Begin multicast address request|
	o DHCP Scope,		| | |
	o Start time,
	o Lease time (duration)
	If any of these options are not specified, the DHCP server		| _____________/|\_____________ |
	may assume default values.
	3.2. DHCPOFFER Message.		|/ DHCPDISCOVER | DHCPDISCOVER \|
	The DHCP server may respond to a DHCPDISCOVER message with a		| | |
	unicast DHCPOFFER the client. This message MUST includes an
	available multicast address using ``yiaddr'' field. The
	MDHCP server SHOULD reserve the offered address. When allocating		Determines | Determines
	the address, the server MUST make every effort to ensure that the
	address is not in use for the lease period.
	The server MUST include configuration parameters such as DHCP		address(es) | address(es)
	scope, start and lease time, in the DHCPOFFER message, if different
	from the ones requested. The MDHCP server must specify a cookie
	value in this message and this cookie MUST be specified in all the		| | |
	subsequent messages exchanged between the MDHCP clients and server
	pertaining to associated address(es). The MDHCP server MUST use the
	cookie to identify the addresses instead of the client IP address.
	3.3. DHCPREQUEST		|\ | ____________/|
	The client will select a multicast address(es) from a DHCPOFFER MDHCP 09/16/97		| \_________ | /DHCPOFFER |
	response. The client SHOULD send a unicast DHCPREQUEST message		| DHCPOFFER\ |/ |
	indicating the selected multicast address(es) to the MDHCP server,
	when the DHCPOFFER was in response to a unicast DHCPDISCOVER
	message, and using a multicast message, when the DHCPOFFER was in		| \ | |
	response to a multicast address. It MUST include multicast address
	option field in the response. If the number of address selected are
	different from the number of offered address, the client MUST also
	include the multicast block size option.
	The M flag MUST be set and B flag MUST NOT be set.		| Collects replies |
	3.4. DHCPACK.		| \| |
	If the multicast address(es) are still available, the MDHCP server		| Selects Address(es) |
	MUST reserve the address and send a DHCPACK message. Any
	configuration parameters in the DHCPACK message SHOULD NOT conflict
	with the ones in earlier DHCPOFFER message. The M flag MUST be set		| | |
	and B flag MUST NOT be set.
	3.5. DHCPNACK		| _____________/|\_____________ |
	The server MAY choose to mark the multicast address in DHCPOFFER		|/ DHCPREQUEST | DHCPREQUEST \|
	unavailable to the client. In that case it will send DHCPNACK		| | |
	message. The M flag MUST be set and B flag MUST NOT be set.
	3.6. Renewing and termination of lease		| | Commits address(es)
	The client may choose to release address(es) before the lease time		| | |
	has expired. The usual DHCP messages are used for this purpose.		| | _____________/|
	The M flag MUST be set and B flag MUST not be set. Moreover, the		| |/ DHCPACK |
	client port option SHOULD be specified, if the client is using a
	port different from the standard DHCP port. The cookie MUST be
	specified with RENEW and RELEASE messages.
	4. Examples of usage		| | |
	The MDHCP server is not required to be co-located with a DHCP		| assignment complete |
	server. Therefore, in a typical deployment, there may be fewer
	MDHCP servers then the DHCP servers. We consider specific examples
	of DHCP configurations and the use of MDHCP protocol extensions.
	4.1. One MDHCP server MDHCP 09/16/97		| | |
	There is one MDHCP server which is configured to allocate multicast		. . .
	addresses to a client and there may be many DHCP servers. The DHCP
	servers should be configured to provide the address of the MDHCP
	server capable of allocating multicast address to the MDHCP client,		| | |
	and should include a multicast scope list supported by the MDHCP
	server. The client may obtain the DHCP server address and scope
	list through DHCP client configuration procedure (and may use
	DHCPINFORM message). The client then selects a multicast scope from
	which the multicast address is to be requested and sends out a
	unicast DHCPDISCOVER address and includes multicast scope, start
	time, and lease time information using DHCP options. It
	may also specify multicast block size. The MDHCP server		| Graceful release |
	responds with an DHCPOFFER for multicast address and includes a TTL
	value to be used with this address. The client sends out a
	DHCPREQUEST message and includes the selected. If the address is
	still available, the server responds with an DHCPACK message, else
	responds with a NACK message.
	Since the DHCP messages are directly send to the MDHCP server, the		| | |
	server is capable of interpreting M flag and therefore, there will
	be no conflict between the interpretation of DHCP and MDHCP
	messages. MDHCP 09/16/97
	Client Server (selected)		| |\_____________ |
	v v
	| |		| | DHCPRELEASE \|
	Obtain IP address |
	| |
	| |
	Begin multicast address request|
	| |
	| |
	|\_____________ |
	| DHCPDISCOVER \|		| | |
	| |
	| Determines		| | Discards lease
	| address(es)
	| |		| | |
	| ____________/|
	| /DHCPOFFER |		v v v
			Figure 1: Timeline diagram of messages exchanged between MDHCP
			client and servers using group multicast address for MDHCP
			capable servers.
			Patel and Shah 11
			MDHCP 11/20/97
			Client Server
			v v
	|/ |
	| |
	\| |
	Selects Address(es) |
	| |		| |
	|\_____________ |		|\_____________ |
	| DHCPREQUEST \|		| DHCPREQUEST \|
	| |		| |
	| Commits address(es)		| Commits address(es)
	| |		| |
	| _____________/|		| _____________/|
	|/ DHCPACK |		|/ DHCPACK |
	| |		| |
	assignment complete |
			| assignment complete
	| |		| |
	. .		. .
	. .
	| |
	Graceful release |
	| |
	|\_____________ |
	| DHCPRELEASE \|
	| |
	| Discards lease
	| |		| |
	v v
	Figure 1: Timeline diagram of messages exchanged between MDHCP
	client and servers when allocating multicast address(es) using
	unicast messages to a MDHCP capable server. MDHCP 09/16/97
	4.2. One or more MDHCP servers		Graceful release |
	If one or more MDHCP servers are available to a MDHCP client for		| |
	the purpose of assigning multicast addresses, the DHCP scope list
	option SHOULD specify an administratively scoped group address used
	by the MDHCP servers to receive DHCPDISCOVER messages. Each scope
	in the scope list MUST be supported by at least one server listening		|\_____________ |
	to the group multicast address used by MDHCP servers.
	The client SHOULD select a scope and send out a DHCPDISCOVER,		| DHCPRELEASE \|
	DHCPREQUEST messages to the group multicast address. The multicast
	DHCPREQUEST message is only received by the MDHCP capable DHCP
	servers, and therefore, there is no conflict between the MDHCP and
	DHCP messages. Further, the messages for renewing and releasing		| |
	lease are sent directly to the MDHCP servers only, and therefore,
	there is conflict between DHCP and MDHCP message interpretation by
	a non-MDHCP capable server.
	A summary of fields of MDHCP in messages that are different from		| Discards lease
	the corresponding DHCP [1] messages are specified in Tables 1 to 3.
	In some cases, the client may be aware of the unicast address of an		| |
	MDHCP capable server, and may also be aware of the group multicast
	address of the MDHCP capable servers. In that case, the client
	SHOULD first try to use the unicast address, and if unsuccessful,
	SHOULD try the group multicast address for MDHCP servers. MDHCP 09/16/97
	Server Client Server
	(not selected) (selected)
	v v v		v v v
	| | |
	| Obtain IP address |
	| | |
	|Begin multicast address request|
	| | |
	| _____________/|\_____________ |
	|/ DHCPDISCOVER | DHCPDISCOVER \|
	| | |
	Determines | Determines
	address(es) | address(es)
	| | |
	|\ | ____________/|
	| \_________ | /DHCPOFFER |
	| DHCPOFFER\ |/ |
	| \ | |
	| Collects replies |
	| \| |
	| Selects Address(es) |
	| | |
	| _____________/|\_____________ |
	|/ DHCPREQUEST | DHCPREQUEST \|
	| | |
	| | Commits address(es)
	| | |
	| | _____________/|
	| |/ DHCPACK |
	| | |
	| assignment complete |
	| | |
	. . .
	| | |
	| Graceful release |
	| | |
	| |\_____________ |
	| | DHCPRELEASE \|
	| | |
	| | Discards lease
	| | |
	v v v
	Figure 2: Timeline diagram of messages exchanged between MDHCP		Figure 2: Timeline diagram of messages exchanged between MDHCP
	client and servers when allocating multicast		client and servers when MDHCP server has already been
	address(es) using group multicast address for MDHCP		selected
	capable servers. MDHCP 09/16/97
	5. MDHCP Protocol properties		4. MDHCP Protocol properties
	Conflict free address allocation: In the intranet case, each MDHCP		Conflict free address allocation: In the intranet case, each MDHCP
	server is allocated part of the administratively scoped address		server MAY be allocated part of the administratively scoped address
	space. As long as the address space managed by MDHCP servers is		space. As long as the address space managed by MDHCP servers is
	non-overlapping for a given administrative scope, the protocol		non-overlapping for a given administrative scope, the protocol
	will allocate conflict free addresses. MDHCP protocol does not		will allocate conflict free addresses. MDHCP protocol does not
	directly address the mechanisms for determining address allocation		directly address the mechanisms for determining address allocation
	outside Intranet. However, we propose to use MDHCP as a front end		outside Intranet. However, we propose to use MDHCP as a front end
			to any future address allocation protocol for the Internet. The DHCP
	to any future address allocation protocol for the		protocol will preserve conflict free address allocation property of
	Internet. The MDHCP protocol will preserve conflict free address		the internet multicast address allocation protocol.
	allocation property of the internet multicast address allocation
	protocol.
	Session protocol independence: The MDHCP protocol does not dictate
	use of the address allocated, and does not rely on any session
	control protocol. Therefore, it will work with SIP or SAP based
	session control protocol.
	Small response time: The response time for MDHCP protocol is		Small response time: The response time for MDHCP protocol is
	strictly based on the network propagation delay and the load on the		strictly based on the network propagation delay and the load on the
	MDHCP server.		MDHCP server.
	The MDHCP protocol does not require a client system to be on all		The MDHCP protocol does not require a client system to be on all the
	the time. Thus, it poses no additional requirements on power		time. Thus, it poses no additional requirements on power managed
	managed systems.		systems.
			Patel and Shah 12
			MDHCP 11/20/97
	Multicast address scopes: The administratively scoped multicast		Multicast address scopes: The administratively scoped multicast
	address may be directly allocated by MDHCP server. However, it is		address may be directly allocated by MDHCP server. However, it is
	envisioned that the MDHCP protocol will be indirectly used for		envisioned that the MDHCP protocol will be indirectly used for
	Internet wide Multicast addresses allocation. In such deployment,		Internet wide Multicast addresses allocation. In such deployment,
	the MDHCP server will act as a front-end to future Internet		the MDHCP server will act as a front-end to future Internet
	multicast address allocation protocols.		multicast address allocation protocols.
	Efficient use of address space: The multicast address space may be		Efficient use of address space: The multicast address space may be
	statically partitioned between MDHCP servers to provide sufficient		statically partitioned between MDHCP servers to provide sufficient
	reliability and load management on servers. However, the multicast		reliability and load management on servers. However, the multicast
	based address request will be able to obtain addresses from any of		based address request will be able to obtain addresses from any of
			the available servers.
	the available servers. Alternately, the MDHCP server can be		5. Security Considerations
	organized hierarchically where a master server allocates blocks of
	addresses to the child servers (using MDHCP protocol). It is also
	possible to provide further fault-tolerance using DHCP server-server
	protocol. MDHCP 09/16/97
	6. Security Considerations
	This document does not explicitly address security considerations to		This document does not explicitly address security considerations to
	avoid redundant effort with the work in progress in DHC working		avoid redundant effort with the work in progress in DHC working
	group of IETF on securing DHCP.		group of IETF on securing DHCP.
	7. Acknowledgements		6. Acknowledgements
	The authors would like to thank Rajeev Byrisetty, Steve Deering,		The authors would like to thank Rajeev Byrisetty, Steve Deering,
	Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning,		Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning,
	Dave Thayler, Ramesh Vyaghrapuri and the participants of IETF for		Dave Thayler, Ramesh Vyaghrapuri and the participants of IETF for
	their assistance with this protocol.		their assistance with this protocol.
	8. References		7. References
	[1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,		[1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
	October 1993.		October 1993.
	[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor		[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
	Extensions", RFC 1533, Lachman Technology, Inc., Bucknell		Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
	University, October 1993.		University, October 1993.
	[3] Patel, B., and Shah, M., ``Multicast address allocation		[3] Patel, B., and Shah, M., ``Multicast address allocation
	extensions options'' <draft-ietf-dhc-multopt-00.txt>		extensions options'' <draft-ietf-dhc-multopt-00.txt>
	[4] Meyer, D., ``Administratively scoped IP Multicast'', Internet		[4] Meyer, D., ``Administratively scoped IP Multicast'', Internet
	draft, <draft-ietf-mboned-admin-ip-space-01.txt>		draft, <draft-ietf-mboned-admin-ip-space-01.txt>
	[5] D. Mills, ``Network Time Protocol version 2 specification and		[5] D. Mills, ``Network Time Protocol version 2 specification and
	implementation'',		implementation'',
	9. Author's Address		8. Author's Address
	Baiju V. Patel		Baiju V. Patel
	Intel Corp.		Intel Corp.
	2111 NE 25th Ave.		2111 NE 25th Ave.
	Hillsboro, OR 97124		Hillsboro, OR 97124
			Patel and Shah 13
			MDHCP 11/20/97
	Phone: 503 264 2422		Phone: 503 264 2422
	EMail: baiju@mailbox.jf.intel.com		EMail: baiju@mailbox.jf.intel.com
	Munil Shah		Munil Shah
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Phone:206 703 3924		Phone:425 703 3924
	Email:munils@microsoft.com		Email:munils@microsoft.com
	This document will expire on Sept, 1997 MDHCP 09/16/97		This document will expire on April, 1998
			Patel and Shah 14
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/