On Fri, 20 May 2005, Bob Hinden wrote:
Also, I am not sure I understand what the problem is regarding knowing when
to try using DHCPv6. For practical purposes, if there isn't a router present
(indicated by the RAs it sends) is very unlikely that there will be a DHCPv6
server either (or it won't be reachable because the router is down). If the
"m" and/or "o" bits are set in a RA, it is a pretty good hint that a host
might try to use DHCPv6 and see what it gets. If the "m" or "o" bits are not
set, then it's a pretty good hint that there isn't much sense in trying to
use DHCPv6.
Actually, the lack of M or O bits is not as good a hint as their
existence. If we wanted a _good_ hint about non-existence of DHCPv6
(for addresses or config information), we'd have to have different
flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in
this network". That allows disambiguation from "Yes, we do have a
couple of DHCPv6 servers, but we weren't aware you should configure
this stuff in the RAs, because with v4 you don't".
But I'm not sure that disambiguation is worth the effort.
That said, I support the clarification. In a sense I agree with
Thomas et al that the ra-mo-flags spec goes beyond the bare minimum
what the IETF specifications must specify -- it documents the policies
and behaviours which most vendors would implement in any case, but
these kind of knobs have often been left out of our specs. However,
as there has been so much confusion and discussion of M/O flags, I
think this specification is useful, and also allows vendors (who want
to) to implement the knobs in a uniform manner.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
