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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 16 May 2005 09:56:26 -0400

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Saturday, May 14, 2005 4:36 AM
> To: Pekka Savola
> Cc: [email-masked]; 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 <[email-masked]> 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.
> 					[email-masked]
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 18 May 2005 17:11:16 +0900

>>>>> On Mon, 16 May 2005 09:56:26 -0400, 
>>>>> "Bernie Volz (volz)" <[email-masked]> said:

> Solicit/Advertise/Request/Reply sequence?

Nope.  Not at all.

Perhaps I was just not very clear, but I basically agree with your
understanding (and opinions) below (and so do all of us, I believe).

In particular,

- I didn't intend to *force* a host (client) to take a particular
  action.
- I agree that the M or O flag is just a "hint" about available
  configuration methods.

And, in fact, in draft-ietf-ipv6-ra-mo-flags-01.txt we do not use any
"MUST" or "MUST NOT" with one exception which is actually a citation
from another document.  Also, we introduced separate "policy
variables" for hosts so that they can act based on their own decision,
regardless of the RA flags.

What I was trying to address is to avoid an undesirable situation for
hosts when not everything is perfectly working.

For example, consider the case where we provide both address
allocation via DHCPv6 and also the stateless service (the RFC3736
subset of DHCPV6) in a network.  As you mentioned in a separate
message, we can think of a scenario in which it makes sense for a host
to use the information provided via the RFC3736 subset but not use
address allocation via DHCPv6.  In this case, both the M and O flags
in RAs would be set to ON.

Now, suppose that there is a reachability trouble from a host to all
available DHCPv6 servers that provide the address allocation service,
but some of the RFC3736 DHCPv6 servers can be reached (I think this
can happen because the latter can be more lightweight.  For example,
some or all of routers in the host subnets would probably be able to
act as the RFC3736 DHCPv6 server without offering any addresses to be
allocated to the client).

Or worse, there may be a configuration error that the router
administrator sets the M flag ON while there is actually no address
allocation service via DHCPv6 available.  This is a special case of
the above "reachable trouble".

In such cases, if the host can still do meaningful operation (this can
happen, as you pointed out in a separate message) even without being
allocated global addresses via DHCPv6, it would want to get other
configuration information via the available RFC3736 service.

What I want to clarify in the draft-ietf-ipv6-ra-mo-flags-01.txt
document is to provide operational guideline for hosts in such cases.
Specifically, I proposed to explicitly allow the host to perform the
address allocation exchanges and the RFC3736 exchange concurrently in
that document.  Someone may want to point out that such a behavior is
not prohibited in RFC3315 and that we don't have to emphasize that in
a separate document.  But at least I was previously confused about
whether this is a valid behavior, so I believe it makes sense to
mention that explicitly.

And finally, I admit the above examples can be an issue only when
something unexpected happens (e.g., when the administrator
misconfigures the router, or under a reachability problem).  I
personally still think it makes sense to provide a guideline so that
the host can get as much configuration information as possible even
under a small administrative error (again, I'm not intending to
*force* a particular action for such cases).  But if many others think
this is too minor to mention the ra-mo-flags document explicitly, I'll
follow that decision.

Am I now clear enough?

