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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20160224/6e534d83/attachment.html>