Subject: meta thoughts on m/o bits

From: Thomas Narten <[email-masked]>
Date: Fri, 20 May 2005 13:24:26 -0400

Stepping up a level (and this also reflects my thinking after a
private exchange with Ralph/Bernie - but not necessarily their
thinking!)...

I think the M/O bits (in retrospect) have turned out to be more
trouble than they are worth. Indeed, they seem to be mostly just
confusing. Thus, maybe we should work towards removing them
completely.

In an ideal world, there would be exactly one way for a client to
invoke DHC. That is, it would use the same message exchange to get
"addresses" as it did for "non-address configuration". In such a
world, there would be no need for the M/O bits, since the client would
do the same thing if either one of them were set.

Unfortunately, we are not quite there, since DHC actually has HCB &
ICB message exchanges (using Ralph's terminology). Thus, there are
scenarios where invoking ICB is preferable over HCB. (Aside note: here
is another example where having two ways to do similar things, results
in undesirable complexity). Currently, we sort of need the M/O bits so
a client can know which variant of DHC to invoke. But, we now also
allow for the possibility of "silly states", i.e., states that aren't
supposed to happen, but can, e.g., through misconfiguration. Having
the M bit set but no addresses available is one such example.

Ralph has already indicated that with some small changes to the DHC
spec, we might be able to fix the DHC issue so that there is one way
to invoke DHC that does the right thing in all combinations of
addresses and/or other configuration information being available via
DHC.

If we had that, we wouldn't need two RA bits anymore. At most, a
single "there is stuff to obtain via DHC" bit would suffice.

Indeed, one could go further and say "just always invoke DHC", and
don't even bother with an RA bit saying DHC is available. That has the
nice property of being simple to implement and you don't have silly
states where the RA bit(s) are configured incorrectly, etc.

The only advantage I can see right off to having at least 1 RA bit is
to tell the client "there is no DHC server running, so don't even
bother". This would be a performance optimization to allow one to
avoid needing to invoke DHC and have it timeout -- before concluding
that there are no DHC servers. Is this a significant optimization?
Hard to say.

What I would like to suggest: followup on the above proposed DHC
changes and see if we can actually "fix" DHC to simplify what the
client has to do to invoke it. And if that works, do away with one or
both of the RA bits.

Remember, simplicity is Good!

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 20 May 2005 23:17:09 +0530

This proposal looks better and easy to understand. However,
if we just rely on timeout for concluding the unavailabiliy of DHCP server,
how does the client re-invoke DHCP if the DHCP server is available later in 
time? I think we need one bit to inform the clients about the
availabilty of DHCP
services in the network.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 May 2005 13:53:40 -0400

> time? I think we need one bit to inform the clients about the

I would assume that DHC has mechanisms for discovering when DHC
servers come on line. I.e., the client just sits quietly in background.

Sure, an RA bit could also signal the availability of a new server,
but I would first like to be convinced that the existing default DHC
mechanism isn't good enough for handling this case (better not to have
multiple ways of acheiving the same result).

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 May 2005 14:33:38 -0400

Well...DHCPv6 doesn't have any better mechanism for announcing
availability of a server than does DHCPv4 (which is to say "none").
There has not been an identified need to push an announcement of DHCP
server availability out to clients.

Section 14 of RFC 3315 specifies the retransmission behavior for DHCP
clients.  When that behavior is interpreted for Solicit messages in
section 17.1.2, the result is that the DHCP client continues to
retransmit Solicit messages at low frequency (once every 2 minutes)
forever.  Therefore, the client will eventually contact the DHCP service
when a server becomes available.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 21 May 2005 03:50:02 +0900

(cc'ing the dhcwg list)

>>>>> On Fri, 20 May 2005 13:24:26 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> confusing. Thus, maybe we should work towards removing them

As a meta thought, I cannot agree more.  In fact, the points you
showed are (almost) exactly what I wanted to make when we first
discussed the M/O flags issue in the rfc2462bis work (but you seem to
express the points much better than I did).

We actually once considered this option, whereas we didn't see some of
the relevant points we now know.  See, for example, a very long
thread a year ago:

http://www1.ietf.org/mail-archive/web/ipv6/current/msg02285.html

As you can see in the thread archive, there was a strong push-back
against the idea of removing these flags (while some others supported
the idea).  Then we finally decided to not remove the flags after a
heated discussion.  So, I'm wondering whether we can now really
convince those who opposed to the idea.

One additional meta note: even if we now decide to remove the flags,
it wouldn't affect rfc2462bis, since it does not mention the flags at
all.  However, the decision would require a non-trivial (while not so
big) change to rfc2461bis, which contains these flags in the RA
message format and a brief description of these flags.

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

---

From: Syam Madanapalli <[email-masked]>
Date: Sat, 21 May 2005 00:37:13 +0530

> when a server becomes available.

This may not be efficient for wireless networks where power and
bandwidth are crucial.

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

---

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Tue, 24 May 2005 10:28:22 +0900

(Sorry for being too late response)

I am really not sure why this thread is moved to *meta thought*.
When I wrote this document, I originally thought this task was 
our explicit consensus to be a seperated document from 2462bis.
Am I missing anything ? I don't think so.

See below link (October 2004)
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03799.html

It would have been nice if you said your comment at that time.

As you mentiond, simplicity is also good aspect and we (all author)
was trying to make this document as simple as we can. If we feel it 
so heavy, we will make it more concise than now.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Narten
> Sent: Saturday, May 21, 2005 2:24 AM
> To: [email-masked]
> Subject: meta thoughts on m/o bits
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 24 May 2005 10:45:19 -0400

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?

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

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

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.

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!!! :-))

So, what is it? 

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 25 May 2005 10:35:23 +0900

>>>>> On Tue, 24 May 2005 10:45:19 -0400, 

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

In my understanding of the past discussion (mainly for rfc2462bis),
the "community" felt that operators need RA bits that control indicate
whether a client "can" invoke DHC.  The nuance might be slightly
different from "is to" invoke DHC, but I think in general the answer
was YES.  And I don't think recent discussions change the base sense
at that time.

> (And should that be honored by clients?)

Perhaps depending on the meaning of "honored", but it seems some
people who have mobility background think YES, in that it is important
to provide a way of signaling "do not run DHC" (when it's not
available) for saving batteries (and perhaps network bandwidth).

					JINMEI, Tatuya

---

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

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

YES

> presence become useless?)

YES

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

---

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

> 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

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

> 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

---

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