Seems to me it would be useful to allow both M and O flag on.
While, in theory, the support for the subset of DHCPv6 indicated by the O bit is implied by the support for all of DHCPv6 indicated by the M bit, it seems there would be little harm in advertising both.
Some hosts may choose to use both the Request message exchange for address assignment and the Information-Request message exchange for other information. For example, an application may need other configuration information that was not supplied during the initial Request message exchange, requiring a subsequent Informaton-Request message exchange for that information. There are DHCPv4 hosts that work this way today.
- Ralph
At 12:32 PM 8/11/2004 -0400, Soliman Hesham wrote:
I have a silly question below.
> I now feel I get understanding the point...to make it sure, > let me try > to rephrase that. > > Assume we have a "stateful" DHCPv6 server (that implements RFC3315) > running. The server should support both > Solicit/Advertise/Request/Reply(/and Renew) and > Information-request/Reply exchanges. > > Then the administrator would send Router Advertisement with > the M flag > being ON and the O flag being OFF. (The O flag is OFF since there is > no server that only supports RFC3736).
=> Couldn't the admin turn on the O flag in this case too? The host doesn't know which RFC the server supports so I don't see what harm will be done if the O flag is turned on independently of the setting of the M flag.
> Now consider a host that only implements (the client side > of) RFC3736, > configures global addresses via stateless address autoconfiguration > (assuming the RAs provide global prefixes for this), and wants to > configure recursive DNS server addresses using RFC3736. However, > since the O flag is OFF in advertised RAs, the host would not be able > to invoke the RFC3736 procedure and therefore cannot configure DNS > server addresses. This should be a suboptimal scenario.
=> Right, but there is no need to have the O flag off. To me RFC 3736 is something useful for server vendors and should not be associated with setting the O flag.
Hesham
=========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. ===========================================================
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
