Subject: List of DHCPv6 Issues with Responses, Part 2 of 2

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 10 Nov 1999 18:51:57 -0500 (EST)

Hi folks,
	Try again, mailer choked.

					bound/mwc/perkins	11/08/99

		List of DHCPv6 Issues with responses, part 2 of 2
		=================================================

DHCPv4 disadvantages to avoid:
==============================

	*	Lack of DHCP protocol versioning in original
		specification.

				We're adding a DHCPv6 extension for
				protocol version to the extensions
				draft.

	*	Changes to options in most cases necessitate changes to
		client and server implementations. Can we avoid this by
		carefully specifying suggested generic encoding
		mechanisms?

		Response:	Good point. We'll add text to the
				extensions document suggesting handling
				of data of different types. Note also
				that we'll draw in what was learned from
				the DHCPv4 futures panel regarding the
				review of options/extensions. This
				should help extension authors and
				the DHC community avoid unnecessary
				changes to implementations.

	*	Confusion regarding minimum packet size. Some say BOOTP
		size (300bytes) is the minimum, whereas others say the
		minimum is the fixed part of the BOOTP header.

		Response:	Appendix B notes that the IPv6 MTU is
				used, potential learned through Path MTU
				discovery. A client can signal to the
				agent its DHCPv6 MTU through the use of
				the Maximum DHCPv6 Message Size
				Extension. The client will learn the PMTU
				from the relay if necessary (DHCP relay
				ICMP error message).

	*	Change in RFC 1541 -> RFC 2131 INIT-REBOOT DHCPREQUEST
		format was not backward compatible.

		Response:	Adding a DHCPv6 protocol version
				extension discussed above will enable
				us to deal appropriately with
				incompatible changes in the future.

DHCPv4 advantages, DHCPv4-based questions
=========================================

	*	State transition diagram clarifies client / server
		interaction.

		Response:	We will produce client and server
				implementation state transition
				diagrams for DHCPv6 for inclusion in the
				appendix.

	*	Client version

		Response:	We're adding a DHCPv6 protocol version
				extension to carry the protocol version.
				Client implementation versions are
				handled by the implementors.

	*	DHCP server load balancing
		
		Response:	We will widen the specification to allow
				relay agents to relay to unicast and any
				other specified multicast address (not
				just the DHCP ones). We also suggest
				that the implementor of a server could
				use the preference field to signal when
				it was getting overloaded.

