Subject: Responses from authors on DHCPv6 issues list, part 1

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Fri, 8 Oct 1999 15:37:18 -0400 (EDT)

Comments welcome.

					bound/mwc/perkins 	10/08/99

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

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

	*	Lack of mechanism for defining server priority.

		Response:	DHCPv6 provides this functionality
				through the use of the "preference"
				field in the advertise message.

	*	BOOTP heritage. DHCP suffers alot from overloading the
		BOOTP packet format simply to leverage BOOTP relay agent
		functionality.
		
		Response:	Simply not an issue for DHCPv6.

	*	Current option format too restrictive. Not enough
		options, value lengths too small. Alleviating this
		problem in DHCPv4 made difficult due to BOOTP heritage.

		Response:	DHCPv6 extensions avoid this problem by
				specifying a 16bit unsigned type field
				followed by a 16 bit unsigned length
				field, permitting 64k extensions, with a
				maximum length of 64k-2 in length.

	*	Uses broadcast.
	
		Response:	IPv6 doesn't have broadcast.

	*	Overloading single Packet type for multiple purposes.
		DHCPREQUEST's use in INIT, INIT-REBOOT, and RENEW/REBIND
		has been a source of major confusion for implementors.
		We should avoid overloading packet types as much as
		possible.

		Response:	We hear you. We'll separate the two
				forms of the reconfigure message into
				different message types.

	*	Confusion about interaction between vendor class id and
		encapsulated vendor option. Verbiage in original RFC
		1541 appears to have been deleted in RFC 2131.

		Response:	The platform specific Information
				section of the extensions document
				describes in detail the use of the
				exncapsulated platform-specific
				extension and its relationship with the
				platform class identifier.

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

	*	Does not require service on every link; service can be
		remote from client's link

		Response:	DHCPv6 has a notion of a relay agent,
				thus DHCPv6 has this feature.

	*	Has specified an optional server to server
		synchronization protocol.

		Response:	We do not consider a server to server
				protocol as part of the base DHCPv6
				specification; however, we will work
				with the DHCPv4 server to server people
				to ensure that the DHCPv6 protocol does
				not have any elements that would prevent
				a separate specification of a server to
				server protocol from being written.

	*	DHCPv4 / DNS interaction finally reaching maturity. How
		well defined is this in DHCPv6?

		Response:	Very well-defined. DNS integration as
				always been a goal of DHCPv6 from the
				start.

	*	Is what has been learned during the DHCP authentication
		draft development useful in the discussion in the v6
		extensions draft?

		Response:	DHCPv6 defines a Client-Server
				authentication  extension in the
				extensions draft. It is the same
				authentication mechanism that is 
				used by Mobile IP.

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

	*	Document organization makes protocol unclear.
		Information is duplicated, some info contradictory.

		Response:	The authors have committed to reorganize
				this document to make it clearer, as
				well as provide an introductory section
				showing the interaction between client
				and server. We also will have a state
				transition diagram to help the reader
				become oriented properly when reading
				the material.

	*	RECONFIGURE / renumbering semantics unclear.

		Response:	We'll clarify these points. Note also
				that we will be defining a new message
				to avoid overloading the RECONFIGURE
				message.

	*	Do we still need the added complication of the ability
		to request multiple addresses, in the light of http 1.1?
		(this support is seen as a source of major complication
		in the current draft)

		Response:	The authors feel that this functionality
				is fundamental to IPv6, thus it needs to
				stay in the specification. We will
				endeavor to clarify the description as
				much as possible.

	*	What about the new media becoming available? How well
		will DHCPV6 work in these environments? Example: IEEE
		1394, USB, CDN. What about traditional environments?
		ATM, FDDI. Are there any issues with multicast in these
		environments? What about PPP?

		Response:	Unlike DHCPv4, DHCPv6 doesn't depend on
				any "special" IP level magic to do its
				job. Thus, DHCPv6 should work on any
				media that supports IPv6/multicast.

	*	Lack of a DHCPv4 -> DHCPv6 section describing the
		differences between the protocols (useful for DHCPv4
		folks thinking about implementing DHCPv6).

		Response:	Um, we got that - appendix C.

	*	Seems like there are too many alternatives for releasing
		resources. 

		Response:	Yes, this point needs work. We need to
				unify the release feature somewhat, or
				provide a section on releasing which
				goes into details on how it's done for
				each of the legal message types.

	*	(Section 6) Is the mandate for implementation strategy
		too strong? Why is XID transaction cache described in
		such detail?

		Response:	We need to clarify this some. We didn't
				intend to mandate the implementation
				strategy, but rather state that if an
				implementor chooses to implement a XID
				transaction cache, then this is how it
				should work.

	*	Which messages are not idempotent (and why not?)

		Response:	We believe they all are idempotent.
				Clarification from the DHC WG
				requested please.

	*	In case of a RECONFIGURE failure, loosen text to specify
		"notify administrator" (rather than "log to error log").

		Response:	Ok.

	*	Section 6.3.2: Clarify that 'C' bit semantics are to
		release all resources, reallocate only those requested
		in message.

		Response:	Ok.

	*	Section 6.4: What does client do with response? Add
		MUST/SHOULD.

		Response:	Should be in 5.6; will add text.

	*	RFC 2119 terminology misused.

		Response:	Will review our use of this terminology.

	*	retransmission backoff not always exponential, and is
		sometimes too short.	

		Response:	Will investigate - we'll ensure drafts
				correct on this point.

	*	Error codes not sequential, and there is no discussion
		of how error codes are allocated (IANA?)

		Response:	The error codes are organized in logical
				groups. We'll add text describing what
				these groups are.

	*	Some extensions require association with server that
		sent the message (releasable resources?) There is no way
		to signal this to the client in a way that avoids having
		to rev the client when new such extensions are deployed.
		Would be much better to flag such options with a bit
		that would allow clients to function appropriately w/o
		change.

		Response:	Releasable resources must be requested
				by the client, and in order for the
				client to request them, the client must
				therefore understand that the extension
				it is requesting is releasable, and thus
				take care to release it when that resource
				is no longer needed.

	*	prefix-size description unclear.

		Response:	We'll add text to explain that the
				prefix-size is set by relay to inform
				server what network link the client is
				on (prefix-size of client's link).

	*	Impact that receiving an IP address with 0 lifetime as
		denial of service attack not handled. Need to look at
		addrconf solution to this problem.

		Response:	We'll add a reference to the autoconf
				solution.