On Jul 27, 2005, at 12:21 AM, Iljitsch van Beijnum wrote:
Requirement 1 simply says "DHCP is not available"; it doesn't say "do
not try to find it".
I disagree. On some networks it's inappropriate to try to use DHCPv6.
And if hosts are going to look for DHCPv6 servers regardless of the
value of the M/O bits, what's the point of this whole discussion??
It's the difference between policy and mechanism. We can say that
when the M/O bits say there is no DHCPv6 service on the network, the
client SHOULD NOT try to do DHCPv6. Or we can say that when the M/O
bits say there is no DHCPv6 on the network, the client MUST NOT try
to do DHCPv6. The latter statement leaves us with a lot less wiggle
room, and is hard to justify in any but the most resource-constrained
context. A client implemented for such a context benefits from
following the SHOULD NOT, so there is probably no need for a MUST NOT.
I should note that I don't actually care one way or another whether
it's a SHOULD NOT or a MUST NOT, because I don't think we have enough
operational experience to understand what the problems will be either
way. So I suspect that whatever is said on this in the next draft
of any document that comes out, it will not be the last word. On
that basis, I think we should try our best to get it right, but not
freak out about getting it right. :'}
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