(I believe this response also covers the rest of the messages in this
thread or some of the other messages talk about different things I
intended to discuss, so I won't explicitly reply to the other messages
for now.  If I still miss something crucial in the other messages,
please point it out.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

> That seems very bad to me. And

---

From: Thomas Narten <[email-masked]>
Date: Wed, 18 May 2005 12:29:20 -0400

Let me just start off by saying I pretty much agree completely with
what Bernie just said.

I've also reviewed this document, and I am really wondering what this
document is trying to achieve. It seems to me that its added a lot of
text (that IMO is not really needed). In particular, I don't think
either Section 6 or 7 are necessary or appropriate.

There are really only two behaviors a client should be doing. If a
client doesn't implement DHC, well, then it obviously shouldn't/can't
invoke DHC. End of story. If it does implement DHC, well, it should
use it. Moreover, it shold never really be a "client" choice whether
to invoke use DHC or not. If the sys admin has stuff available via
DHC, the client should (in the SHOULD sense) be getting it and using
it. Why on earth would we want to disable that via a configuration
knob?

Indeed, when I look at Section 2, "Background", I find that the
wording that it quotes from RFC 2461 really does say pretty much what
should be said. That is, these bits are "hints" that the local sys
admin has a DHC server that is giving out addresses and/or other
configuration information. Seems to me, if the local access network is
giving out config information, clients SHOULD try and get it, because
if they don't, they will presumably operate at some sort of reduced
level of functionality -- after all, if a sys admin set up a DHC
server, there must be a reason for this (e.g., to provide DNS
recursive name server service, addresses not available via stateless
addrconf, etc.).

So, these bits should just provide clients with a stronger indication
that they should be using DHC to get the information that is
available.

If the original 2461 text is really deemed insufficient, how about
something like:

   o  M :

      1-bit "Managed address configuration" flag.  When set, it
      indicates that addresses are available via Dynamic Host
      Configuration Protocol [DHCPv6], including addresses that were
      not configured via stateless address autoconfiguration.  Clients
      SHOULD use DHC to obtain addresses (and associated
      configuration information) as described in [ADDRCONF].  Note
      that when the M bit is set, the setting of the O bit is
      irrelevant, since the DHC server will return "other"
      configuration information together with addresses.

   o  O :

      1-bit "Other configuration" flag.  When set, it indicates that
      [DHCPv6lite] is available for autoconfiguration of other
      (non-address) information.  Examples of such information are
      DNS-related information or information on other servers within
      the network. When set, 

       - If the M bit is also set, clients SHOULD use DHC to obtain
         addresses (and associated configuration information) as
         described above.

       - If the M bit is not set, clients SHOULD use DHC as
         described in RFC 3736.

Is more than something like the above _really_ needed? If so, why?
	 
Thomas

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 May 2005 15:45:04 -0700

Thomas,

>Is more than something like the above _really_ needed? If so, why?

I agree and also don't see why more than this is needed.

Thanks,
Bob

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 20 May 2005 16:19:26 +0900

(Cleaning the Cc list a bit)

>>>>> On Wed, 18 May 2005 12:29:20 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> it. Why on earth would we want to disable that via a configuration

One possible case would be a server host which manually configures
itself with an IPv6 address, but seeks to get default router addresses
via an RA and possibly other configuration information such as
recursive DNS server addresses via DHCPv6 (Information-request/Reply).
Such a host would receive (and use) RAs but not invoke DHCPv6 for
address allocation even if the M flag is set in the RAs.

I personally also expect a host that does not implement address
allocation via DHCPv6 would have an implicit local policy that
"disables" the behavior (regardless of the value of the M flag).  But
I admit the current mo-flags document does not clearly indicate that
even if my expectation is reasonable.

On the other hand, I'd also like to allow a client to use DHCPv6
(either full 3315 or the 3736 subset) even if the corresponding M or O
flag is not set.  In particular, I'd reserve the possibility for a
host to try the RFC3736 behavior even if the O flag is off, so that
the host can get configuration information even when the RA flags and
available DHCPv6 are inconsistent (due to misconfiguration of routers,
etc).

> that they should be using DHC to get the information that is

In general, I agree (while I'd say "...that they can be using DHC
...").

> Is more than something like the above _really_ needed? If so, why?

"_really_" sounds subjective, and opinions may vary, but I personally
don't think "the above" is enough in practice.  In my understanding,
many people have been confused about the relationship between the M/O
flags and the "stateful" configuration protocol (we now know the
protocol is DHCPv6).  At least I, as an implementor, have been always
confused about these points.  For example,

1. whether the specification about the M flag indicates address
   allocation via DHCPv6 is a mandatory feature to be implemented in
   hosts.  (this point may now be clear by the "IPv6 Node
   Requirements" document and recent clarification of 2462bis)
2. whether it's valid for a host to not invoke DHCPv6 (either full
   RFC3315 or the RFC3736 subset) even if the corresponding M/O flag
   is set. (see above)
3. whether it's valid for a host to do invoke DHCPv6  (either full
   RFC3315 or the RFC3736 subset) even if the corresponding M/O flag
   is not set. (see also above)
4. what should the host do if the M or O flag is reset from ON to OFF.
   (while I pernsoally believe RFC2462 is pretty clear on this, many
   people, including a DHCPv6 specialist, have still misunderstood
   that.)
5. what if the M flag is set but the host does not get any DHCPv6
   Advertise in the initial exchange?  Is it okay to fall back to the
   RFC3736 subset?  Or is it even okay to run both full RFC3315 and
   the RFC3736 subset concurrently from the beginning?

If all we have is "the above" you suggested or the current 2461bis
wording, I'd still continue getting confused.  So I personally want to
clarify these points somewhere, either in an existing document or a
separate document like the ra-mo-flags draft.  As for the latter, I
don't stick to the current content.  Perhaps sections 6 and 7 are
overspecification, and I'll be happy as long as we can clarify the
points that have confused many people so far.

According to the others' opinions, however, all or some of the above
points seem to be so trivial to some people that they don't bother to
"clarify" those.  If I've been simply dull and things are so clear for
others, I don't mind killing the new clarification document (it would
reduce my responsibility:-).

					JINMEI, Tatuya

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 20 May 2005 13:53:34 +0530

