Subject: RE: Discussion on configuring stateless clients.

From: "Thirumalesh Bhat" <[email-masked]>
Date: Wed, 8 Aug 2001 11:01:30 -0700

I think this topic needs further discussion.

(a) What are the scenarios where the client has to get the same IP every
time? 
(b) If the client says that I don't know my state to the server, it has
to identify itself somehow to the server. This worked on V4 based on
client id or hardware address. What is the mechanism for the client to
identify itself in v6?

(c) when can the client say that it has forgotten its state? Is it when
it is doing a solicit or when doing a request?

thx

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, August 08, 2001 10:40 AM
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 08:59:16 +0100

> (a) What are the scenarios where the client has to get the same IP every

E.g., a laser printer with an ethernet card.   You don't want it to
change its IP address every time it's power cycled, because the DNS
may not follow quickly enough, and users may lose access to the
service unexpectedly.

> client id or hardware address. What is the mechanism for the client to

The DUID.   The client sends a DUID but no IAID, and the server, if it
remembers an IA for the DUID, sends the IAID back to the client.   The
client can then choose among DHCP Advertise messages based on whether
they contain IAIDs.

> it is doing a solicit or when doing a request?

Solicit only (IMHO).

			       _MelloN_

---

From: [email-masked]
Date: Thu, 09 Aug 2001 10:42:59 +0200 (CEST)

Hi,

the comments are inline.

Quoting Ted Lemon <[email-masked]>

> may not follow quickly enough, and users may lose access to the

And there are a lot of LANs where the system administrator likes it, that every
computer has always the same IP address. Especially if he doesn't like dynamic
DNS...

[...]
> client can then choose among DHCP Advertise messages based on whether
I always thought, that the DUID is the central information on which the server
relies to assign data. So it seems a good idea to link the available IAIDs
together with the DUID.

> > it is doing a solicit or when doing a request?

In the solicit, because it is the first message after a crash/reboot.

Martin

P.S. Yesterday I asked Ralph Droms about who is implementing DHCPv6 and he isn't
aware who is doing so. The reason for this is, that I'm currently implementing
the DHCPv6 stuff and I'm looking for future test partners.