Subject: [dhcwg] RE: Stateful != M , Stateless != O

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 12:34:08 -0400

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-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Thursday, August 12, 2004 9:26 AM
> To: [email-masked]
> 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-masked]
> >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> >--------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 12 Aug 2004 11:33:31 -0700

> and ignores the O bit. 

More precisely, the M bit indicates that a client wishing to do stateful
may do it, and the M=0 bit indicates that the client should not try.

If the router wants to not enable stateless, then the M bit is not the
right tool. The router should simply not advertise that prefixes are
available for stateless auto-configuration.

-- Christian Huitema