Subject: #1, DAD, DHCP clients and servers...

From: "Michael W. Carney" <[email-masked]>
Date: Fri, 17 Mar 2000 11:02:30 -0800 (PST)

Hi folks,

I've uncovered a few issues when writing the new DHCPv6 drafts that I'd
like to get the opinion of the WG on.

I'm sending each issue in a separate message thread, to facilitate the
discussion.

1) draft-ietf-dhc-dhcpv6-14.txt states that a client is to perform
Duplicate Address Detection (DAD) on IP addresses it receives from DHCP
server(s). That prevents multiple machines from using the same address
on the link, but there isn't any mechanism for notifying the DHCP
server(s) that the IP address it handed out is already in use. DHCPv4
has the DHCPDECLINE mechanism for this purpose.

When I asked a few folks about this problem, I was told that the IP
addresses given out by DHCPv6 servers will always include the client
interface's interface identifier, and thus the address should already be
unique, since uniqueness is determined by the interface identifier, a'la
stateless address autoconf.

It seems to me that one of the features of DHCPv6 should be the ability
to allocate IP addresses independent of an interface's interface ID.
Otherwise, I feel we're unnecessarily limiting the protocol.

If we want to enable DHCPv6 to return IP addresses independent of
the client's interface ID, then I think we need a mechanism for DHCP
clients to use to inform servers of IP address collisions.

Thus:

a) Do we want to enable DHCPv6 to return IP addresses independent of
client interface ID?

b) If (a) is YES, then is it important for clients to notify servers of
the address collision (or more generally, resource collision)?

c) If (b) is YES, then the mechanism I propose is similar to DHCPv4. We
add a new message type, the Decline message, and a the client would
include an IP address extension with the client IP address field set to
the duplicate address, the 'C' bit set, and the status field would
contain a TBD value informing the server that the IP address is already
in use. Please feel free to propose other solutions.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
(650) 786-4171
Mailstop UMPK17-202
901 San Antonio Rd
Palo Alto, CA 94303

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 18 Mar 2000 09:15:22 -0800 (PST)

> a) Do we want to enable DHCPv6 to return IP addresses independent of

Yes. In some cases a site might wish to "hide" the interface ID
(it tells who manufactured the EThernet card if nothing else).
Also, in certain cases (maybe in the future) sites might wish to have
denser allocation by not giving a /64 to every subnet. Being able to
use DHCP (since stateless addrconf can't do it) seems like useful
'insurance'.

> the address collision (or more generally, resource collision)?

At a minimum the clients must be able to get a different address.
And for operational reasons I assume the DHCP server (and admin) needs
to be notified of the duplication.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Mar 2000 11:47:40 +0100

In your previous mail you wrote:

=> yes, IMHO it is one of the reasons we need DHCPv6.

=> yes because the client will need to get another address and
the manager a red window with an error message (I suppose the manager
manages the DHCPv6 server in place of a zillion of individual hosts :-).

=> It should be fine to have as many as possible infos about the collision?
Perhaps an error message with suitable extensions is better (ie this is
more an error case than a retry one).

Regards

[email-masked]

PS: I agree with Tim and Erik.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 20 Mar 2000 09:39:16 -0500

>a) Do we want to enable DHCPv6 to return IP addresses independent of

*Yes*.

>the address collision (or more generally, resource collision)?

Yes - although I'm not sure what other resources might "collide" at this 
point...

>in use. Please feel free to propose other solutions.

A Decline message seems like the right solution.

- Ralph