Hello, Tony. Thank you for your agreement and interests in the issues being addressed by the draft "draft-cha-ipv6-ra-mo-00.txt".
Since I feel that we need to discuss how to solve the issues more, I would like to insert my comments as below. 2008/10/24 Tony Hain <[EMAIL PROTECTED]>: > I agree with Joseph that these should be combined and published. > > As for dealing with conflicting M&O, just OR the received set. When the > state changes from 1 to 0 (actually in either direction), after a random > delay re-query DHCP to verify the lease time/config information. In a > managed configuration, this would be a simple way to abruptly revoke > outstanding leases, without allowing a rogue RA to drop existing state. The > most the rogue RA would do is generate extraneous traffic to the DHCP > server. > I think that you mean by "OR" that the state of M/O bit should remain 1 as long as a RA is received with M/O set to 1. If you consider to implement this, you might agree more complexity suggested by our draft. That is, timer based management scheme of bit states. I see possible cases that states should be able to be clear. Administrator may change network policy from stateful addressing to stateless one. Or administrator may fix the misconfiguration by clearing M/O bits in RA mistakenly set. Or, once a dual homed site is connected with two domains provisioning stateful addressing and stateless one respectively, the upstream connection to the stateful domain may be removed later. Through our scheme, the state variables can be changed from 1 to 0 after some pre-defined delay. As for re-quering DHCPv6 to verify the lease time/config information, I also agree that this may be one option. However, if there are RA messages with conflict M/O bits being sent frequently by multiple routers, this might generate much extraneous traffic to the DHCPv6 server. For this case, hosts do not have to generate extraneous DHCPv6 traffic as long as one valid router sends its RA with M/O bit set to 1 if our scheme is applied. Only if no RA are received with M/O bit set to 1 within pre-defined delay, the state will be changed to 0. Then, your suggestion may be one option. As for options that we may choose, two another options are suggested in the draft. First one is that a client refer states just to check that it should keep its operation, i.e it is allowed to send Solicit/Info-request multicast messages only when lease or information refresh timer expires. If the state is 0, client terminates. According to the RFC3315, DHCPv6 server may send a Reconfigure message to inform new or updated configuration parameters, then client initiate a Renew/Reply or Information-request/Reply transaction. So, if the server send the Reconfigure message right before its termination or service change from stateful to stateless(RFC3736), leases of clients can be invalidated early and safely through the DHCPv6 protocol. The other option is that state transition from 1 to 0 makes client be revoked immediately. Even though this sounds unreasonable and unsafe, it will cause no serious problems since this might happen only if no RA messages are received with M/O bits set any more. Joseph > I would also like to clarify a point raised by Iljitsch; the reason the > number of people complaining about too many changes is the same as those > complaining about not enough, is due to both arguments being raised by the > same people. Basically people are whining that their favorite change isn't > happening, so no other change should be allowed either. This is essentially > why we ended up with the state where both an RA and DHCP are required, > rather than both mechanisms being self-contained and available to deal with > different deployment scenarios. Some people demand central control, and they > should have all the capabilities within DHCP to do so, while others want to > minimize points of configuration to maintain, and they should also have a > complete set of capabilities. While RFC 5006 fixes the DNS piece, there is > no hint that SRV records allow completing that picture. > > FWIW: the people that are promoting the concept that IPv6 is just IPv4 with > more bits, are simply refusing to recognize that they need to learn > something new. They have tied their value in the marketplace to IPv4, and > are trying to convince the market they are still relevant. > > Tony > > >> Hello, Ralph and all. >> >> I would like to insert another option into the following list. >> draft-ietf-ipv6-ra-mo-flags-01.txt >> I am not clear why this WG document failed to proceed. However, I view >> this document as nice base docuement since I think that it seems that >> we do not have clear reason to deprecate M&O bits and it is more >> desirable to let host's local policy override M&O bits in received RA. >> >> One thing I would like to point is that our draft >> "draft-cha-ipv6-ra-mo-00.txt" just aims to clarify old >> specifications(RFC2461/2462) and provide better guidance to >> implementors. So, I would say that our draft can be merged with >> "draft-ietf-ipv6-ra-mo-flags-01.txt" or extended to contain the whole >> framework w.r.t processing the bits. >> >> Joseph >> >> > 2. NO: How does the IETF want to change this consensus and how should >> the >> > change process be conducted? >> > >> > There have been some suggestions for changes to the current >> consensus >> > behavior: >> > >> > * Deprecate the M/O flags; require that future DHCPv6 clients ignore >> > the M/O flags; require that routers send RAs with M/O flags set to 1 >> > * Revert to previous definitions and behaviors in RFC 286* >> > * draft-cha-ipv6-ra-mo-00.txt >> >> >> >> >> 2008/10/17 Ralph Droms <[EMAIL PROTECTED]>: >> > I've been tracking this discussion about the M/O flags, which seems >> to be >> > going in several different directions. I thought it might be useful >> to try >> > to get some agreement on what needs to be done so we can focus on >> coming to >> > consensus on a course of action. It also seems like a small group of >> > participants has gone pretty deep into some technical details, which >> might >> > be irrelevant depending on the consensus of the IETF. >> > >> > Here's a quick, informal survey to assess consensus about how to >> proceed. >> > Please reply to the list so we can focus our discussion. Thanks. >> > >> > 1. Is the following text an accurate summary of the previous IETF >> > consensus on the definition and use of M/O bits: >> > >> > The M/O flags indicate the availability of DHCPv6 service for >> > address assignment and other configuration information, >> > respectively. The IPv6 specifications make no requirements on the >> > behavior of DHCPv6 clients in response to the values of the M/O >> > flags received in RAs. >> > >> > 2. Does the IETF choose to continue to accept this consensus or >> should >> > the definition of client behavior in response to the M/O flags be >> > revisited? >> > >> > 2. YES: Is that consensus adequately described in the IPv6 RFCs or >> should >> > the IPv6 RFCs be revised in some way to describe the consensus >> > requirements? >> > >> > 2. NO: How does the IETF want to change this consensus and how should >> the >> > change process be conducted? >> > >> > There have been some suggestions for changes to the current >> consensus >> > behavior: >> > >> > * Deprecate the M/O flags; require that future DHCPv6 clients ignore >> > the M/O flags; require that routers send RAs with M/O flags set to 1 >> > * Revert to previous definitions and behaviors in RFC 286* >> > * draft-cha-ipv6-ra-mo-00.txt >> > >> > >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> > >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
