Hello, Thomas. Thank you for your clarifications. Please see my comments below.
> -----Original Message----- > From: Thomas Narten [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 18, 2008 12:18 AM > To: [EMAIL PROTECTED] > Cc: ipv6@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Request for Advices on the draft > "draft-cha-ipv6-ra-mo-00.txt" > > 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. > Although alternatives are possible as existing drafts proposed, my concern is focused on the invocation of DHCPv6 clients through RA flags, which is specified in the RFC2462 and have been supported widely by existing implementations and conformance test tools such as TAHI. As an implementor, I wrote a draft to clarify the issues which I observed. > > 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.) > Perhaps this point might be a major conflict. As we both know, consecutive DHCPv6 SOLICIT messages are sent exponentially back-offed if no valid replies are received within timeouts. Since this always holds, I would like to ask you why M/O flags should not be deprecated. IMO, revocation of DHCPv6 clients has also benefits if invocation of DHCPv6 clients should be guided by RA flags. > > 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 is not true. Please refer to the section 4 in our draft. 4. An Algorithm for the Management of Internal State Variables We introduce an algorithm for the management of the internal state variables as follows. In this algorithm, two timers (M-timer and O-timer) are used, lifetimes of which is chosen to be 3 times of MaxRtrAdvInterval in [RFC4861]. When an RA is received that has the M flag set, ManagedFlag is set to TRUE and the M-timer is started or restarted. When an RA is received that has the O flag set, the OtherConfigFlag is set to TRUE and O-timer is strarted or restarted. If the M-timer goes off, the ManagedFlag is set to FALSE. If the O-timer goes off, OtherConfigFlag is set to FALSE. Thus, once ManagedFlag or OtherConfigFlag is set to TRUE, it can only be changed into FALSE after no RA is received with the bit set within lifetime of timers. Thus, state variables can be managed consistently even when a host is connected to multiple routers sending conflicting RA messages, because the RA messages with the bit set will overrule the ones with the bit clear. > > 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 > If you can not agree with our problem statement, I just hope that you have only the reasons mentioned above. Joseph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
