NoBinding after confirmation and subsequent REQUEST message

[Shankar Anand R]

Hi all,

I have a few queries regarding a particular sequence of events described below. I request for your help in clarifying them.

1. Client reboots and sends out a CONFIRM message with 1 IA_NA containing 1 IA_ADDR option.
   
2. Server sends a REPLY with Status code 0 with status message "All addresses still on link."
   
3. After some time client sends a RENEW message with same IA_NA and IA_ADDR option.
   
4. Server, due to some reason, sends a REPLY with status code 3 (NoBinding)  with status message  "Address not bound to this interface."
   
5. Client sends out a REQUEST message with 1 IA_NA containing the same old IA_ADDR option.
   
6. Server sends a REPLY message with 1 IA_NA containing a new IA_ADDR option.
   

My queries:

1. In what possible scenario would an ISC DHCPv6 server send  a "NoBinding" REPLY to an IA_ADDR which it had recently confirmed to the client? Just to be clear: the server has not rebooted in between.

2. When the server sends a REPLY message with NoBinding in response to a RENEW message, RFC 3315 section 18.1.8 says

" When the client receives a Reply message in response to a Renew or Rebind message, the client examines each IA independently. For each IA in the original Renew or Rebind message, the client:

   -  sends a Request message if the IA contained a Status Code option with the NoBinding status (and does not send any additional Renew/Rebind messages)"

Should this next REQUEST message contain the same IA_ADDR option for which the server has sent a "NoBinding"?

3. When the server sends a REPLY message with an IA_ADDR which is different from what the client has asked in it's REQUEST message, what should the client do? I can see that ISC DHCPv6 client retains both the old IA_ADDR (which the server had actually a NoBinding) and the new IA_ADDR contained in the latest REPLY message from the server. This doesn't seem to be correct to me. Is this the expected behaviour?

Thanks in advance.

Regards,

Shankar

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users