Hi:
I've tried the 0.3 release and many things are now working much better!
I do notice a few issues though when performing the *SERVER* test (make
test_server):
For Test 26, the stated purpose of the test is to send a REQUEST w/o a
Client Identifier option. While the test does this, it also happens to
send the REQUEST with the WRONG Server Identifier option. So, the server
may well drop this because of the wrong Server Identifier option (since
the message is not directed at the NUT server).
Same goes for Test 27 and 28.
Perhaps whatever Test 25 "set" to force a different server identifier
option was never "unset" for the following tests?
Test 47 (./S_RFC3315_15.10_ClientIDOPMatch.seq -pkt
./S_RFC3315_15.10_ClientIDOPMatch.def -log 47.html -ti "Reply
message(w/o Client ID option)") reports that the server did include a
Client Identifier option in the Reply when this is not the case (hence
the test fails). Something is wrong in the check of the results:
---
Receive DHCPv6 Reply Message: NUT --> Any
got DHCPv6 Reply Message
Reply Message
DHCPv6 OptionValues
Opt_DHCPv6_SIDDUID-LLT HardwareType = 1
DUID-LLT MAC = 00:03:ba:6c:9f:b9
DUID-LLT TIME = 1137090706
IdentifierIdentifier = 102
NUT return Reply message
Begin check option
NG: The Reply Message includes Client ID option
DHCPv6 Server stop
---
As you can see, no Client ID option was returned by the server.
Test 51
(./S_RFC3315_15_DiscardInvalidInformationRequestwithInvalidOP.seq -pkt
./S_RFC331
5_15_DiscardInvalidInformationRequestwithInvalidOP.def -log 51.html -ti
"Process
ing Invalid Information-request Message (w/Invalid Option)") also isn't
doing what it supposedly says it is since it ends up sending an
Information-Request with the wrong Server Identifier option. It does
also include the Perference Option, but most servers likely ignore the
message because it wasn't directed at them (as it has the wrong server
identifier option).
Test 75 (./S_RFC3315_18.2.2_ReceiptConfirmMsg.seq -pkt
./S_RFC3315_18.2.2_ReceiptConfirmM
sg.def -log 75.html -ti "Receipt of Confirm Messages(return w/Status
Code= Succe
ss)" is not checking the reply correctly. I think there is an assumption
that the IA_NA option should be returned in the REPLY and the Status
Code option is contained therein. HOWEVER, this is NOT my interpretation
of RFC 3315:
18.2.2. Receipt of Confirm Messages
When the server receives a Confirm message, the server determines
whether the addresses in the Confirm message are appropriate for the
link to which the client is attached. If all of the addresses in the
Confirm message pass this test, the server returns a status of
Success. If any of the addresses do not pass this test, the server
returns a status of NotOnLink. If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected), or there were
no addresses in any of the IAs sent by the client, the server MUST
NOT send a reply to the client.
The server ignores the T1 and T2 fields in the IA options and the
preferred-lifetime and valid-lifetime fields in the IA Address
options.
The server constructs a Reply message by setting the "msg-type" field
to REPLY, and copying the transaction ID from the Confirm message
into the transaction-id field.
The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Confirm
message in the Reply message. The server includes a Status Code
option indicating the status of the Confirm message.
There is nothing about returning IA_* options. It is interesting that
Test 76, Confirm w/NotOnLink Status, assumes that there will be no IA_*
options returned.
Test 78 has the same issue -- it is assuming IA_* options w/Status Code
of SUCCESS on a CONFIRM.
Test 81 (./S_RFC3315_18.2.3_ReplyNoBidingStutusCodeReceiptRenewMsg.seq
-pkt ./S_RFC3315_18.2.3_ReplyNoBindingStutusCodeReceiptRenewMsg.def -log
81.html -ti "Receipt of Renew Messages(return w/Status Code=
NoBinding)") is not checking for the Status Code option in the correct
place. Again, my interpretation here is that the Status Code option is
INSIDE the IA_* option in this case. The reason for this is simple --
there could be multiple IA_* options in the message and the server way
well know about some of the bindings but not others.
From RFC 3315, section 18.2.3:
If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with a Status Code option set
to NoBinding in the Reply message.
Please think about the location of the status code option as follows: If
the status code applies to a single binding, it appears in the binding
(ie, encapsulated in an IA_* option). If it applies to the entire client
request, it appears in the main part of the message. Note that for a
REQUEST, we return NOT ON LINK in the main part of the message because
this implies that the client and server don't agree on the link the
client is on and thus we want the client to know it is on the wrong link
and not assign it any addresses.
In the RENEW case, there could be multiple bindings (IA_* options) and
perhaps only one of those is not known to the server. Hence, the
NoBinding applies to a specific BINDING, not the entire request and
hence it must be encapsulated in the binding.
Test 82 (./S_RFC3315_18.2.3_ReplyLifetime0ReceiptRenewMsg.seq -pkt
./S_RFC3315_18.2.3_ReplyLifetime0ReceiptRenewMsg.def -log 82.html -ti
"Server return lifetimes=0") is failing though we send back the correct
response (well, we actually send back an IA_NA option with two IADDRs,
one for the bad address with lifetimes of 0, and another for the good
address -- which we renew). I'm not sure exactly what is failing in the
test's check (it reports
From the log, it reports:
Checking Options...
Checking Opt_DHCPv6_SID Opt_DHCPv6_SID found
Checking Opt_DHCPv6_CID Opt_DHCPv6_CID found
Checking Opt_DHCPv6_StatusCode Opt_DHCPv6_StatusCode not found
Checking Opt_DHCPv6_IA_NA Opt_DHCPv6_IA_NA found
NG: Option check is failed.
Yet, this is incorrect. Per 18.2.3 in RFC 3315:
If the server finds that any of the addresses are not appropriate for
the link to which the client is attached, the server returns the
address to the client with lifetimes of 0.
This is also apparently what the stated purpose of the test is ("Server
return lifetimes=0").
There is a similar issue with Test 85. Though I think in this case the
test check fails because our server turns both the valid address (with
lifetimes) as well as the bad address (with 0 lifetimes).
Test 93 (./S_RFC3315_18.2.7_ReceiptDeclineMsg.seq -pkt
./S_RFC3315_18.2.7_ReceiptDeclineMsg.def -log 93.html -ti "Receipt of
Decline Messages") is failing when I don't think it should. It reports
that there is no IA_NA option but there shouldn't need to be one:
Receive DHCPv6 Reply Message: NUT --> Any
got DHCPv6 Reply Message
Reply Message
DHCPv6 OptionValues
Opt_DHCPv6_SIDDUID-LLT HardwareType = 1
DUID-LLT MAC = 00:03:ba:6c:9f:b9
DUID-LLT TIME = 1137090706
IdentifierIdentifier = 108
Opt_DHCPv6_CIDDUID-LLT HardwareType = 1
DUID-LLT MAC = 00:00:00:00:a2:a2
DUID-LLT TIME = 300000
Opt_DHCPv6_StatusCodeStatusCode= 0 Success
Checking Options...
Checking Opt_DHCPv6_SID
Opt_DHCPv6_SID found
Checking Opt_DHCPv6_CID
Opt_DHCPv6_CID found
Checking Opt_DHCPv6_StatusCode
Opt_DHCPv6_StatusCode found
Checking Opt_DHCPv6_IA_NA
Opt_DHCPv6_IA_NA not found
NG: Do not include necessary options!
DHCPv6 Server stop
From RFC 3315, section 18.2.7:
After all the addresses have been processed, the server generates a
Reply message and includes a Status Code option with the value
Success, a Server Identifier option with the server's DUID, and a
Client Identifier option with the client's DUID. For each IA in the
Decline message for which the server has no binding information, the
server adds an IA option using the IAID from the Release message and
includes a Status Code option with the value NoBinding in the IA
option. No other options are included in the IA option.
---
That's all I got through today. If I find additional issues with test 94
and beyond, I'll let you know.
- Bernie
> -----Original Message-----
> From: Hideshi Enokihara [mailto:Hideshi.Enokihara@jp.yokogawa.com]
> Sent: Monday, January 09, 2006 11:42 PM
> To: dhcwg@ietf.org; dhcptest@tahi.org
> Subject: [dhcptest:00097] Release-0.3 TAHI DHCPv6 conformance test
>
>
> Hi all,
>
> The TAHI project release DHCPv6 conformance test tool version 0.3.
>
> Please see the following URL.
>
> http://www.tahi.org/dhcpv6/
>
> If you are interested in this test tool,
> I recommend that you subscribe to following Mailing list.
>
> dhcptest@tahi.org
>
> And please give your comments/questions about the test tool
> and the specification to this Mailing list.
>
> Best regards,
>
> --
> *************************************
> Hideshi Enokihara
> IPv6 Business
> Network & Software Development Dept.
> Yokogawa Electric Corporation
>