I also agree with this. I think this would be useful and there is no harm. - Bernie
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ralph Droms > Sent: Thursday, August 12, 2004 9:26 AM > To: [EMAIL PROTECTED] > Subject: RE: Stateful != M , Stateless != O > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