> Let me just start off by saying I pretty much agree completely with

Even I do agrre, what Bernie said. I understodd from his mail, a node can
fall back to Information Configuration Behavior (DHCPv6 Lite) if ti fails do 
Full DHCP.
I am not sure if such infomation is available in handy somewhere.

Moreless the draft looks similar to what Bernie said except with more 
options
to control the invoking th DHCPv6 behaviour, e.g., If I know prettty sure 
that the DHCPv6
is not avaialble in the network my node is connected, I have not seen any 
reason why I should
let DHCPv6 be running in the background.

> it. Why on earth would we want to disable that via a configuration

If it is this simple, we do not really need the M/O flags in Router 
Advertisements.

> recursive name server service, addresses not available via stateless

Also it is not clear for nodes what they should if they receive these bits
ON to OFF and vise versa.

> Is more than something like the above _really_ needed? If so, why?

Currently for IPv4, we either select to get the address using DHCP, or 
configure manually.
At least this true in Windows OS.
Similarly, it is not bad idea to have options for IPv6 to select between 
DHCPv6, SLAAC or Manual or
combination of these. For an intelligent use he can furthe select options 
for DHCPv6 either to run all
the time or run only when host sees the M/O flag set. THis is what the 
policy the draft is talking about.

Of course I do agree that it it little heavy in the current form, which can 
be simplified.
I think it is worth clarifing these, and in any case the draft is not going 
to introduce any
changes to the existing standards.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 May 2005 06:37:55 -0400

Comments in line...

- Ralph

> address allocation even if the M flag is set in the RAs.

There's no particular reason why a host with an otherwise configured
address might not also use DHCP for other assigned addresses.  But, I
agree with you that use of DHCP in a host is a matter of local policy,
perhaps guided by the M/O bits.

> even if my expectation is reasonable.

