Subject: RE: DHCPNAK for DHCPv6?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 15 Jul 2001 22:36:39 -0500

>The problem is that the spec doesn't say
>what the server should do when I send a Confirm while I'm on the wrong
>network, or what the client should do when it gets a Reply saying
>"you're on the wrong network."

I think the server should send an indication that the prefixes are bad for the link.

When the client receives that indication, it should go to Solicit state at that point to restart the DHCP process (and discard the old addresses).

Note: If the client wants added security, it could require authentication. In that case, a *bad* server can't tell the client that the addresses are bad (unless it knows how to authenticate to the client).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, July 13, 2001 12:42 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6? 

> I think not having NAK is fine. It caused a lot of grief in V4 to get
> the NAK part right.=20

That had more to do with figuring out what state the client is in than
it did with anything else.   We don't have the problem of figuring out
the client state, so this is a non-issue.

More to the point, DHCPNAK *does* something.   We can't just leave it
out.

> In the absence of a NAK - the client can directly go to the INIT state
> with its DUID on changing networks.  It can get the same set of
> addresses or a different set of addresses depending on the DHCP Server
> it is now talking to.

That's not what the specification says right now.  According to the
spec as it stands, we would have to wait for the timeout.  When I
change networks, I want a new address immediately, not after some long
tiemout period has expired.   But moving straight to sending a Solicit
isn't right either.   When the client detects a "link change", it may
not actually have moved - it just suspects that it *may* have moved.
So I want to keep my old IA if I can.   So using Confirm is correct.
The problem isn't that.   The problem is that the spec doesn't say
what the server should do when I send a Confirm while I'm on the wrong
network, or what the client should do when it gets a Reply saying
"you're on the wrong network."

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Mon, 16 Jul 2001 22:08:27 -0400 (EDT)

we should send back prefix not match if the relay prefix does not match
*any* addresses for the IA for the client.  Should be new error code.
In the current spec I catch this and use nobinding.  better to have prefix
no match or some such code we will come up with.

/jim