Subject: DHCPv6 issues list

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Tue, 17 Aug 1999 00:05:46 -0400 (EDT)

Hi Folks,
	
	Here are the list of issues we've captured. We (the authors)
are currently producing an item by item response for these issues.
If we've missed some or have gotten some wrong, please let me know.

						bound/mwc/perkins

			List of DHCPv6 Issues to resolve
			================================

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

	*	Lack of mechanism for defining server priority.

	*	BOOTP heritage. DHCP suffers alot from overloading the
		BOOTP packet format simply to leverage BOOTP relay agent
		functionality.
		
	*	Current option format too restrictive. Not enough
		options, value lengths too small. Alleviating this
		problem in DHCPv4 made difficult due to BOOTP heritage.

	*	Lack of DHCP protocol versioning in original
		specification.

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

	*	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.

	*	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.

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

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

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

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

	*	State transition diagram clarifies client / server
		interaction.

	*	Has specified an optional server to server
		synchronization protocol.

	*	Echo option would be handy in DHCPv6. (client retains
		option value to later echo back to server).

	*	Change server explicit option.
	
	*	Client version

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

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

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

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

	*	Consider merging two documents into one

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

	*	RECONFIGURE / renumbering semantics unclear.

	*	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)

	*	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?

	*	There isn't a clear state machine defined.

	*	No background explanations for complicated message
		exchanges.

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

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

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

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

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

	*	How does a client request addresses from multiple
		prefixes?

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

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

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

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

	*	RFC 2119 terminology misused.

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

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

	*	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.

	*	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.

	*	Does a client need to request PTR record update, or is
		it implied that the server will always do the PTR record
		update on its behalf?

	*	prefix-size description unclear.

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

	*	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.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Aug 1999 12:42:41 -0400 (EDT)

In your previous mail you wrote:

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

=> this isn't very clear but I believe "in the light of http 1.1"
means multiple addresses in the same prefix, doesn't it?

=> then this issue is a different one and you do *not* suggest support
for multiple prefixes should be dropped (:-)!

=> I have seen one then you should get that...

Regards

[email-masked]

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 18 Aug 1999 12:23:37 -0400 (EDT)

Thanks for sending this along, Jean-Jacques. We'll take a look.
ASCII art is always lots of fun. ;^)

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803