This local policy seems to be a crucial issue.  Do we try to describe
host behavior explicitly or do we specify the network behavior (M/O
bits; retransmit behavior for ND and DHCP; HCB/ICB (Host Configuration
Behavior [RFC 3315]/Information Configuration Behavior [RFC 3736]
information returned from DHCP server) and leave the host to implement
its own policy and behavior?

> available DHCPv6 are inconsistent (due to misconfiguration of routers,

I don't see a reason to prohibit explicitly use of DHCP is M/O bits are
not set.  Other standards bodies or host implementors may choose to make
such prohibitions if appropriate; e.g., in a network environment with
limited bandwidth where any spurious traffic is avoided.

>    Requirements" document and recent clarification of 2462bis)

I agree that the requirement for DHCP has never been entirely clear nor
well-documented.

>    is not set. (see also above)

If there is confusion about these points, then we need clarification,
once we agree on the desired behavior and definition.

>    people, including a DHCPv6 specialist, have still misunderstood

RFC 2462 is pretty clear; however, I must admit I have been confused by
the lengthy discussion clarifying the meaning of the bits and I seem to
remember that there was a proposal to change the meaning of the bits at
some point in the discussion.

>    the RFC3736 subset concurrently from the beginning?

There is another possibility - a DHCP server that will not assign
addresses can respond to a Solicit message with an appropriate status
code.  Thus, a host that tries to use HCB first can get an immediate
indication that HCB is not available and revert to ICB immediately.

Deployment of such behavior may require some clarification in the DHCP
RFCs, because the existence of two separate RFCs has led to confusion
about the "separation" of two "different" protocols for HCB and ICB.
There is no *prohibition* against a DHCP server that intends to
participate only in ICB from responding to a Solicit message with the
"will not assign addresses" ("NoAddrsAvail")._DOa.

Additionally, a small, backward-compatible extension to RFC 3315 would
simplify the situation even further.  At present, RFC 3315 specifies
that a server return the NoAddrsAvail status code and no other
information.  If the server were allowed to return NoAddrsAvail *and*
ICB options, the host could use the ICB options with a simple 2-message
exchange.  This extension would also require a clarification to RFC 3736
explicitly allowing this behavior (Note that RFC 3736 is intended as
*minimum* function and does not *prohibit* implementation of other DHCP
features).

> 					[email-masked]

In my opinion, we need a simple clarification of M/O bits as "advisory"
and that there is no explicit *restriction* on hosts' use of DHCP.  We
might also consider a couple of clarifications and minor extensions to
the DHCP spec to optimize host-server interaction.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 May 2005 07:39:19 -0400

The discussion of M/O bits caused me to think about the meaning and
specification of host behavior for M/O bits and for SLAAC.  In
particular, I'm trying to understand the degree of control over host
behavior specified in both cases.

I'll focus here on what I can understand about SLAAC, because we've been
discussing the M/O bits in a separate thread.

One part of the specification in section 5.5 of RFC 2462 seems pretty
clear:

5.5.  Creation of Global and Site-Local Addresses

   [...]
   Creation of global and site-local addresses and configuration of
   other parameters as described in this section SHOULD be locally
   configurable. However, the processing described below MUST be enabled
   by default.

I read this to mean that the information in the RAs is advisory.  

In section 5.5.3 of RFC 2462, the following text seems to imply that the
"autonomous address-configuration flag" (A bit) controls whether a host
forms a SLAAC address for a prefix:

    a) If the Autonomous flag is not set, silently ignore the
       Prefix Information
       option.

But, there is no RFC 2119 language, and the earlier text allows for
local host configuration, so it's not clear if a host is compliant with
RFC 2462 if it forms a SLAAC address from a prefix advertised with the
A-bit not set.

Later in the same list of behaviors:

    d) If the prefix advertised does not match the prefix of an address
       already in the list, and the Valid Lifetime is not 0, form an
       address (and add it to the list) [...]

This text also does not contain RFC 2119 language, so it's not clear
that a host is required to form an SLAAC address from a prefix
advertised with the A-bit set.

While open to interpretation, I read the text about SLAAC addresses to
be advisory, which would give roughly the same control over host
behavior as interpreting the M/O bits as indicating the availability of
DHCP services, but not requiring specific behavior on the part of hosts.

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 May 2005 13:47:25 -0400

> address allocation even if the M flag is set in the RAs.

There is nothing wrong with the above case. But, I don't think we need
our specs need to say anything about them either. There are always
going to be lots of scenarios where a vendor may want to do things
differently than implement _only_ what the spec says _explicitely_.
Thus, I see no reason to go into a lot of detail in one our specs
supporting this particular scenario or "allowing" it to be "part of
the standard" so to speak.

That is, vendors always implement additional knobs/whistles as they
see fit. The IETF doesn't need to account for all of those.

What we our specs do need to support is not disallowing behavior that
it might make sense to allow for, and that doesn't negatively impact
interoperability and such.

The above should be perfectly consistent with our existing specs. Do
you (or others) feel otherwise? I.e., is the above not allowed by our
specs?

> even if my expectation is reasonable.

I do not understand the concept of having a local policy that disables
invoking a service that one has not implemented. If you don't
implement it you don't implement it, and anywhere you might consider
invoking the service, well, you obviously just don't. That is not a
"local policy", that is just common sense. :-)

