On 5/18/05, Thomas Narten <[EMAIL PROTECTED]> wrote:
Let me just start off by saying I pretty much agree completely with what Bernie just said.
Even I do agrre, what Bernie said. I understodd from his mail, a node can
fall back to Information Configuration Behavior (DHCPv6 Lite) if ti fails do Full DHCP.
I am not sure if such infomation is available in handy somewhere.
Moreless the draft looks similar to what Bernie said except with more options
to control the invoking th DHCPv6 behaviour, e.g., If I know prettty sure that the DHCPv6
is not avaialble in the network my node is connected, I have not seen any reason why I should
let DHCPv6 be running in the background.
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?
If it is this simple, we do not really need the M/O flags in Router Advertisements.
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.).
Also it is not clear for nodes what they should if they receive these bits ON to OFF and vise versa.
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?
Currently for IPv4, we either select to get the address using DHCP, or configure manually.
At least this true in Windows OS.
Similarly, it is not bad idea to have options for IPv6 to select between DHCPv6, SLAAC or Manual or
combination of these. For an intelligent use he can furthe select options for DHCPv6 either to run all
the time or run only when host sees the M/O flag set. THis is what the policy the draft is talking about.
Of course I do agree that it it little heavy in the current form, which can be simplified.
I think it is worth clarifing these, and in any case the draft is not going to introduce any
changes to the existing standards.
Thomas
_______________________________________________ dhcwg mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dhcwg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
