Let me just start off by saying I pretty much agree completely with
what Bernie just said.
I've also reviewed this document, and I am really wondering what this
document is trying to achieve. It seems to me that its added a lot of
text (that IMO is not really needed). In particular, I don't think
either Section 6 or 7 are necessary or appropriate.
There are really only two behaviors a client should be doing. If a
client doesn't implement DHC, well, then it obviously shouldn't/can't
invoke DHC. End of story. If it does implement DHC, well, it should
use it. Moreover, it shold never really be a "client" choice whether
to invoke use DHC or not. If the sys admin has stuff available via
DHC, the client should (in the SHOULD sense) be getting it and using
it. Why on earth would we want to disable that via a configuration
knob?
Indeed, when I look at Section 2, "Background", I find that the
wording that it quotes from RFC 2461 really does say pretty much what
should be said. That is, these bits are "hints" that the local sys
admin has a DHC server that is giving out addresses and/or other
configuration information. Seems to me, if the local access network is
giving out config information, clients SHOULD try and get it, because
if they don't, they will presumably operate at some sort of reduced
level of functionality -- after all, if a sys admin set up a DHC
server, there must be a reason for this (e.g., to provide DNS
recursive name server service, addresses not available via stateless
addrconf, etc.).
So, these bits should just provide clients with a stronger indication
that they should be using DHC to get the information that is
available.
If the original 2461 text is really deemed insufficient, how about
something like:
o M :
1-bit "Managed address configuration" flag. When set, it
indicates that addresses are available via Dynamic Host
Configuration Protocol [DHCPv6], including addresses that were
not configured via stateless address autoconfiguration. Clients
SHOULD use DHC to obtain addresses (and associated
configuration information) as described in [ADDRCONF]. Note
that when the M bit is set, the setting of the O bit is
irrelevant, since the DHC server will return "other"
configuration information together with addresses.
o O :
1-bit "Other configuration" flag. When set, it indicates that
[DHCPv6lite] is available for autoconfiguration of other
(non-address) information. Examples of such information are
DNS-related information or information on other servers within
the network. When set,
- If the M bit is also set, clients SHOULD use DHC to obtain
addresses (and associated configuration information) as
described above.
- If the M bit is not set, clients SHOULD use DHC as
described in RFC 3736.
Is more than something like the above _really_ needed? If so, why?
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