It has never been the case that if something is not in an IETF spec,
it is "disallowed" or "not compliant" with a spec. If we go down that
road, one ends up having to overspecify everything to make sure even
obvious things are allowed.

What our specs _do_ need to do is be very clear on what we expect all
implementations to do, in order to achieve interoberability (and to
prevent damaging behavior, as in, e.g., being congestion unfriendly).

> flag is not set.

I agree that this  should be allowed. Indeed, I'd expect that to be the default
behavior regardless of the M/O bits. It should be the default behavior
of anyone that implements DHC.

No where in our specs (AFAIK) is it claimed that you SHOULD/MUST NOT
invoke DHC if the M/O bits are clear. Right?

> In particular, I'd reserve the possibility for a

Is there any wording in our specs that suggests a client is not
allowed to invoke DHC if either of the M or O bit is off? If not, why
do people feel that they are not allowed to invoke DHC?

>    Requirements" document and recent clarification of 2462bis)

The RA bits should have no bearing in answering that question. They
are advisory only.

I think folk have already made it clear that DHC on clients is not
"mandatory to implement as part of IPv6".

If that is the question you really have, this document is the wrong
way to ask/resolve it.

Another way of looking at things. Does the fact that someone can send
a node a TCP SYN packet require (in the MUST sense) that the client
respond to that SYN?

Likewise, if an RA says "DHC is available", that doesn't mandate that
it invoke DHC either. (but the node SHOULD do so...)

>    RFC3315 or the RFC3736 subset) even if the corresponding M/O flag

That is why I suggested "SHOULD invoke DHC". Makes it clear you
should, but there are cases where you might not want to, so no, it is
not mandatory to _invoke_ (mandatory to implement is covered in the
previous question).

>    is not set. (see also above)

should be, IMO. The bits do not mean "if 0, you MUST NOT use DHC ..."

>    people, including a DHCPv6 specialist, have still misunderstood

On to off? nothing. Let DHC continue to be used. The DHC protocol will
do what it normally does if a DHC server goes away... I.e., if you've
gotten config information from DHC that still has a valide lifetime,
you wouldn't throw that information away...

>    the RFC3736 subset concurrently from the beginning?

Should be legal, but this is an unfortunate situation, since we're not
trying getting into how to deal with misconfigurations...

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 21 May 2005 04:31:56 +0900

>>>>> On Fri, 20 May 2005 13:47:25 -0400, 

> you (or others) feel otherwise? I.e., is the above not allowed by our

(Perhaps it's not wise to continue this thread while we are in the
separate "meta" thread, but)

I believe we've basically agreed on each technical point (e.g.,
whether a host can perform DHCPv6 based on its decision/policy even if
the corresponding M/O flag is off; the answer is "it can").  The real
point in this thread is, at least to me, as follows:

It's the fact that people have actually been confused about these
points.  We now know the answers to the questions, but I'm quite sure
new implementors will ask the same questions in the future, since most
of the background rationale is implicit, e.g., "this is valid since no
specification explicitly prohibits it", and we'll continue answering
the questions by saying "yes, it's valid because no specification
explicitly prohibits it".

I don't know if such confusion is just usual in the IETF
specifications or there is something special for the M/O flags and
DHCPv6 case, due to, for example, partly overwrapping functionality of
"Host Configuration Behavior (full RFC3315)" and "Configuration
Information Behavior (RFC3736 subset)" or other complexity you
mentioned in the other thread.

I personally think this is the latter case, and it makes sense to
clarify these points explicitly in order to help future implementors
(and ourselves by avoiding seeing/answering the same questions again
and again).  If I don't misunderstand him, Ralph also seems to think
some clarification is useful.

On the other hand, you and some other guys seem to regard this as a
usual case which does not require explicit clarification.  If this
group is the majority, I won't fight against it; at least I now know
the answers to the questions, so (hopefully) I won't be confused any
more:-)

					JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 May 2005 16:15:13 -0700

Hi,

I would like to second the point Jinmei made, that we had something very 
close to this discussion about a year ago.

