Ralph:
How do these changes help the situation?
Why don't we just deprecate the bits????
What value do these bits have if "The DHCPv6 client behavior in response
to the receipt of M and O flags is unspecified."
- Bernie
-----Original Message-----
From: Ralph Droms (rdroms)
Sent: Monday, October 06, 2008 9:31 AM
To: Thomas Narten
Cc: Ralph Droms (rdroms); [EMAIL PROTECTED]; DHC WG; IPV6 List
Mailing; Bernie Volz (volz); Brzozowski John
Subject: Re: [dhcwg] Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"
Thomas - you wrote:
> unless something has
> changed (and I have seen no indication of this), the WG should not
> take on this topic or discuss it further because there is no consensus
> to make any changes.
One part of the situation that may have changed - or, perhaps, wasn't
considered - is the case of implementors reading RFC 486[12] without
the knowledge of previous discussions of the M/O flags. How will
those implementors interpret the text in RFCs 486[12] and 246[12], and
how will they implement stack behavior for the M/O flags?
I ask because I've gotten questions on exactly this issue. In my
opinion, the previous discussions that lead to the current text in RFC
486[12] came to consensus that:
* M/O bits indicate availability of DHCPv6 services
* client behavior based on the availability based on M/O bits is
unspecified
I don't think that consensus is clearly described in RFCs 486[12].
However, I think the problem can be resolved with a couple of
sentences; e.g.:
* Add a new Note after the description of the M/O flags in Section 4.2
of RFC 4861:
Note: The DHCPv6 client behavior in response to the receipt of M
and O flags is unspecified.
* Add a sentence to the clarification in RFC 4862:
o Removed the text regarding the M and O flags, considering the
maturity of implementations
and operational experiences. ManagedFlag and OtherConfigFlag were
removed accordingly. (Note
that this change does not mean the use of these flags is
deprecated.) *The DHCPv6 client
behavior in response to the receipt of M and O flags is
unspecified.*
* Change the following sentence from Section 3 of RFC 4861:
For example, routers can specify whether hosts should use DHCPv6
and/or autonomous (stateless)
address configuration.
to:
For example, routers can specify whether DHCPv6 services are
available for address configuration and other
configuration information.
- Ralph
On Sep 17, 2008, at Sep 17, 2008,11:17 AM, Thomas Narten wrote:
> HYUN WOOK CHA <[EMAIL PROTECTED]> writes:
>
>> Hello, Thomas Narten and 6MAN folks.
>
>> I made a presentation for our draft "draft-cha-ipv6-ra-mo-00.txt" at
>> the 6MAN session in Dublin IETF. This draft aims to clarify the
>> handling of the M/O flags of IPv6 RA. Though I got several comments
>> during my presentation, I could not figure out what you really
>> pointed out. So, I decided to ask you again why you think that the
>> issues which the draft addresses are neither clear nor considered as
>> worthy to be discussed in the 6MAN wg.
>
> Meta point. This WG has (multiple times) over the last few years had
> discussions about what the best semantics for the M&O bits should
> be. Despite hundreds of emails, and multiple drafts, there was not
> (and still is not) consensus on what the exact semantics should be.
>
> If you look at the history, RFC 2462 had text about the M&O bits. It
> basically said that if the M or O bit was set, a client should invoke
> DHC. Note: the wording was "should" not "must". When 2462 was reissued
> as RFC4862, all the wording about the M&O bits was removed. The change
> section says:
>
> o Removed the text regarding the M and O flags, considering the
> maturity of implementations and operational experiences.
> ManagedFlag and OtherConfigFlag were removed accordingly. (Note
> that this change does not mean the use of these flags is
> deprecated.)
>
> This was done because the WG could not agree on alternative wording on
> how to define the M&O bits.
>
> Thus, my main comment at the microphone was that unless something has
> changed (and I have seen no indication of this), the WG should not
> take on this topic or discuss it further because there is no consensus
> to make any changes.
>
>> First of all, I would like to give a brief summary for the draft.
>
>> Existing specification (RFC2462) does not give a method on how to
>> revoke DHCPv6 clients once they were invoked by the M or O flags of
>> RA messages.
>
> Personally, I do not believe this is wrong or a problem. IMO, it is
> just fine that there is no way to revoke an earlier hint that DHC is
> available and clients should use it. (DHC has its own ways for dealing
> with unresponsive servers -- clients will retransmit at a very low
> rate, in such a way that such retransmissions do not cause operational
> problems.)
>
>> Let us think about the case that a administrator wants to change
>> network policy from stateful addressing via DHCPv6 to stateless
>> one.
>
> It can do so by simply starting to send out RAs with the relevant
> information. There is no need to disable DHC in order to switch to
> stateless configuration. (It would of course be foolish for the
> information sent out via RAs to conflict with the DHC advertised
> information.)
>
>> Although the admin clears M flag of RA messages and reconfigure(or
>> shutdown) the DHCPv6 server, the DHCPv6 clients keep operating. Even
>> after all bindings expire and stateful addresses are invalidated,
>> the client will keep searching another stateful servers by sending
>> SOLICITs, because the DHCPv6 protocol does not care about values of
>> RA flags.
>
> As stated before, I do not consider this to be a problem.
>
>> If the intention of the restriction that DHCPv6 clients should be
>> invoked at the transition from FALSE to TRUE of the M or O flag of
>> RA is that waste of resources of network infrastructure and host
>> devices caused by useless DHCPv6 operation can be prevented and
>> stateful addresses can be configured automatically by the
>> administrative policy, we believe that our draft has value to
>> supplement missing parts which existing specification and
>> implementations have.
>
> Note: there is not WG consensus that if the M/O bits are cleared that
> one MUST NOT invoke DHC. Routers could be misconfigured and leave the
> bits cleared, even though DHC is to be used. Or there may not even be
> a router on the link! Thus, some persons argue that they want the
> freedom to ignore the M&O bits and invoke DHC anyway. That said,
> others (just as strongly) feel that a client MUST NOT invoke DHC if
> the M/O bits are cleared. This is a point on which the WG simply does
> not have consensus. I do not believe anything has changed in the WG to
> suggest that the WG could reach agreement now, if it were to reopen
> discussion on the matter.
>
>> The second issue (which is likely less important) is concering
>> conflicts M/O flags from different routers which belongs to differnt
>> administrative domains.
>
> This type of environment is problematical and there are no good
> solutions. If two routers are sending out conflicting information
> (intentionally), there is little a client can do to "make things
> right".
>
>> Existing IPv6 stack implementations such as linux are assumed to
>> comply with handling of the M/O flags of RA in the RFC2462. So, they
>> just keep the most recent M/O values without considering senders of
>> RA messages.
>
> In this type of environment, you would presumably want clients to
> continue using DHC even if an RA was received with the M&O bits
> cleared. That is precisely the behavior that is defined/implemented
> today per existing RFCs.
>
> Your proposal would differ and (from what I can tell) cause DHC to be
> enabled/disabled/enabled/disabled/etc/ over and over again. This seems
> like a bad solution in this case.
>
>> This point does not expose serious problems though it does not
>> provide consistent informations about the availability of the DHCPv6
>> service. Since we would like to support revocation of DHCPv6 clients
>> at the transition of M or O flag from TURE to FALSE, the handling of
>> the flags is reworked in our draft to avoid the iteration of
>> invoking and revoking of the clients.
>
> I do not agree with your problem statement that there is a need to
> revoke DHC.
>
> IMO, the WG should first discuss the actual problem statement. That
> is, discuss what exactly is broken that needs to be fixed. Only if
> there is agreement that we have a problem that needs fixing should the
> WG revisit this topic.
>
> Thomas
> _______________________________________________
> dhcwg mailing list
> [EMAIL PROTECTED]
> https://www.ietf.org/mailman/listinfo/dhcwg
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
