Turns out I found the trigger. My server was sending a duid-llt with a hardware type of 6 instead of 1. This seems to cause tahi to revert to duid any instead of just copying the server duid from the advertise to the request.
----- Original Message -----
From: Yoshio Uomori <mario@tahi.org>
To: Andre Kostur
Cc: users@tahi.org <users@tahi.org>
Sent: Tue Oct 06 20:54:38 2009
Subject: Re: [users:01324] DHCPv6 DUID any ?
Hi Andre,
Thank you for your question.
In the beginning, could you send the test log?
Best Regards,
Yoshio Uomori
On Tue, 6 Oct 2009 12:06:23 -0700
Andre Kostur <akostur@incognito.com> wrote:
> I'm attempting to use the DHCPv6_Self_Test_P2_1_0_17, and having some unexpected behaviours. For the DHCP_CONF.2.1.1 test, part A (standard Solicit/Advertise/Request/Reply), TAHI appears to be sending the Request filling in the server ID with a DUID Any. Two questions:
>
>
> 1) Where is DUID Any defined in RFC?
>
> 2) Wouldn't sending a DUID any in a Request defeat the purpose of the Request?
>
>
>
--
Yoshio Uomori <mario@tahi.org>