Ralph: Your changes effectively deprecate them.
- Bernie -----Original Message----- From: Ralph Droms (rdroms) Sent: Monday, October 06, 2008 9:59 AM To: Bernie Volz (volz) Cc: Ralph Droms (rdroms); Thomas Narten; [EMAIL PROTECTED]; DHC WG; IPV6 List Mailing; Brzozowski John Subject: Re: [dhcwg] Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt" Bernie - my suggested clarifications help the situation in that the flags are currently underspecified (in fact, IMHO, confusingly specific) relative to the previous consensus about their definition. Deprecating the bits would require a new consensus. - Ralph On Oct 6, 2008, at Oct 6, 2008,9:55 AM, Bernie Volz (volz) wrote: > 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
