>>>>> On Tue, 24 May 2005 11:35:41 -0400,
>>>>> "Bernie Volz (volz)" <[EMAIL PROTECTED]> said:
> I believe were there are issues are in the details about what each bit
> means and how they interact and what happens if they're not set
> correctly.
> Personally I think the last issue should be a non-issue since there are
> plenty of other parameters that need to be set correctly for networks to
> run. At worst, this causes clients not to get addresses (which will
> likely generate complaints to the network administrators fairly quickly)
> or wastes bandwidth.
I agree. While I have repeatedly mentioned the latter case, I
actually don't care about the case where a client cannot get addresses
via DHCP due to incorrect M/O flags and/or misconfigured DHCPv6
servers. In this case, the user can do nothing but complain to the
administrator.
I'm more concerned about the case you mentioned in the succeeding
lines (below), and it looks we are in some level of agreement.
> If we assume that current bits are retained, there is a problem if both
> the M and O bits are set with what a client should do if it supports
> both stateful and stateless DHCPv6 but fails to receive responses to
> Solicit requests.
> If the client only supports stateless DHCPv6, there is no issue since it
> just sends Information-Request messages.
> But if the client supports both (really this means it is a "full" 3315
> client), does it do both in parallel, initiate stateful (Solicits) and
> failover to stateless at some point (and does it continue to do stateful
> in the background), or? These areas that are not well documented in the
> DHCPv6 specifications (3315 + 3736) and we need to clarify. We've
> discussed several proposals but I don't think we've closed that
> discussion.
Exactly. This is one of my major concerns, which I've been trying
to address through the mo-flags draft with my co-authors (although we
may not have been convincing enough in that work so far).
> Thus, I would suggest we:
> - Have one bit that says "run DHCPv6". If the client is stateful, it
> does "full" 3315". If the client is stateless (3736), it does stateless
> only.
> - Have the DHC WG publish a draft to properly define the behavior of
> clients (and servers) when stateful service is not available and only
> stateless is available. IE, when should a client switch to using
> Information-Request or should all servers support Solicit and should an
> Advertise be able to carry "other configuration" options when addresses
> are not available. (Or perhaps there are other options to be
> considered.)
If we can get the DHC draft soon (it's okay even if it's just an I-D),
I think this is a reasonable approach. But since this (the first
bullet more specifically) clearly results in a "backward-incompatible"
change, we'll need a meta-level agreement for this approach. (In
particular, we should consider how this affects the rfc2461bis work as
an urgent issue)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
