Subject: RE: M=1/O=0 is not valid in full 3315 ?

From: "Bound, Jim" <[email-masked]>
Date: Thu, 19 Aug 2004 07:59:00 -0400

The key is the ongoing debate of stateless vs stateful and members
working their agendas for their products.  The bottom line is the users
will use stateful and stateless and we need a way to permit that and
also inform implementors that both stateful and stateless are required
for clients.  That is the bottom line.  How we say it seems to be still
a debate.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Wednesday, August 18, 2004 7:01 AM
> To: [email-masked]
> Subject: Re: M=1/O=0 is not valid in full 3315 ?
> 
> Ignoring the issue of whether the service available when 0=1 
> is a subset of the service available when M=1 for a minute...
> 
> Practically speaking, even if we legislate that an RA is not 
> allowed to have M=1/O=0 or M=1/O=1, in practice, at some 
> point, some host will receive an RA with one of those 
> disallowed flag settings.  My guess is that a client will 
> *not* ignore the input and log an error meesage.
> Rather, the client will try to interpret the bits - perhaps 
> interpreting each bit as indicating availability of each 
> servie individually? - and make a good choice about using DHCP.
> 
> Suppose a host has a local policy that it does not need to 
> obtain addresses through DHCP (e.g., it has manually assigned 
> addresses), and receives the disallowed combination M=1/O=0.  
> If I were writing a client, I would have that client first 
> try an Information-Request exchange.  If that exchange 
> receives no response, I would have the client send a Discover 
> message, without asking for the assignment of any addresses.
> 
> My recommendation is not to bother disallowing any specific 
> combinations of M/O bits and give simple guidelines to client 
> implementors...
> 
> - Ralph
> 
> On Wed, 18 Aug 2004, S. Daniel Park wrote:
> 
> > (Just for easy tracking of this thread, I am slighly changing the 
> > subject)
> >
> > As I described in this draft, 3736 is definitely subset of 
> 3315, thus, 
> > a host implementing 3315 can do both or either Stateful DHCPv6 for 
> > configuring the IPv6 address and Stateless DHCPv6 for the other 
> > information. Also M=1/O=0 can be invalid state based on 
> admin policy.
> > However, originally we tried to propose what scenarios with 
> M/O flags 
> > were possible. It means that we did not enforce any 
> specific scenario 
> > in this document because it can be easily done by admin policy.
> > Thus, I (personally) would keep this combination in valid state.
> >
> > Besides, as jinmei indicated earlier as editor of 2462bis, 
> M flag (ON) 
> > indicated that the host (should) use the stateful protocol 
> for address 
> > autoconfiguration. This should mean the M flag (ON) indicates 
> > Solicit/Advertise/Request/Reply.
> >
> >
> >
> > - Daniel (Soohong Daniel Park)
> > - Mobile Platform Lab. Samsung Electronics.
> >
> >
> >
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Thu, 19 Aug 2004 13:30:37 +0100

Hi Jim,

I thought we had reached a concensus that the O/M flags were now only hints,
as part of the IPv6 Node Requirements text (in 4.5.5 and 5.2), and the 
2462-bis update, under Section 5.2.

On the requirement to implement stateless support in nodes, it's only a 
MAY in the Nodes Requirements draft, but with a health warning:

4.5.5 Stateful Address Autoconfiguration

   Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
   3315] is the standard stateful address configuration protocol; see
   section 5.3 for DHCPv6 support.

   Nodes which do not support Stateful Address Autoconfiguration may be
   unable to obtain any IPv6 addresses aside from link-local addresses
   when it receives a router advertisement with the 'M' flag (Managed
   address configuration) set and which contains no prefixes advertised
   for Stateless Address Autoconfiguration (see section 4.5.2).
   Additionally, such nodes will be unable to obtain other
   configuration information such as the addresses of DNS servers when
   it is connected to a link over which the node receives a router
   advertisement in which the 'O' flag ("Other stateful configuration")
   is set.

I recall the DHCP M/O flag processing text in the Nodes Requirements draft 
in 5.2 was written in a way to avoid stating must or may for the processing
of M/O flags, so that RFC2462-bis is the definitive guidance.

I think Node Requirements is now rev 10 after IESG feedback(?) so is
pretty much final (but I may be wrong :)

Tim

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Aug 2004 14:31:06 +0200

> for clients.  That is the bottom line.  How we say it seems to be still

I agree with this. I have one concern though.

There must be a way to support different types of clients. On a link
there may be both full fledged DHCP clients that needs to receive
IPv6 addresses with DHCP, and some other DHCP clients that can only
do stateless (or need only stateless). In the latter case the clients
may have manually configured IPv6 addresses, or use IPv4 or whatever.

In that case, there must be a way to tell the full fledged clients
that they should use DHCP to configure addresses, while at the same
time allow some DHCP clients to use stateless.

If you say all clients MUST do stateful or all clients MUST do
stateful...

I believe there must be a way for an administrator to allow the
scenario I describe above.

I'll try to stay away from this thread now,

Stig