Thomas, I would like to add a few comments as below. > > ------- Original Message ------- > Sender : Thomas Narten<[EMAIL PROTECTED]> > Date : 2008-09-18 22:01 (GMT+09:00) > Title : Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt" > > HYUN WOOK CHA <[EMAIL PROTECTED]> writes: > >> > > 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. > > Because the WG doesn't feel that the flags were so problematic that > they needed to be deprecated? There certainly has been concern that > existing implementations that do support the M&O bits should not > become non-complient through deprecation of the M&O flags. > > IMO, if we were to start over knowing what we know today, I'd be in > favor of not having the M&O bits at all. But we are not starting from > scratch... >
I am not sure that M&O bits has no value. At this moment, I simply do not want to enter long debates for this topic. According to the RFC4861 and 4862, we have freedom to choose handling of M&O bits in RA. Specification in the RFC 2462 may be considered as an option, which has been implemented and practiced widely by many vendors. In this option, we found out the issue that there is no method to revoke DHCPv6 clients once invoked by RA M/O bits. Thus, we devised our proposal to address the issue clearly. >> IMO, revocation of DHCPv6 clients has also benefits if invocation of >> DHCPv6 clients should be guided by RA flags. > > On this point, I have seen little indication that the WG agrees with > you. > >> > 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. > > OK. Sorry for not reviewing this point in advance. > >> 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. > > Sure, this would work. Though one can question whether the additional > implementation complexity is worth the benefit. > >> If you can not agree with our problem statement, I just hope that >> you have only the reasons mentioned above. > > Right. I just don't see the problem as particularly significant, and I > don't believe the WG will be able to agree on changing the definition > of the M&O flags (given past discussions). > I agree that the issue itself is not significant. However, we believe that the issue is a missing part which should be handled clearly so that implementors may be guided well and our proposal can be applicable for this. > If your real concern is that DHC continues to be invoked forever (even > when no DHC servers are available), wasting network resources, IMO, > the better place to make changes is in the DHC specification. I.e., > the DHC client should backoff more aggressively and "poll" for the > appearance of a new server very infrequently. > > This would be appear to be as simple as changing the value of SOL_MAX_RT: > > Parameter Default Description > ------------------------------------- > SOL_MAX_RT 120 secs Max Solicit timeout value > > See Section 17.1.2 in RFC 3315. > > Thomas > > > I do not think that your suggestion is right approach. Why do not you simply allow to revoke DHCPv6 clients by RA flags through which they are invoked? Joseph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
