Subject: RE: Discussion on configuring stateless clients.

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 8 Aug 2001 18:29:34 -0500

In thinking about this some:

Why is it difficult to state this for client implementations? Simply
say "If a client has no permanent storage to store IAIDs that it was
using across boots, it MUST assign IAIDs using a consistent pattern
every time it boots. For example, 0, 1, 2, ....".

I'm not sure why configuration changes matter. After all, if the client
has no way to storage anything across boots, how can it know whether the
configuration changed? Why would it make any difference anyway?

Next,

>Another solution is to have the client send a message saying "I don't
>remember my previous state - does any server remember it?"  

Seems like Solicit/Advertise would be a neat way to do this. But, I haven't
thought of any clever way to do this since if the client doesn't include an
IAID option in the Solicit, what would a server send back in the Advertise
to communicate, yes I can assign you addresses. So, it is a catch-22 unless
multiple Solicit/Advertise are done.

I still think the solution is to specify the behavoir for the client. Use
the same IAID space.

One item that we should address in the -20 draft is some recommendations on
when to assign new IAID values and when to keep old ones (or perhaps when
a client or server may 'delete' old ones).

For example, I would suggest that we say "A server may NOT delete all knowledge
of a client's IAID until there are no more valid addresses for the IAID (ie,
the valid lifetime has expired)."

On a different issue, suppose a client has held onto lots of IAIDs that it has
accummulated over time (as it has moved from network to network). I would assume
it is acceptable for that client, when it (re)boots or detects a network change,
to Confirm *ALL* of the IAIDs it has (either in one or multiple messages). So,
this has an implication for whether clients want to retain "old" IAIDs or not.
And, what they might do with them if they do.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 1:40 PM
To: DHCPv6 discussion list
Subject: Discussion on configuring stateless clients.

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: Ted Lemon <[email-masked]>
Date: Thu, 09 Aug 2001 09:26:44 +0100

> multiple Solicit/Advertise are done.

We could add an option signifying that the Solicit means "I want you
to tell me my state or assign me an address" rather than "I just want
to get DHCP information, and don't need an address," which I think is
what no IAID means now in an advertise message.

> I still think the solution is to specify the behavoir for the client. Use

I think this is the ideal solution.   I am just afraid is is not the
right solution given past experience.   THe problem is that the cost
to the client implementor of doing this wrong is relatively low, so if
a mistake is made we may just have to live with it.   If we provide
the client implementor with an easy way to do this, I think it's more
likely to happen, even if it complicates things slightly on the
server.   I certainly don't mind the extra complexity - I don't think
it's very substantial.   :'}

> For example, I would suggest that we say "A server may NOT delete
> all knowledge of a client's IAID until there are no more valid
> addresses for the IAID (ie, the valid lifetime has expired)."

Sounds like a good plan.   Can it be a SHOULD NOT rather than a MUST
NOT?

> On a different issue, suppose a client has held onto lots of IAIDs
> that it has accummulated over time (as it has moved from network to
> network). I would assume it is acceptable for that client, when it
> (re)boots or detects a network change, to Confirm *ALL* of the IAIDs
> it has (either in one or multiple messages). So, this has an
> implication for whether clients want to retain "old" IAIDs or not.

I don't really know why clients would make up new IAIDs, other than at
the request of an application - what's the scenario you're thinking of
here?   Are you suggesting that the client should, for example, have a
different IAID for each network to which it connects?   I'm not sure
how that can be made to work, frankly, since it doesn't necessarily
know what to network it's connected when it sends a Solicit or
Confirm.

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 9 Aug 2001 01:42:50 -0700

> very substantial.   :'}
...which is why I proposed raising the "cost" to a lazy client
implementation by insisting that if they cannot be consistent in their IAID
use, they should not be able to continue communicating

> Sounds like a good plan.   Can it be a SHOULD NOT rather than a MUST
...SHOULD NOT works for me!

--Barr

---

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

> use, they should not be able to continue communicating

There's no way to specify this other than by administrative policy,
which isn't likely to help us.   That is, you can tell the server
"only allow the client 5 IAs at a time", for example, but we can't say
that in the standard, because the server administrator may need to
allow more addresses than that.

			       _MelloN_