Hi, Mr. Volz,
Thanks for the information from you!
> 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).
I have checked the script and found a problem of the definition
of the SID option. It have be fixed in the patch with the email.
> Same goes for Test 27 and 28.
Test27:
It have SID option, but the test is used to check the validation
the process when server receives a Request Msg with invalid SID option.
Test28:
The Request Msg have no SID option.
I can't confirm where the problem is in Test27 & 28.
Would you like to say them in detail? Thanks.
BTW, if you show the log of 27&28, I think it is very helpful to me.
> 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:
...
> 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.
I think the current edition with a error that is only checked whether
it is Discard by the server. Please try to apply the patch file.
> 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).
I think the goal of the test is to check whether it is discard by the
NUT while the NUT receive the Information-Request message with
invalid option. Maybe it is same as the previous discussion of
how to process the messages with invalid options. (Discard
them or Ignore them)
> 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
>...
> 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.
In this scirpts, I think I add a not properly assumption that the Reply message
need include IA_* options for the Confirm message. It should be not check the
IA_* options in the Reply message and not mind exists or not-exists, isn't right?
BTW, I am not very clear why you said "Test 76, Confirm w/NotOnLink Status, assumes
that there will be no IA_* options returned.". Actually this test script only checked
the status code and does not expect the IA_* options.
> 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.
I will modify my script to run as this.
But I think whether it is necessary to describe more clearly in
the RFC for avoiding the wrong understand.
(This item and the previous item test51)
> 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).
In current version of this test item it only process the status code
in the main part, so the test is failed. Now I have begin to modify it.
> 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:
…
>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.
I think I had mis-understood the text above in RFC3315.
Only the IA in the Decline message can't be found in the server's IA list
is added in the Reply messages. And in common the IA is not be added
for declined objects.
> That's all I got through today. If I find additional issues
> with test 94 and beyond, I'll let you know.
Thanks for using our test tool and give us precious feedbacks.
And your explain of RFC, they are very helpful to me.
Thank your very much.
Sincerely yours,
Haoda
99_2.tgz