Subject: RE: Discussion on configuring stateless clients.

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 10 Aug 2001 09:50:37 -0500

Mark:

I like it. It does require clients to honor 4 but I don't see why that should be
any problem.

One minor issue - we SHOULD use a "No-State Option" instead of a flag bit as
we don't really have a means to signal flags (at present, but I'm sure you'd
add a flags field). It could simple be a 2-byte option code followed by 0 length
(no data). That way, it is fairly short.

Personally, I feel it would be good to stay away from flag bits because we'd have
to allocate some number of them, and that number is fixed. Options already exist
and allow us to handle this in a much more standard manner. (In terms of the scoping
rules, we should allow options to be GLOBAL - which means they MAY appear anywhere
(SHOULD appear early in the message) and have only global scope regardless of where
they are.)

Just to confirm I understand, the "No-State" indication (flag bit or option) means
to a server either return the most recent IA information for the client OR
discard all IAs for the client and assign new one (for the IAID).

Also, you state "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." I agree that additional IAs
should not be allocated. However, what happens if IAID 0 (or whatever IAID is
included in the Solicit) doesn't have any addresses? Should the server allocate
addresses for this IA or not? Also, while you are silent about allocating additional
IAIDs, what about additional addresses? Might be best to leave both these activities
for Request(s).

THERE is just ONE minor issue that servers must be careful about - that is duplicated
Solicit messages from the client. This really won't do major damage - especially
since we no longer consider the Advertised addresses as being a "contract" to lease
those addresses (if they were, a server would have to take care if it wanted to
assign new addresses since it could be that an earlier Advertise response was
delayed).

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:[email-masked]]
Sent: Thursday, August 09, 2001 5:54 AM
To: DHCPv6 discussion list
Subject: Re: Discussion on configuring stateless clients. 

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