<snipped from Ralph's posting> >>> 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?
Personally I had same questions when I started to implement DHCPv6 clients for our products. Though RFC4861[2] do not specifiy specific behaviors on client's side, I could refer to existing implementations like Vista, opensource from IBM, other vendors' web sites and specification of TAHI conformance testsuit and also, deprectated RFC2461[2]. IMO, even though more clarifications will be inserted as Ralph suggested, the situation will be remain same. If it is correct that M/O bits do not have any values and just results unnecessary complexity as Thomas, Bernie, and Ted commented, I also think that new document is necessary to deprecate M/O bits effectively because current RFCs specify the purpose of M/O bits clearly and sound to leave usages for M/O bits to implementors' choice temporarily. However, if current consensus is that the bits are useful and have no harm, I believe that the issues such as revoking clients and conflict flags should be addressed clearly. Joseph 2008/10/6 Ralph Droms <[EMAIL PROTECTED]>: > Bernie - The point of my suggested text is, in fact, to better describe the > definitions reached in the previous consensus rather than make any changes. > In my opinion, the suggested text represents clarification and does not > make any changes to those definitions. > > - Ralph > > On Oct 6, 2008, at Oct 6, 2008,10:00 AM, Bernie Volz (volz) wrote: > >> 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 >>> >> > > _______________________________________________ > 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 --------------------------------------------------------------------
