Subject: RE: DHCPNAK for DHCPv6?

From: "Thirumalesh Bhat" <[email-masked]>
Date: Fri, 13 Jul 2001 09:31:25 -0700

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

The main problem when changing networks is the amount of time it takes
to get a new address in the absence of a NAK. Let us say you switch from
network A to network B - you try to contact the DHCP server to verify
that you can continue using the leases. You have to wait for your
request to time out before going to the init state and requesting
another address if there isnt a NAK. This process can take more than a
minute in a V4 network.

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.

thx

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]] 
Sent: Friday, July 13, 2001 6:30 AM
To: DHCPv6 discussion list
Subject: RE: DHCPNAK for DHCPv6?

I believe this is covered in the status field in the IA option. Section
7.4 has various error codes that can be returned in IA status or addr
status (the text isn't as clear as to which status codes are where as it
could be).

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |   IA status   |   num-addrs   |T| addr status | prefix length | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Note however that I did comment to Ralph that the -19 draft has no
mechanism for the server (or client) to communicate any status if there
is no IA option. So, I think that a general error status option (with
perhaps a 16-bit code followed by a variable length string for human
consumption) be considered.

I think it is fine to use the Reply message type since that that is a
generic reply message. 

- Bernie 

-----Original Message----- 
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, July 13, 2001 1:03 AM 
To: DHCPv6 discussion list 
Subject: DHCPNAK for DHCPv6? 

One thing I just noticed about the latest draft is that there is no 
equivalent of a DHCPNAK sent in response to a request to renew an 
address when the client has moved to a different network link.  This 
behaviour is extremely important - without it, whenever the client 
changes networks it has to wait for its lease to expire before it can 
get a new IP address. 

Am I correct in thinking that this is missing, or is it I who am 
missing something? 

                               _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jul 2001 09:41:33 -0700

> 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.

> addresses or a different set of addresses depending on the DHCP Server

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_