Subject: RE: DHCPNAK for DHCPv6?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 13 Jul 2001 18:24:51 -0500

Ted:

I had raised this issue a long time ago. I wanted status codes for a CONFIRM that a server could send that said:

- Prefixes are correct, but I can't say your addresses are. This was to be used by a server that served the network but did not assign the addresses to the client. It also means that the client can know it has not moved in such a way that its addresses are bad.

- Prefixes are not correct.

Now, what I'd suggested is that if a client receives an "Success" from a server, it can use the addresses. If it receives a "prefixes are correct" from the server it can use the addresses (it should wait around a bit to see if a server does response with success). If it receives "prefixes are not correct", then it should take steps to get new addresses.

Note that the above two status codes say nothing about the binding because the server can't - it has no information on the bindings (perhaps the Prefixes are not correct is not needed since an existing error covers it).

- 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: Ted Lemon <[email-masked]>
Date: Fri, 13 Jul 2001 16:57:43 -0700

> Note that the above two status codes say nothing about the binding
> because the server can't - it has no information on the bindings
> (perhaps the Prefixes are not correct is not needed since an
> existing error covers it).

What you described seems like it would work, with one caveat.  We need
to explicitly say that in DHCP Solicit, Request and Confirm message,
only IAs for the interface on which the packet is transmitted may be
included.  Otherwise, the server isn't in a position to make address
allocation decisions based on network topology information.  It might
also be necessary to place this restriction on the DHCP Rebind message
- I'm not sure.

			       _MelloN_