Subject: [dhcwg] Questions on dhcpv6 implementations of Microsoft Server 2008

From: 차현욱 <[email-masked]>
Date: Thu, 30 Aug 2007 02:09:56 +0000 (GMT)

Dear, all.

While I observed dhcpv6 client and server of Microsoft Server 2008 Beta3, I have some questions on its behaviors.

Server side.
1. When the server receives Request without ORO (Option Request Option), it gives no Reply. Although it responds with Advertisement to Solicit without ORO. 

2. When the server receives Confirm with valid IPv6 address(On-link prefix), it responds with Reply without any status code.  

3. When the server receives Confirm with invalid IPv6 address(not on-link prefix), it responds with Reply with "NoBinding" status code. 

4. After an existing binding is removed, when the server receives Renew for the deleted binding, it responds with Reply with "NoBinding" status code within IA address option which includes IPv6 address and lifetimes set to zero.
I
Client side.  
5. When physical link of the client host is moved to different network and the client received Reply with "NotOnLink" status code to its Confirm, it ignores the Reply and keeps renewing. 
 
6. When physical link of the client host is reconnected and the client received Reply with "Success" status code to its Confirm, it sends Solicits.

7. When DAD fails and the client sends Declines and receives Reply, it sends not Request but Solicit. 

8. After the client obtains IPv6 address and the host reboots, it sends not Confirm but Solicit. 

Thank you for kind replies in advance. 

Regards, 

Joseph HyunWook Cha

The truth will set you free !!!

Software Engineer 
Development Part 1. I/Infra  
Network System Division 
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Shane Kerr <[email-masked]>
Date: Thu, 30 Aug 2007 10:15:14 +0200

> 1. When the server receives Request without ORO (Option Request Option), it gives no Reply. Although it responds with Advertisement to Solicit without ORO. 

Interesting observation. The next version of our client has changed to always
include an ORO - an empty ORO if you really don't want any options.

It's not clear from RFC 3315 whether it is legal or not to send a request without an
ORO. :(

> 2. When the server receives Confirm with valid IPv6 address(On-link prefix), it responds with Reply without any status code.  

This should be okay given this (from section 22.13 of RFC 3315):

                                                                     If the Status
   Code option does not appear in a message in which the option could
   appear, the status of the message is assumed to be Success.

> 3. When the server receives Confirm with invalid IPv6 address(not on-link prefix), it responds with Reply with "NoBinding" status code. 

Yup... it's a bug.

> 4. After an existing binding is removed, when the server receives Renew for the deleted binding, it responds with Reply with "NoBinding" status code within IA address option which includes IPv6 add…

Another bug.

> 5. When physical link of the client host is moved to different network and the client received Reply with "NotOnLink" status code to its Confirm, it ignores the Reply and keeps renewing. 

Bug... and highly annoying! :(

> 6. When physical link of the client host is reconnected and the client received Reply with "Success" status code to its Confirm, it sends Solicits.

The client is looking to see if there are other DHCPv6 servers on the new link.
This behavior is quite okay.

> 7. When DAD fails and the client sends Declines and receives Reply, it sends not Request but Solicit. 

Seems like a relatively harmless bug. Perhaps not even a bug, since it is such a
rare condition (hopefully!) and RFC 3315 does not say what client s should do
when they do detect a duplicate address, beyond sending a Decline.

> 8. After the client obtains IPv6 address and the host reboots, it sends not Confirm but Solicit. 

Well, this should be okay. Clients are not required to store their lease in
persistent memory are they?

- --
Shane