Seems to me that: If M is set(1), a client able to do stateful, does stateful (or full 3315) and ignores the O bit. This client can always fall back to stateless if it receives a NoAddrAvail status for a SOLICIT (as per 17.1.3) and receives no other ADVERTISEs it can use. Though this behavior isn't clearly spelled out in 3315 (either in 17.1.2 or 17.1.3) and may be something we want to consider in a future revision of 3315. Perhaps this behavior could even be controlled by the O bit - if the O bit is set, the client SHOULD try stateless (INFORMATION-REQUEST).
If either M or O is set, a client able to do stateless (either full 3315 or 3736), does stateless. - 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 --------------------------------------------------------------------
