Subject: Discussion on configuring stateless clients.

From: Ted Lemon <[email-masked]>
Date: Wed, 08 Aug 2001 18:40:22 +0100

We had a big discussion about configuring stateless clients (clients
with no persistent storage) in the WG meeting today.  The idea is that
we'd like a stateless client to get the same IP address every time,
but we're not sure how to do that.

One point that was raised is that we need to make sure that a
stateless client doesn't generate a new IAID every time it boots,
because if it reboots a lot that could consume addresses without
limit.   One solution is to just insist that a stateless client
implementation be written in such a way that as long as the physical
configuration of the device doesn't change, the client MUST always
generate the same IAIDs.

My objection to this is that it's complicated to specify on the client
side, and I'm afraid client implementors won't implement it.

Another solution is to have the client send a message saying "I don't
remember my previous state - does any server remember it?"   In this
case, a server that remembered previous state for the client could
reply with the IA(s) that it remembers.   The client could then choose
the server that remembered it.

An objection was raised that we have covered this ground before, with
the 'R' bit, which meant "I've forgotten my state - you please forget
it too."   Another objection was that this is a big can of worms that
we don't want to open right now.

We need to solve this problem.   Either solution will work.   I'm
leery of specifying anything complicated on the client, because client
implementors frequently get things wrong, and are much less likely to
actually talk to someone who groks DHCP before deploying their broken
client.   So I favor the solution of having the client able to ask the
server what its state is.   I'd like to know what others think about
this.

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 8 Aug 2001 14:03:21 -0700

> -----Original Message-----
> From: Ted Lemon
> Sent: Wednesday, August 08, 2001 10:40

*Snip!*

> side, and I'm afraid client implementors won't implement it.
...How about some wording such as, "If a stateless client implementation is
capable of generating a repeatable IAID (for example, one algorithmically
derived from a fixed entity such as a system serial number burned into ROM)
the client MUST do so, else a stateless client MUST be capable of generating
a <message-type> message to the server requesting it's (the client's)
previous state.  If a stateless client does not receive a <message-type>
message from a server with it's (the client's) previous state, the client
MUST NOT randomly select an IAID for use, but remain silent."

I put that last bit in to actively discourage client implementors from
taking the lazy way out and dumping all responsibility on the server for
dealing with statelessness, but then rudely insisting on a bit of
self-configuration when they cannot find a cooperative server.

> the server that remembered it.
...this requires a means of resolution if there is no server with knowledge
of the previous state -- my clear preference is to prohibit connectivity if
no server answers.

> we don't want to open right now.
...this one really works only if the client is capable of generating a
reasonable IAID itself, so I'd vote against this one at the moment....

> server what its state is.   I'd like to know what others think about
...right, if the server is incapable of regenerating an IAID from something
(relatively) fixed, then asking for it is the better of the two approaches,
at least to my mind

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 09 Aug 2001 09:09:03 +0100

> MUST NOT randomly select an IAID for use, but remain silent."

Right.   My concern is that a client implementor is going to look at
this, not grok it, do the wrong thing, and deploy.   I would rather
not depend on the client implementor to get this right, based on past
experience.

> of the previous state -- my clear preference is to prohibit connectivity if

Any server willing to give the client an address should answer!

			       _MelloN_

---

From: Mark Stapp <[email-masked]>
Date: Thu, 09 Aug 2001 10:53:55 +0100

I've tried to summarize this problem, and make a proposal at the end.

1) DUID + IAID really identifies a unique binding (or request for a unique 
binding). The presence of the IA is the signal that a client wants 
addresses. That means that a client which sends SOLICITS with a variety of 
IAIDs will get a set of config info and addresses for each ID.

2) That's why the stateless client is a potential problem: if it generates 
a new ID each time it boots, the servers have no choice but to allocate it 
new addresses (and retain state for the previous IDs, which the client is 
not actually using any more).

3) Clients SHOULD respect the semantics of the IAID, and SHOULD NOT 
generate new ones when they don't intend to ask for new bindings.

4) Stateless clients need to obey (3), and if they do (say by always using 
ID 0, they'll be ok. There's a concern that they won't do (3) right, and 
that'll lead to address instability, extra dns updates, and wasted bindings 
that servers remember on behalf of clients that have forgotten them.

5) So we either need to live with the risk that the dependency on (3) is 
acceptable, or provide an explicit mechanism that clients can use to 
indicate that their state is gone.

6) I actually like (5), and I'd like to propose that that be available and 
unambiguous. Here are some sample words:
If a client has no state (because it is a brand-new client booting for the 
first time, because it lost its state through misadventure, or becasue it 
is a stateless client), it SHOULD set the 'N'o State bit in the flags field 
in the header in its SOLICIT messages. It SHOULD include an IA if it wants 
addresses to be allocated; that IAID SHOULD be 0. If a client sets the 'N' 
bit, it MUST NOT continue to use any addresses that it obtained via DHCP, 
and it MUST NOT rely on information which it received from previous DHCP 
messages. Servers which have state for the DUID MAY reply with 
advertisements that contain the valid (unexpired) IAs (and IAIDs) that they 
remember, and SHOULD NOT allocate additional IAs. We expect that to be the 
normal response to the presence of that bit, and we expect that to be the 
mode in which most servers operate. There are several important properties 
of this mode. It allows the client to resume use of addresses by which it 
was known, which might be significant if the client provided services to 
others - if it is a printer or other device, for example. At sites which 
use DNS update, this mode avoids DNS updates to remove DNS records related 
to old bindings and additional DNS updates to reflect new bindings. 
Finally, this mode allows the client to avoid allocating additional resources.

Alternatively, servers MAY take advantage of the client's indication to 
discard state for some or all of the existing bindings it finds for that 
client, if it is configured to do so. Administrators may want to send 
updated or changed information and free existing bindings, and may consider 
the potential cost of changed addresses for the client, additional DNS 
updates, etc. to be acceptable. Servers SHOULD be able to be implement that 
policy.

What do people think about (6)? Is that adequate, too much, not enough? I 
like it (duh) because it's unambiguous (I think), it doesn't overload the 
IA, and it suggests that servers do the 'normal' thing most of the time, 
but it allows that there may be reasons to do different things in some 
situations.

-- Mark