Subject: [Fwd: [Fwd: Re: DHCPv6 issues status]]

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 20 Dec 1999 14:48:27 -0800

Hello Erik,

Thanks for your note.

Here are my simple answers.  There are actually more cases, but I
don't want to get into every detail just yet.  I think Mike is
preparing a more comprehensive note with additional details on
various subjects.

>> 	- Simple clients do not include the prefix request ERE, and thus
>> 	  only care to get *some* set of one or more IP addresses
>> 	  returned by the server. They make the number of IP addresses
>> 	  known by including empty IP address extensions in their DHCP
>> 	  request.
>
> Do you have a proposal that can carry these different types of semantics:
>  - Client want's no addresses at all (got them from stateless already)

Client doesn't include any IP address extension or ERE with address
extension number.

>  - Client want's all addresses (using the "default" prefixes) that the
>    server hands out

Client includes an ERE or IP address extension, probably with no IP
address
(also implies no prefix) in it.

>  - Client wants N addresses (even if the server by default hands out M which
>    could be more or less than N)

Client includes an IP address extension.
If it gets M (<N) addresses, it asks again.
If it gets K (>N) addresses, it releases some.

The last case is pretty speculative, and I don't think it should
be a common case.  Thus I don't see that we need to devise special
protocol to handle it.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Dec 1999 11:01:35 -0500

> be a common case.  Thus I don't see that we need to devise special

This last case is the most interesting one, and is the one that has
caused the confusion/complexity so far. This is one of the critical
aspects of the "request more addresses" model.  Saying it won't be a
common case and we don't need to worry about it now seems odd. The
spec needs to nail down the details and semantics of this type of
operation precisely because they are non-trivial.

Alternatively, if it really is the case that this won't be a common
scenario, why should the protocol support it?

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Dec 1999 08:40:57 -0800

>>>    could be more or less than N)

The scenario was, as I understood it, that the client wants exactly
N addresses at some particular point in time.

>> be a common case.  Thus I don't see that we need to devise special

I stand by this answer.

> operation precisely because they are non-trivial.

What I have always said is that we should allow a DHCP client to get
a new IP address whenever it wants one.  There is no contradiction
whatsoever between this, and my answer to the question that Erik raised.
I do not consider my answer to be "odd".

I also still do not believe that we have to devise special protocol
to handle the case for a client that wants exactly N addresses and
no more and no less.  We can get pretty close with what we have now,
by allowing a client to append N IP address extensions to its DHCP
Request.  I still suggest that most clients will not want to do this,
and that if they did they might just as well append a single IP address
extension and wait to see what comes back from the server.  Or servers!

Even with that long bit of clarification, I stand by my original answer.

Furthermore, I believe that it is not the responsibility of the
DHCP specification to nail down every bit of application-level
programming related to DHCP.  We just have to make the spec work
and solve the needs for stateless address autoconfiguration.  I think
that what you are asking for fits much better in the realm of
policy management for DHCP server database configuration.

> scenario, why should the protocol support it?

The protocol should support the allocation of new IP addresses to
clients
whenever they ask for them.  Perhaps the local administration will
configure their server to be less generous.  Perhaps the local
administration
will configure their server(s) to be very generous and hand out several
IP addresses at every request.

Charlie P.