On Fri, 5 Nov 2004 23:19:46 +0200 (EET),
Pekka Savola <pekkas@xxxxxxxxxx> said:
Information Configuration Behaviour:
configuring other information excluding addresses through
Information-request and Reply exchanges
For full clarity, I'd suggest s/Reply/Information-reply/ above, as I
think it was what you meant.
No, it's surely "Reply". According to RFC3315, the response to
Information-request is also a Reply message, and there is no
Information-reply defined.
But your main point still stands, and I agree this is a problematic
case. I'd first note I don't think it's a true-or-false thing; we're
just going to define the most reasonable behavior, and this is its
first step. The background of this statement is the dependency
described in Section 6, which was originally stated in RFC2462, that
if we invoke Host Configuration Behaviour we basically should not
invoke Information Configuration Behaviour.
I'm not sure if I followed this background statement. My assumption
has always been that 'host configuration behaviour' would always also
include information config as well; a "less specific prefix" in a way
:). But I may have missed some earlier consensus or did not read too
carefully. (There would certainly be no way to stop Full DHCPv6
client from getting back all the ancillary information in addition to
the addresses, right?)
Your assumption is correct. More clearly, when we exchange
Solicit/Advertise/Request/Reply messages, we usually get some IPv6
addresses allocated as well as other configuration information such as
recursive DNS server addresses. In our draft we call it "Host
Configuration Behaviour".
On the other hand, when we exchange Information-request/Reply
messages, we only get "other" configuration information. We call it
"Information Configuration Behaviour".
Are we synchronized so far? If so, which part of the background
didn't you follow?