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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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

> 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?

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.
					[e-mail]

> 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.

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