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 PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Ralph Droms
> > Sent: Wednesday, August 18, 2004 7:01 AM
> > To: [EMAIL PROTECTED]
> > 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 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
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
