Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6

From: Bernie Volz <[email-masked]>
Date: Wed, 30 Aug 2000 21:15:15 -0400

>The server should keep track of all resources allocated per client,
>and it's able to identify its clients by (relay_address + lower client
bits).
>If a client is crashing a lot, it should set the 'C' bit for each crash :-)
>If it doesn't do that, the server should probably enforce an upper limit
>on how many addresses to allocate.  If the client fakes new interface
>identifiers each time, then I don't know what to do except track it
>down and administer many lashes with a wet noodle.  Or you might
>use a user class identifier and require an authentication extension.

While setting the 'C' bit certainly works if you have only ONE type of
allocatable resource, it doesn't work if you have many. For example, a
client might have lost address information but not foobar information. OR,
it might have remembered some of its addresses, but not all. So, it won't
necessarily want to release everything (I guess that's perhaps were you'd
use the release-all-but type of request).

And, my previous issue for having to have a Server Transaction ID cache is
also addressed in 15.4 and 15.1 - the transaction id is stored for a lease
binding (as well as the client 'identifier'). Sorry I missed that earlier.

This discussion does seem to be helping me get a better understanding of
what currently is defined in DHCPv6 (hope it is helping others). And, the
specification does seem to be cover all of these issues.

Perhaps after some packet format and extensions (options) rework, I'll back
the DHCPv6 specification. This version of the draft appears to be much more
solid than I thought. Good job Charlie, Jim, and Mike!!!

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 7:16 PM
To: Bernie Volz
Cc: [email-masked]'
Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6

Hello Bernie,

Thanks for your note.  Since I won't be there tomorrow, I will
have to assume that technical discussion is a legitimate use for
IETF mailing lists :-)

Bernie Volz wrote:

> While allocation choice 1 sounds nice, it can be extremely wasteful (in
> terms of allocatable resources). What if a client isn't receiving (or
> properly processing server responses) and keeps re-requesting addresses.
> Does that mean you want to allocate a new address for each request? Having
> the server remember transaction ids to detect duplicates doesn't solve the
> problem completely because the client could be crashing on receipt of the
> server's responses and that would mean different ids will be used.

The server should keep track of all resources allocated per client,
and it's able to identify its clients by (relay_address + lower client
bits).
If a client is crashing a lot, it should set the 'C' bit for each crash :-)
If it doesn't do that, the server should probably enforce an upper limit
on how many addresses to allocate.  If the client fakes new interface
identifiers each time, then I don't know what to do except track it
down and administer many lashes with a wet noodle.  Or you might
use a user class identifier and require an authentication extension.

> The questions really comes down to how does the server know what the
> intentions of the client are? I haven't yet figured out how the current
> DHCPv6 design communicates this (feel free to explain).

I'll try, but please forgive me if I miss the point.
- If a client asks for a new address, it should get one (within the
  limitations observed above)
- If a client asks for an existing address, it should get a
  renewal.

> Therefore, if a client wants to request three addresses is sends:
>         ... header ...
>         ere extension (global)
>         ip-address extension 1
>         ere extension for address 1
>         ip-address extension 2
>         ere extension for address 2
>         ip-address extension 3
>         ere extension for address 3
>
> When the server receives this request, is knows the client is requesting 3
> addresses and either allocates all three or those that it can and returns
> the results.

But it _could_ know that even if there were just 3 IP address extensions.

> Now, the tricky part is what happens if the client wants a 4th address.

It could just send another IP address extension.  I don't think it
has to include the previous IP addresses.  Why would it?

Somehow, I am thinking I didn't get the whole point of
your question.  Can you expand a little bit more?

Regards,
Charlie P.

---

From: Jim Bound <[email-masked]>
Date: Wed, 30 Aug 2000 23:17:47 -0400

thanks bernie we really did listen to folks too.  I am sure we missed
some input as it was a lot.  Mike deserves the lion share of the credit.
mike I think invented a mail parser/sorter to make sure we caught most
of the input as the previous draft was way to long ago.
we did not change some architectural points folks wanted but I think we
need a meeting like tomorrow to get folks to tell us their thoughts.
And we have to thank Thomas and Ralph for pushing all of us real hard to
do this, me definitely included and I am pushed to work harder. but I am
burning out on this and progress in anyway would envigorate me again.

/jim