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

From: RamaSubramanian KrishnaMurthi <[email-masked]>
Date: Tue, 11 Sep 2007 05:04:37 -0700 (PDT)

>> 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.
>
>Another bug.
What is the expected behavour here ?

Yours ever
-RamaSubbu SK 

----- Original Message ----
From: Shane Kerr <[email-masked]>
To: [email-masked]
Cc: 임평빈 <[email-masked]>; [email-masked]; 한근후 <[email-masked]>; 김현아 <[email-masked]>
Sent: Thursday, August 30, 2007 1:45:14 PM
Subject: Re: [dhcwg] Questions on dhcpv6 implementations of Microsoft Server 2008

차현욱 wrote:
> 
> 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. 

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 address and lifetimes set to zero.

Another bug.

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

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

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 11 Sep 2007 09:42:05 -0700

> What is the expected behavour here ?

I think the expected behaviour is for the server to include the IA
from the Renew, with a status code of NoBinding, and no addresses.

This goes back to the two paragraphs you quoted earlier.  I think the
ordering of those paragraphs is meaningful.  Even if you don't accept
the order of the instructions to be meaningful, you have to admit it
is hard to comply with the first paragraph (including no addresses
in the reply) while also including addresses with zeroed lifetimes.

So.

In the case where the server has no binding, it replies as such.

In the case where the server has a binding, but the client has moved
networks so the addresses are no longer valid, it zeroes the
lifetimes.

Note that it may be desirable for the server to 'remember' expired
bindings for some grace period after they have expired.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg