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

From: Bernie Volz <[email-masked]>
Date: Wed, 30 Aug 2000 20:54:10 -0400

Ted:

Yes, the "address index" is something I had thought about as well. It might
actually be the simplest. It does require a server to record one more thing,
but that isn't so bad. A server can easily implement a policy that limits
clients to <n> addresses - reject requests when the index is greater than
<n> (of course, that does require clients to number them sequentially and
might not be wise).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 8:22 PM
To: DHCPv6 discussion list
Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6

> 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.
> 
> Now, the tricky part is what happens if the client wants a 4th address.

This isn't tricky.   All you need is to identify each address.   So
have the client send a client identifier, and an different address
index for each address request.   If it gets three addresses and later
wants a fourth, it uses a new address index to get that one.   I would
suggest that if you want to clump addresses, you should define a clump
option that encapsulates an entire packet, or something like that,
rather than doing a special case on the ip address option.   This
avoids the artificial imposition of an ordering on how the options
need to be laid out.

			       _MelloN_

---

From: Richard Johnson <[email-masked]>
Date: Wed, 30 Aug 2000 18:20:53 -0700 (PDT)

> <n> (of course, that does require clients to number them sequentially and

Why not simply use one of the flag bits to say "this is a new
request"?  If it's not set, the server MAY reissue the same address it 
gave back last time.  If it *is* set, the server MUST either issue a
new address or reject the request.

(I'm probably missing something obvious.  :)

/raj

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Aug 2000 18:40:18 -0700

> It does require a server to record one more thing,
> but that isn't so bad.

Indeed.   I think it's better to require the server to store one more
thing.   We have learned from experience that sending more information
is good in some cases - if we sent a state option with each DHCPv4
message, handling the DHCPREQUEST message would be *much* easier.

			       _MelloN_

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 31 Aug 2000 09:11:53 -0700

A comment on client identifier. This has several uses,
one of which includes serving as the claim of identity
for use in DHCP authentication. It seems awkward to me
to have to rekey a client when they change their NIC.
For that reason I would suggest not tying the client
identifier to the EUI. 

A format that has been suggested in the past is 
concatenation of the hostname with an interface name
and number. This has the advantage of being persistent
across reboots as well as potentially NIC changes.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 31 Aug 2000 20:12:40 +0200

In your previous mail you wrote:

=> for server database lookup, an EUI64 is perfect but
for security we need more an authenticator than an identifier
but I agree we have to add an opaque and optional identifier
(something like a IKE ID payload).

   and number.

=> just make it opaque. On my GSM I'd like to use the IMSI from the SIM.

   This has the advantage of being persistent
   across reboots as well as potentially NIC changes.
   
=> use a Sparc... (:-) Seriously interface IDs are not wired
to NICs, MAC -> EUI64 -> interface ID is just a convenient/standard
way to get an interface ID with good properties (but not the one you
want), it is not the law even if some implementors (not me) don't provide
enough freedom IMHO about this point.

Thanks

[email-masked]