host-identifier with IPv6

[Niall O'Reilly]

	Backing up to when,
On Fri, 2009-02-27 at 14:08 +1300, Eustace, Glen wrote:
> This latter issue has driven me mad!!  I prefer not to hack code so
> haven't 'fixed' the issue by ignoring the dhcp-id for ipv4. But we
> have had to set lease lifetime down to 5 secs for PXE boots so that we
> don't run out of leases in several of our laboratory pools.
> 
> I didn't realise this was going to be a can of worms.  The best
> solution I can think of is to add in options that change the behaviour
> away from the 'standard'.  The default should be what the 'standard'
> says but if there are legitimate cases where the standard doesn't work
> for people, having the ability to change the behaviour by turning
> on/off an option would seem a pretty good compromise.

	and after reading subsequent messages in this thread, I now
	see that there are two distinct questions to be addressed here,
	only one of which matches the thread subject directly.

	One question has to do with mitigating the problems which arise
	on IPv4 networks whose operators estimate the usefulness of any
	client identifier other than the link-layer address as close to
	zero, and this for very good reasons, actually mentioned on 
	page 220 of the first edition of Droms & Lemon. [They also 
	mention a potential problem with depending on the link-layer
	address, but that's not a problem for the networks I'm involved
	with.]  This is the question which is nearer my heart, and 
	further from the subject of the thread. 

	It would be very useful to have a configuration option allowing 
	an operator to specify that the only trustworthy client 
	identifier for _this_ network is the link-layer address.  Such
	an option would be philosophically analogous to that long 
	available for BIND named and named-checkzone with regard to
	standards-compliance for host names.

	OTOH, the 'real' subject of the thread is not unrelated.  If
	it's already a problem on a number of IPv4 networks that there 
	is no option to allow a network operator to substitute for a 
	client identifier which is operationally useless (for the valid 
	purposes of that network operator) one which actually has value,
	shouldn't we recognize and take account of this problem in
	mapping out the way forward in the IPv6 environment?

	No doubt someone will point out that I really need to liberate
	myself from an outmoded IPv4 mindset, and commit myself to the
	Royal Way of IPv6.  There!  I've saved that someone the trouble.

	Have a good weekend.

	/Niall