[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.txt



On Sat, 6 Nov 2004, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀãºÈ wrote:
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.

Sorry for misremembering (and not checking).

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?

When I read the draft, it struck that it tried to specify Host Configuration Behaviour as excluding Information Configuration Behaviour. That is, when both O and M flags would be set, and the policy would be appropriate, the host would try to run *both* Host and Information config behaviour, even if information config behaviour is already (implicitly) included in host config.


There is of course one corner case here: if a node running host configuration behaviour would omit separate information configuration behavior, in case there was no "full DHCPv6" server in the network, the host would not get even the Information Configuration unless DHCPv6 falled back to sending an information-request in some manner (such as we discussed).

Thus it seemed that in the current draft's specification, there were some (typically unnecessary) steps when both M and O flags are set and the policies set in a certain way, depending on how the DHCP specs are to be implemented to fall back when the server would only support information configuration.

Does that clarify?

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------