RE: [dhcwg] Re: purpose of m/o bit

["Bernie Volz \(volz\)" <volz at cisco.com>]

So Rich, I'll ask. What would you like to see happen?

- Bernie 

> -----Original Message-----
> From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] 
> On Behalf Of Woundy, Richard
> Sent: Wednesday, May 25, 2005 1:39 PM
> To: Iljitsch van Beijnum; Thomas Narten
> Cc: dhcwg at ietf.org; IETF IPv6 Mailing List
> Subject: RE: [dhcwg] Re: purpose of m/o bit
> 
> >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: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
> Of Iljitsch van Beijnum
> Sent: Wednesday, May 25, 2005 5:43 AM
> To: Thomas Narten
> Cc: dhcwg at 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------