Based on the discussion I have seen so far, having support for both is ok for desktop kind of machines which hardly move out of premise but with the advent of nomadic devices, I feel this is going to make it difficult for the clients to make the right choice safely.
1) What could be the scenario wherein M=0 and O=1 will be useful from deployment standpoint? 2) Static address assignment, RA-based assignment and DHCPv6 are three different ways to provision addresses to clients. Static and the other two are contrary to each other. But can a client handle both RA-based as well as DHCPv6 based address assignment? Though it may not be a viable scenario, it will most likely occur for various reasons - misconfiguration, unauthorized servers and what not. In such a scenario how can the client reliably choose the address and settings (like DNS servers) and be able to function properly. 3) If home scenario is really what RAs will be most useful for, RAs can straightaway assign prefixes rather than having M/O bits. On the contrary, these(CPE) are the devices for which recommendation should be carefully made as any revision of proposal is going to cause lot of interop pain. 4) If RAs are deemed to be useful for non-home scenarios as well, securing against attacks should be done for both RA as well as DHCPv6 which might be a significant problem for clients to be solved. This could be a reason to go with one way rather than both. Both DHCP and RA play a crucial role as they both occur before network discovery. So it would be significantly harder for clients to decide whether they are on a network to allow RAs or not. For managed clients, it's the administrators nightmare. Of course, had it been wireless networks it can be associated with SSID and managed but even otherwise, it is going to involve some bootstrapping/provisioning issues. From network administrators point of view, in non-home network scenario, DHCPv6 might seem more appropriate but given that a client may not know what to expect out of the network, it would have to understand both 5) I'm not sure if it has happened in the past or not. But perhaps since this group comprises the significant portion of the technical community, it would perhaps help to put out some deployment guidelines as well which would help implementers to choose the right model to support the technology. Thanks Kadir -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralph Droms Sent: Friday, October 17, 2008 4:52 PM To: IPV6 List Mailing; DHC WG Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits 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 --------------------------------------------------------------------