DHCPv6 draft issues
===================

	*	Consider merging two documents into one

		Response:	We plan on leaving the extensions
				definitions in the extensions draft. We
				will improve the protocol draft by
				adding more references to the extension
				draft where protocol-related extensions
				are discussed.

	*	What is the process for defining, reviewing, and
		acceptance of new extensions? Particularly when there are
		DHCPv4 options for the same item?

		Response:	We plan on incorporating the findings of
				the futures panel such that these
				processes are described where
				appropriate in the protocol document and
				the extensions document.

	*	There isn't a clear state machine defined.

		Response:	We will be adding client and server
				implementation state diagrams to the
				appendix of the protocol draft.

	*	No background explanations for complicated message
		exchanges.

		Response:	As part of clarifying the document,
				we'll expand the explanations to the
				WG's satisfaction.

	*	General lack of background for complication (seemingly)
		in protocol itself.

		Response:	We got no specific guidance from the WG
				on this point. We will add an
				introductory 'flow' section in an
				attempt to make the protocol clearer.
				There will also be client and server
				implementation state diagrams in the
				appendix.

	*	How does a client request addresses from multiple
		prefixes?

		Response:	We have two possibilities:

			     1) We will add a new "scope" field to the
				IP address extension for use by clients
				to request IP addresses of specific
				scope. The scope field consumes 4 bits
				of the reserved field as follows:

				The high order bit determines whether an
				address matching the scope is requested
				(0) or required (1). The following 3
				bits form a number (0-7) which have the
				following meanings:

				0	Globally scoped address
				1	Site local address
				2	reserved
				3	reserved
				4	reserved
				5	reserved
				6	reserved
				7	reserved

			     2) Produce an additional optional field in
			        the IP address extension called the
				scope field. A new bit (Scope=S) would
				be set when the scope field is present.
				This field carries a prefix
				specification.  Servers would use it in
				IP address extensions in advertise
				messages to communicate which prefixes
				were available and clients can use it in
				requests.

				Comments?
				
	*	How does a client request additional IP addresses? The
		specs aren't at all clear on how this would be done.

		Response:	When a client sends a DHCP request with
				the 'C' bit set, the client has
				'amnesia', and therefore requests the
				server to free up any allocated
				releasable resources. Thus, all IP
				addresses assigned to the client are
				released. Any IP address extensions are
				processed using #a and #c below. When a
				client sends a DHCP request without the
				'C' bit set, it is seeking one of the
				following, based upon the contents of
				the IP address extension:

				a) Requesting a particular IP address.

				b) Requesting an extension on the
				lifetimes of a existing address.

				c) Requesting a new IP address. Note
				that by using the proposed scope field
				in the IP address extension, the client
				can request exactly what prefix the
				client would like the IP address
				allocated from.

				If multiple IP address extensions are
				included in a request w/o the C bit set,
				the above possibilites (a-c) are
				considered by the server for each
				extension.

	*	Does the RECONFIGURE mechanism scale wrt ACK
		implosion? New RECONFIGURE reduces messages from 2N to
		N, but N may still be large.

		Response:	We believe our current mechanism is
				adequate, particularly since we haven't
				received an alternate suggested
				mechanism we find superior to the
				existing one.

	*	No concept of T1/T2 times (or % of lifetimes) for client
		use when deciding when and how often to contact server
		to extend various lifetimes for certain extensions, of
		which IP address is one such extension.

		Response:	We'll clarify the text such that a
				client requests a lifetime extension
				when an address becomes deprecated.

	*	Affect that 'A' and 'Q' bit (MUST update AAAA record
		before responding) has on retransmission not clear.

		Response:	We'll add text discussing the impact of
				that long-lived dns update transactions
				have on the client / server interaction.

	*	DHCPv6 is prone to denial of service attacks like the
		IPv4 icmp router discovery attack.

		Response:	To reduce the scope of such attacks,
				we'll change the text to specify that
				link local messages must set the hop
				limit to 255, which will limit a
				potential attack to the single link.

	*	Some extensions can be specified multiple times, whereas
		others cannot. Which alternative isn't always clear in
		the extensions draft.

		Response:	Add text to make extensions clear on
				this point.

	*	Release message and failover environments. Would be nice
		to permit messages to be sent to multicast address(es)
		from clients, thus any server will see the release.

		Response:	Allowing this prevents DHCPv6
				authentication from being used (an
				authentication header for a multicast
				address?)

	*	Can you map in the DHCPv4 option space into the DHCPv6
		extension space? This would simplify the LDAP schema.

		Response:	v4 and v6 are different protocols, and
				many of the options (which are even
				useless in v4 land) make no sense in a
				v6 environment.

	*	The reconfigure message semantics (N bit) are confusing;
		what about adding new messages to make it clearer?

		Response:	Background: A reconfigure with the N bit
				set contains any information a client
				needs for the reconfiguration. A
				reconfigure w/o the N bit set is used to
				inform the client to redo the
				request/reply exchange with the server.
				The reconfigure message in this case
				does not contain all of the necessary
				data for a reconfiguration.

				We will change the specs as follows: The
				reconfigure message maintains its
				current form (including the N bit).
				However, we will define a new client 
				message, the RECONFIGURE_REPLY message,
				which a client will use in response to a
				reconfigure message with the N bit set.
				This avoids overloading the DHCP request
				message as a "reconfigure reply"
				message, which has been a source of
				confusion within the WG.

	*	Setting address lifetimes to zero (in either
		reconfiguration messages or replies) is quite a denial of
		service attack. How is DHCPv6 going to deal with this?

		Response:	We'll change the spec so that it follows
				an algorithm similar to that in  Section 5.3
				of RFC 2462 (addrconf). If a lifetime is
				less than 2 hrs is received from an
				unauthenticated DHCP server, then a
				lifetime of 2 hrs is assumed. If a
				lifetime of less than 2 hrs is recieved
				from an authenticated DHCP server, then
				that lifetime is accepted.