RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt

["Bernie Volz \(volz\)" <[e-mail]>]

BTW, if you want to look at this from the router administrator's
perspective:

Configure the router to send the M flag set in routing advertisements
for a Link IF:
1. A stateful DHCP server is deployed for that link (either on it or
reachable via a relay agent) AND
2. At least ONE or more prefixes the router is advertising for that link
are NOT configured for stateless auto-configuration.

Configure the router to send the O flag set in routing advertisements
for a link IF:
1. A stateful or stateless DHCP server is deployed for that link (either
on it or reachable via a relay agent) AND
2. At least ONE or more prefixes the router is advertising for that link
ALLOW stateless auto-configuration OR there are resources available to
the clients on that link that are reachable via link-local addresses
(such as an SNTP server). The latter may change over time depending on
what other configuration settings are available, but with the present
set of IETF options there is little value in providing any of the other
configuration settings if the client can only use link-local addresses.

So, the 4 possible combinations of the M&O bit may appear and be used.

For example, the M may be set but the O clear if no stateless auto
configuration for any address is possible (and there are no link-local
resources available to the client that can be configured via DHCP).

The M may be clear if there are no stateful addresses for the link. In
this case, the O would be set if there are more than link-local
addresses advertised.

Both the M & O would be set if one or more stateful addresses is
present, but stateless addresses are also available. Clients that don't
support stateful would still need the other configuration parameters and
could likely communicate with those resources since they have
non-link-local addresses.

- Bernie

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Bernie Volz (volz)
> Sent: Monday, May 16, 2005 9:56 AM
> To: JINMEI Tatuya / ????; Pekka Savola
> Cc: [e-mail]; IPv6 WG; Ralph Droms (rdroms)
> Subject: RE: [dhcwg] Re: IPv6 WG Last
> Call:draft-ietf-ipv6-ra-mo-flags-01.txt
>
> I haven't followed this thread carefully, but are you trying
> to suggest
> that if the M flag is set but O is not, that a client would IGNORE the
> other configuration parameters received from a DHCP server in a
> Solicit/Advertise/Request/Reply sequence? That seems very bad
> to me. And
> a waste of resources to have to do two sets of transactions
> (Solicit/Advertise/Request/Reply for addresses and
> Information-Request/Reply for other configuration).
>
> I really don't understand why this issue has been so difficult to
> resolve.
>
> In IPv4, DHCP is often the default unless you explicitly configure an
> interface or turn DHCP off. We don't have ANY network wide
> configuration
> for this. And it works very well indeed.
>
> In IPv6, the M and O flag should serve as hints. Period. A host is
> perfectly free to do what it wants (or what it has been configured to
> do).
>
> The M flag, if set, means a host SHOULD do full-RFC 3315. This means
> they should attempt to Solicit, but can also fall back to
> Information-Request if needed. This means both addresses and other
> configuration are configured, if available.
>
> The O flag, if set, means a host SHOULD do RFC 3376 (partial
> RFC 3315).
>
> If both flags are set, hosts that can do full RFC 3315 do it
> (and ignore
> the O flag). Those that can only do RFC 3376, do that.
>
> If no flag it set, hosts may still do RFC 3315 and/or 3376 if so
> configured (whether by default or otherwise). There should be no
> prohibition against doing that. The document need not say this - it is
> implied because we MUST NOT use MUST or MUST NOT. Just SHOULD
> or SHOULD
> NOT when taking about the bits.
>
> - Bernie
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of [e-mail]
> > Sent: Saturday, May 14, 2005 4:36 AM
> > To: Pekka Savola
> > Cc: [e-mail]; IPv6 WG; Ralph Droms (rdroms)
> > Subject: [dhcwg] Re: IPv6 WG Last
> > Call:draft-ietf-ipv6-ra-mo-flags-01.txt
> >
> > >>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST),
> > >>>>> Pekka Savola <[e-mail]> said:
> >
> > >>>> I can think of several possible resolutions:
> > >>>>
> > >>>> 1. just say that it's host/network administrator's
> > responsibility to
> > >>>> provide consistent parameters/configurations.  In this
> sense, the
> > >>>> combination of a) and b) above is just a configuration error.
> > >>>> This would be the most lightweight resolution for the
> authors:-),
> > >>>> but I personally think it's irresponsible.
> > >>>
> > >>> I agree as well.  This is not good enough.
> > >>
> > >> I think it's perfectly reasonable to assume that a configuration
> > >> mismatch is admin error and leave it at that - in this
> > case, the RAs are
> > >> configured incorrectly, promising that a non-existent
> > address assignment
> > >> service is available.
> >
> > > That would be consistent if the presence of M-flag would
> > only trigger
> > > DHCPv6 for address assignment, but DHCPv6 would not be used to
> > > configure anything else at all unless O-flag was also
> appropriately
> > > set.
> >
> > > Then the DHCPv6 and DHCPv6-lite would function in a
> similar fashion
> > > from the network administrator's perspective.
> >
> > > So, IMHO, either we must require O flag always for Information
> > > Configuration (whether DHCPv6 full or lite) or support the
> > > administrators who can't make out the subtle difference about the
> > > appropriate configuration of the flags.  For that, guidance
> > for full
> > > DHCPv6 implementers to also try emulating DHCPv6 lite would
> > probably
> > > be sufficient.
> >
> > I've been thinking about this issue for a while, and I now
> feel it may
> > require a more profound discussion than I originally thought...
> >
> > Here are some background points:
> >
> > - In original RFC2462, if ManagedFlag (host's variable corresponding
> >   to the M flag of RA) is TRUE, it implicitly means
> OtherConfigFlag is
> >   also TRUE (Section 5.2).  It would mean if we receive an RA with
> >   M=on (whether O=on or off), the receiving host would start the
> >   "stateful" protocol (which we now know is DHCPv6) for address
> >   configuration *and* the "stateful" protocol for configuration
> >   information excluding addresses (Section 5.5.3).
> >
> > - In the past discussion about the M/O flag document, we clarified
> >   that the notion of "M" and "O" is quite independent.  That is, "M"
> >   means the "Host Configuration Behavior", which, more specifically,
> >   means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O"
> >   means the "Information Configuration Behavior", which means DHCPv6
> >   an Information-request/Reply exchange.  Unlike RFC2462,
> there is no
> >   implicit dependency between "O-Flag" (renamed from OtherConfigFlag
> >   to avoid confusion) and the M flag in this document.  So, for
> >   example, the host does not invoke the "Information Configuration
> >   Behavior" just because the M flag in an RA is ON.
> >
> > I guess the slightly different sense led us to the current confusion
> > (or problem).
> >
> > If we respect both the original sense of RFC2462 and our consensus
> > about the semantics separation of the M/O flags, I believe the right
> > solution is the following:
> >
> >   - allow (or even require) running the Host Configuration Behavior
> >     and the Information Configuration Behavior concurrently. (note:
> >     this is a significant change from the current M/O document)
> >   - note that the same type of configuration information (e.g.,
> >     recursive DNS server addresses) can be obtained with those two
> >     behaviors, and that how to deal with possible inconsistency is
> >     beyond the scope of the M/O document.
> >   - also note that the network administrator should by
> default provide
> >     the Information Configuration Behavior when they
> provide the Host
> >     Configuration Behavior, in which case both the M and O flags
> >     should be set to ON in router advertisements.
> >
> > With the last notice, I'm fine with the position of saying "it's
> > administrator's responsibility to ensure service consistency".
> >
> >                                     JINMEI, Tatuya
> >                                     Communication Platform Lab.
> >                                     Corporate R&D Center,
> > Toshiba Corp.
> >                                     [e-mail]
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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