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

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Wed, 25 May 2005 13:08:29 +0900

> 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?

YES

> 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?)

YES

> If we can't agree that the above is necessary (i.e., is a "problem
> statement" of sorts), I really have to wonder what purpose the R/A
> bits can serve or whether we will ever have a shared understanding of
> what they are supposed to do. Having them be a hint (that clients in
> practice ignore half the time) would seem to solve no useful purpose
> (IMO) and would provide the sys admin with useless tools (since
> clients wouldn't respond to the usage of the tool in predicatable
> ways). The result would simply be more confusion. (Oh, that is already
> the state we are in!!! :-))

I don't think we (folks) do not agree on above necessary. We may
need more simplified method to achieve above than now.

---------------------------------------------
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 May 2005 11:43:07 +0200

[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".

> a need for the sys admin to signal to client whether DHC is to be

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.

> 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.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 May 2005 02:22:48 +0900

>>>>> On Wed, 25 May 2005 11:43:07 +0200, 
>>>>> Iljitsch van Beijnum <[email-masked]> said:

> optain a domain search list and some DNS resolvers makes me very  

A quick check (which may not be relevant to this thread): what exactly
do you mean by such a complex protocol?  Whole RFC3315 (mainly for
address allocation), the RFC3736 subset, or both?  If your goal is to
obtain a domain search list and recursive name (DNS) servers, you only
need the RFC3736 subset, and at least I'd not use the strong phrase
"such a complex protocol" for RFC3736.

Implementation maturity is a separate issue.  I admit KAME's DHCPv6
implementation is not so matured yet, particularly regarding its
address allocation functionality.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Anil Kumar Reddy" <[email-masked]>
Date: Fri, 27 May 2005 17:28:12 -0700

: From: [email-masked] [mailto:[email-masked]] 
: On Behalf Of Iljitsch van Beijnum
: Sent: Wednesday, May 25, 2005 2:43 AM
:
: [Crossposted to dhcwg even though I'm not on that list, as 
: people there may be able to add some useful insights.]

<snip>
 
: 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.

FYI - If I am not too late on this:

HP-UX supports DHCPv6 implementation - conforming to RFC3315.
I don't intend to deviate the topic, but I thought this info 
 may be useful for you with respect to operational community.

--
Anil