>All of this, coupled with the fact that, AFAIK, no OS implements DHCPv6, means that there is essentially zero experience with DHCPv6 in the operational community. This means that at this time, there is little point in asking the operational community what should happen with the M and O bits.
Or perhaps this could be the ideal time to ask the operational community what should happen with the M and O bits -- before software developers go too far down a particular direction without operator guidance? Some of us operators do more than just configure and test vendor products. -- Rich -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iljitsch van Beijnum Sent: Wednesday, May 25, 2005 5:43 AM To: Thomas Narten Cc: dhcwg@ietf.org; IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit [Crossposted to dhcwg even though I'm not on that list, as people there may be able to add some useful insights.] On 24-mei-2005, at 16:45, Thomas Narten wrote: > I wonder if there is key question here that the community has simply > not agreed on (yet), and that that question is at the heart of all > this "confusion". > Does the community feel that operators need RA bits that > control/indicate whether a client is to invoke DHC? That is, is there > a need for the sys admin to signal to client whether DHC is to be > invoked? By a strange coincidence, I spent most of the day yesterday taking several DHCPv6 implementations for a test drive, for reasons unrelated to this discussion. These implementations are: KAME DHCP6, the unnamed Linux fork of the KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco IOS implemenation. Conclusion: the Cisco implementation is incomplete (no address assignment) and the other two are too immature to be of much use. I'm impressed with the prefix delegation functionality, but as before, the prospect of running such a complex protocol just to optain a domain search list and some DNS resolvers makes me very uncomfortable. All of this, coupled with the fact that, AFAIK, no OS implements DHCPv6, means that there is essentially zero experience with DHCPv6 in the operational community. This means that at this time, there is little point in asking the operational community what should happen with the M and O bits. In other words: this is not the time declare the bits useless and remove them. > Second, is it important that such a signal be honored by clients? > (That is, if clients end up mostly ignoring the flags, does their > presence become useless?) Depends. There are three possible ways this can play out: - the DNS resolver issue is solved in a way that doesn't requite DHCP, so most people don't don't run DHCPv6 at all, others run it all the time -> no bits necessary - the DNS resolver issue isn't solved in another way, so everyone runs some form of DHCPv6 all the time -> no bits necessary - DHCP provides benefits but some people are reluctant to use it -> helpful to know whether to bother running DHCPv6 > For example, should the sys admin be able to say "do not run DHC, > doing so wastes local resources and won't get you any config info"? > (And should that be honored by clients?) I think it's good to recognize that in the past, there have often been security issues with non-text based UDP protocols, so knowing there is no need to run DHCP and then not running it would be good security. > Fundamentally, it is only the access network that has knowledge of > whether running DHC is useful. Thus, by default, clients (arguably) > can't know whether running DHC is useful, so by default they shold > invoke DHC (unless the sys admin signals "don't invoke DHC"). > Or (switching the argument), by default, client should not invoke DHC, > unless the local sys admin indicates doing so is appropriate. There isn't really a difference here, except for what happens when there are no RAs. I would be interested in hearing viewpoints on the usefulness of running DHCPv6 even though the hints indicate that there is no need to. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
