> > => 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:
 > 
 > do you mean the case when the flags are NOT set?  (I talked about the
 > case where the flags are "cleared").

=> Yes, sorry.

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

=> Yes ;)

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

=> Ok but if a host desicdes to waste time despite the network's
recommendation
to use stateless, what can we do? Clearing the flags clearly suggests the use
of stateless. If a host goes against that then there is no guarantees that
anything
will work.

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

=> Sure, but currently there is no standard alternative to DHCP for the O
flag.

Hesham

 > 
 >                                      JINMEI, Tatuya
 >                                      Communication Platform Lab.
 >                                      Corporate R&D Center, 
 > Toshiba Corp.
 >                                      [EMAIL PROTECTED]
 > 

========================================================
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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to