Subject: RE: [rfc2462bis] relationship between M/O flags and related protocols

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 13 May 2004 11:08:04 -0400

Some answers below.

 > So far, many people seem to have (somehow) agreed on what Christian
 > said (attached below): the M/O flags should just be hints of
 > availability of the corresponding services (or protocols) rather than
 > a trigger to invoke the protocols under a certain level of 
 > requirement.
 > 
 > While some part of his interpretation (i.e., "do DHCP, and only if it
 > fails do auto-config") was not really accurate according to the
 > specification as others already pointed out, I still think he made
 > important points, in that RFC2462 has "supposedly mandatory nature"
 > with ambiguity on details.

=> Before I attempt to answer the questions below I'd like to
clarify that we already have a Node requirements doc which
states what RFCs, and to some extent functions within RFCs,
should be supported and the level of such support.

 > 
 > An example of the "mandatory nature" is the following sentence of
 > Section 5.5.3:
 > 
 >    If the value of ManagedFlag changes from FALSE to
 >    TRUE, ..., the host should invoke the stateful
 >    address autoconfiguration protocol, ...
 > 
 > The "ambiguity" includes:
 >   - the level of requirements (e.g., should the above "should" be
 >     actually SHOULD?, etc)

=> I don't know if it's a requirement to have upper case. RFC2460 has no
upper
cases and several other IPv6 RFCs (especially those edited by Steve Deering)
have no upper cases at all.

 >   - what is the protocol to be invoked by this statement (we are now
 >     trying to clarify this point)

=> Right.

 >   - what hosts should do if the M/O flags keep being cleared; e.g.,
 >     does this mean the hosts should not invoke the protocols?

=> Stateless is a MUST according to the Node requirements. Now, if an
implementation
decided to use DHCP when the flags are set, then there are two cases to
consider:
 a. No DHCP server. This will be discovered pretty soon.
 b. DHCP exists and address is allocated
 c. DHCP exists but since admin doesn't want it to be used for address
allocation
    it won't allocate an address. 

All of those cases will render a definite outcome so there is no need to tell
the 
host what to do in this case. I.e. no interop issues.

 >   - what if the hosts do not implement the stateful protocol? (recall
 >     that in the node requirements document it is basically 
 > optional to
 >     implement DHCPv6 for the stateful address configuration)

=> It doesn't work! It only gets a link local address.

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 14 May 2004 00:32:59 +0900

Quick checks:

>>>>> On Thu, 13 May 2004 11:08:04 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> decided to use DHCP when the flags are set, then there are two cases to

do you mean the case when the flags are NOT set?  (I talked about the
case where the flags are "cleared").

And you actually meant "three" cases to consider instead of "two":-)

> host what to do in this case. I.e. no interop issues.

Not sure about your intention, but a few additional clarifications:

Detecting non existence of DHCPv6 servers is a quite time-consuming
process rather than "pretty soon", at least protocol-wise.  In fact,
according to RFC3315, we can never "detect" the non existence since
MRC and MRT are both 0 for DHCPv6 solicit and information request
messages, which means we should try to find servers forever.

Also, when we are talking about the O flag, we should note that it
is not directly relevant to address allocation.

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