Also, I am not sure I understand what the problem is regarding knowing when 
to try using DHCPv6.  For practical purposes, if there isn't a router 
present (indicated by the RAs it sends) is very unlikely that there will be 
a DHCPv6 server either (or it won't be reachable because the router is 
down).  If the "m" and/or "o" bits are set in a RA, it is a pretty good 
hint that a host might try to use DHCPv6 and see what it gets.  If the "m" 
or "o" bits are not set, then it's a pretty good hint that there isn't much 
sense in trying to use DHCPv6.

Is something else needed?

Bob

---

From: Pekka Savola <[email-masked]>
Date: Sat, 21 May 2005 07:51:34 +0300 (EEST)

On Fri, 20 May 2005, Bob Hinden wrote:
> to try using DHCPv6.  For practical purposes, if there isn't a router present 
> (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 
> server either (or it won't be reachable because the router is down).  If the 
> "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host 
> might try to use DHCPv6 and see what it gets.  If the "m" or "o" bits are not 
> set, then it's a pretty good hint that there isn't much sense in trying to 
> use DHCPv6.

Actually, the lack of M or O bits is not as good a hint as their 
existence.  If we wanted a _good_ hint about non-existence of DHCPv6 
(for addresses or config information), we'd have to have different 
flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in 
this network".  That allows disambiguation from "Yes, we do have a 
couple of DHCPv6 servers, but we weren't aware you should configure 
this stuff in the RAs, because with v4 you don't".

But I'm not sure that disambiguation is worth the effort.

That said, I support the clarification.  In a sense I agree with 
Thomas et al that the ra-mo-flags spec goes beyond the bare minimum 
what the IETF specifications must specify -- it documents the policies 
and behaviours which most vendors would implement in any case, but 
these kind of knobs have often been left out of our specs.  However, 
as there has been so much confusion and discussion of M/O flags, I 
think this specification is useful, and also allows vendors (who want 
to) to implement the knobs in a uniform manner.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bob Hinden <[email-masked]>
Date: Mon, 23 May 2005 09:48:50 -0700

Pekka,

>existence.  If we wanted a _good_ hint about non-existence of DHCPv6 (for 
>addresses or config information), we'd have to have different flag(s) like 
>"Yes, I'm aware of what DHCPv6 is, but we don't use it in this 
>network".  That allows disambiguation from "Yes, we do have a couple of 
>DHCPv6 servers, but we weren't aware you should configure this stuff in 
>the RAs, because with v4 you don't".

This still seems to be to be fairly equivalent.  I think the important 
function is if there is a DHCPv6 server and the site want the clients to 
use it, then they should set the "m" and "o" bits.  I don't see very much 
value in conveying the negatives (e.g., we have a DHCPv6 server, but we 
don't want the clients to use it, we don't have a DHCPv6 server so don't 
try looking for one, we didn't set up a relay, etc., etc.).

>But I'm not sure that disambiguation is worth the effort.

Agreed.

>That said, I support the clarification.  In a sense I agree with Thomas et 
>al that the ra-mo-flags spec goes beyond the bare minimum what the IETF 
>specifications must specify -- it documents the policies and behaviours 
>which most vendors would implement in any case, but these kind of knobs 
>have often been left out of our specs.  However, as there has been so much 
>confusion and discussion of M/O flags, I think this specification is 
>useful, and also allows vendors (who want to) to implement the knobs in a 
>uniform manner.

Part of me is starting to think that we might be better off waiting for 
there to be more operational experience with deployments of DHCPv6 to see 
how much confusion there really is.  I agree it is good for vendors to 
implement similar knobs, but I wonder how much of a problem there really is.

Bob

---

From: Tim Hartrick <[email-masked]>
Date: 23 May 2005 10:09:20 -0700

Bob,

> implement similar knobs, but I wonder how much of a problem there really is.

More than part of me is thinking this.  It seems to me that there is a
continuing confusion about how these bits interact with local decisions
by the administrator of a specific machine or network.  People are
asking questions like "What happens if the M and/or O bits are clear but
there is a DHCP server?" or "What happens if the M and/or O bits are
clear but the client wants to use DHCP anyway" or "What happens if the M
and/or O bits are set and the client doesn't want to run DHCP".  None of
these questions are in the realm of protocol design.  Clearly, local
administrators will do as they please with their machines.  In this
respect the M and O bits have never been anything but strong hints as to
what the client should do.  The client is always free to ignore the
hints.  Further network administrators are free to misconfigure their
networks as they please.  The current text describing these bits is
clear almost to the point of being infantile.  This isn't an indictment
of the authors.  Rather it is an indictment of attempts to enforce
system configuration and management rules via protocol specifications. 
This is impossible.  We should stop trying.

tim

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 May 2005 08:50:44 -0400

> this stuff in the RAs, because with v4 you don't".

Huh?

> to) to implement the knobs in a uniform manner.

So which do you recomend - a minimum spec like Bob and Thomas have
suggested or a more detailed spec like the current ra-mo draft?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 May 2005 14:46:36 -0400

Tim - I agree 100% with your message.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 May 2005 14:49:55 -0400

Bob - we ought to see what other standards bodies (for example,
CableLabs) identify as address assignment requirements and design as
IPv6 deployment architectures.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 24 May 2005 06:23:25 +0900

>>>>> On 23 May 2005 10:09:20 -0700, 
>>>>> Tim Hartrick <[email-masked]> said:

> This is impossible.  We should stop trying.

First of all, as a part of the authors of the "infantile" document,
I'd like to emphasize once again that it's not our goal to *enforce*
system configuration issues through a protocol document.  Perhaps the
current text is overacting, but the goal is to "clarify" (as the title
of the document shows) confusing points about the M/O flags.  (You
seem to agree that there *is* confusion, but are saying that
clarifying those points is not IETF's work, correct?)

Anyway, regarding Bob's point, I can live with that.  In fact, my
position of these bits has always been we don't have much experience
with these flags to be more specific about their usage.  And that's
why I hesitated to describe more details about those flags in
rfc2462bis.

On top of this fact, I can live with the approach of leaving the
current confusion as is and waiting until we get enough operational
experience (then we may or may not need a separate document).

Before actually taking this approach, however, I'd like to make
a couple of additional notes beforehand:

- we removed from rfc2462bis some statements regarding the M/O flags
  and the "stateful" protocol (=DHCPv6), such as this one:

     If the value of ManagedFlag changes from FALSE to
     TRUE, and the host is not already running the stateful address
     autoconfiguration protocol, the host should invoke the stateful
     address autoconfiguration protocol, requesting both address
     information and other information.

  or one even with an RFC2119 keyword:

     In particular, a host MUST NOT reinvoke stateful address
     configuration if it is already participating

  with the intention of clarifying these points in the
  ipv6-ra-mo-flags document.  If we stop this work, it means these
  statements will simply disappear.

- rfc2461bis will also need to remove the last sentence from the
  description of the M/O flags:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that Dynamic Host Configuration
                     Protocol [DHCPv6] is available for address
                     configuration in addition to any addresses
                     autoconfigured using stateless address
                     autoconfiguration.  The use of this flag is
                     further described in [ADDRCONF].

  (this comment already applies regardless of the future of
  ra-mo-flags, since [ADDRCONF](=rfc2462bis) does not talk about these
  flags anymore)

					JINMEI, Tatuya

---

From: Tim Hartrick <[email-masked]>
Date: 23 May 2005 15:36:02 -0700

Jinmei,

> clarifying those points is not IETF's work, correct?)

I made it clear that the current text is, I believe, a reaction on the
authors' part to the persistent attempts to place operational
restrictions on this protocol mechanism from within the specification. 
The clarity is good.  I am for clarity.  I apologize for any offense. 
However, I am against continuing to modify the document and the protocol
in the hopes that the questions cited above will cease.  They won't
because they have nothing to do with the protocol.  They have to do with
operators wanting to tell users how to use their machines and users not
wanting to do what operators want them to do and how that tension gets
sorted out by what features and knobs are included or not included in
the implementations the operators and users purchase.  We aren't writing
product specifications here.  Trying to specify every implementation
knob in the protocol specification is a mistake and removing useful
features because all the possible knobs to control it aren't specified
is also a mistake.

tim