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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 19 Aug 2004 15:11:42 -0400

Hi Tim,

Hints Node Reqs I agree.  Hints in others I never agreed to at all.
That does not mean that is not the case but lets be clear here people
are running agendas and that is a fact.  DHCPv6 will be used by users
and required.  If we do draft language that states its MAY and we feel
we have consensus that is fine but I will keep I-TOLD-YOU-SO cards on
all who supported it when the market barfs on it :--).  Seeing the mail
I believe it was still for debate.  Declare victory Tim and we can move
on but don't be so naieve to believe the entire market is going to use
stateless because we say so that will not happen.  At this point I
prefer completed drafts to RFC is my priority.  Regarding the matrix m/o
all are possible and should be supported.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tim Chown
> Sent: Thursday, August 19, 2004 8:31 AM
> To: [email-masked]
> Subject: Re: M=1/O=0 is not valid in full 3315 ?
> 
> 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
> 
> On Thu, Aug 19, 2004 at 07:59:00AM -0400, Bound, Jim wrote:
> > 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
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> 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: "S. Daniel Park" <[email-masked]>
Date: Fri, 20 Aug 2004 14:57:13 +0900

(slightly changing the subject of this thread to follow up what we saying easily)

As I indicated previous mail, original intent of M/O flags document 
is same as what Christian said. This intensity of this document was
originally from the 2462-bis (IMO) and even Node Requirement as well.

But, as authors of this document, I am open this issue for moving
it forward.

p.s., I'd close the previous issue of whether M=1/O=0 is not
valid in full 3315 or not. IMO, the consensus is,

M=1, O=0 is valid combination as described in this document.

Let me know your view on this if I am missing anything.

---

From: Tim Chown <[email-masked]>
Date: Fri, 20 Aug 2004 14:51:31 +0100

Hi Jim,

I fully support that fact that managed DHPCv6 environments will be required,
and our site is/will be one of them :)   So there's no "victory" here until
support for full DHCPv6 is out there, for clients, servers, relay agents,
etc... if you believe I'm advocating all-stateless that's not true.

Right now Section 4 of RFC2462-bis draft says :

   Router Advertisements contain two flags indicating what type of stateful
   autoconfiguration (if any) is available.  A "managed address
   configuration (M)" flag indicates whether hosts can use stateful
   autoconfiguration [RFC3315] to obtain addresses.  An "other stateful
   configuration (O)" flag indicates whether hosts can use stateful
   autoconfiguration [RFC3736] to obtain additional information
   (excluding addresses).

So it is a hint, but to me there's nothing there that doesn't suggest an
implementor shouldn't support RFC3315.   I would expect Microsoft, Sun,
Linux, BSD, Mac OS/X and HP :) system to all support that.   The hint is
in the availability, not the support (or that's the way I read it :)

Stig raises the interesting question that many sites (again, ours included)
will want/need to have nodes able to configure statelessly.  At present
to do that you must have RFC3736 support (for DNS, etc), so at present
I hope that all systems support RFC3736.   The interesting case is where
nodes that are managed and stateless are on the same link; how does then
one "enforce" managed for some nodes?

It's not clear yet where the line will be drawn between systems (clients
or servers) that provide RFC3315 support, those that provide RFC3736 support,
and those that have no support (so end systems can only get basic address
and router info, and require manual configuration or a dual-stack crutch
to get access to other services).   I'm guessing we'll see all server,
laptop and PDA OS's doing RFC3315, just because they may be deployed in that
environment, and such systems all have DHCPv4 functionality as a basic
provision now.   Do you see that being any different with IPv6?

Tim