Date: Sat, 14 Jan 2006 00:30:58 -0500 From: "Bernie Volz \(volz\)" <volz@cisco.com> Subject: [dhcptest:00100] Re: Release-0.3 TAHI DHCPv6 conformance test To: <dhcptest@tahi.org> Message-Id: <8E296595B6471A4689555D5D725EBB210118CE62@xmb-rtp-20a.amer.cisco.com> X-Mail-Count: 00100Hi: Regarding Test 26 (S_RFC3315_15.4_InvalidRequestMsgWoCltID.seq), it still fails with the incorrect server identifier option. In the REQUEST it is using: server-identifier (2) option (10 bytes) - 00:ff:00:00:00:00:00:00:00:00 When in the ADVERTISE, the server sent back: server-identifier (2) option (14 bytes) - 00:01:00:01:43:c7:ef:63:00:03:ba:6c:9f:b9 But, this also makes sense since the patch file you send didn't include any change to the S_RFC3315_15.4_InvalidRequestMsgWoCltID.seq file. Regarding Test 27 (S_RFC3315_15_DiscardRequestwithInvalidOP.seq), I thought the purpose of this one was to see what happens if a Preference Option is sent to the server in a REQUEST message? Test 25 already tested the case where the Server Identifier was for a different server? This test still sends both the Preference Option and the WRONG Server Identifier Option in the REQUEST. See the attached log. Send DHCPv6 Request Message: CLIENT1 --> all DHCPv6 Servers Request Message DHCPv6 OptionValues Opt_DHCPv6_SIDDUID-LLT HardwareType = 1 DUID-LLT MAC = 00:00:00:00:a1:a1 DUID-LLT TIME = 400000 IdentifierIdentifier = 101 Opt_DHCPv6_CIDDUID-LLT HardwareType = 1 DUID-LLT MAC = 00:00:00:00:a2:a2 DUID-LLT TIME = 300000 Opt_DHCPv6_PreferencePreference = 10 Opt_DHCPv6_IA_NAOption 1 Identifier= 101010 T1= 4000 T2= 5000 Regarding Test 47 (./S_RFC3315_15.10_ClientIDOPMatch.seq), the checking is still wrong as it still reports a Client Identifier option was present when that was not the case. The test packet is an Information-Request which includes the Pref option, which technically I think you believe would not be valid (we had the discussion already about checking options in packets from clients), so perhaps this was supposed to fail to receive a Reply? NUT return Reply message Begin check option NG: The Reply Message includes Client ID option DHCPv6 Server stop I have attached the log file. Regarding Test 48 (./S_RFC3315_15.11_InvalidReconfigureMsg.seq), no message is ever received by the server (NUT)? It looks like the unicast destination address for the packet is correct but the server never receives any message? Regarding Test 51 (./S_RFC3315_15_DiscardInvalidInformationRequestwithInvalidOP.seq), the Server Identifier option is still using the wrong DUID (but that makes sense as the patch didn't include any change to this test). See the attached log. Regarding Test 52 (./S_RFC3315_15.14_InvalidRelayReplyMsg.seq ), no message is ever received by the server (NUT)? It is being sent to 3ffe:501:ffff:100:200:ff:fe00:a4a4 which is not a known address for the server? Regarding Test 72 (./S_RFC3315_18.2.1_ReceiptRequestMsgWithStatusCodeOPNotOnLink.seq), per RFC 3315 section 18.2.2 (see below), the status code (NotOnLink) is in the IA, not in the main part of the message. If the server finds that the prefix on one or more IP addresses in any IA in the message from the client is not appropriate for the link to which the client is connected, the server MUST return the IA to the client with a Status Code option with the value NotOnLink. If the server cannot assign any addresses to an IA in the message from the client, the server MUST include the IA in the Reply message with no addresses in the IA and a Status Code option in the IA containing status code NoAddrsAvail. Regarding Test 75 (./S_RFC3315_18.2.2_ReceiptConfirmMsg.seq) it is failing because it is looking for an IA_NA option in the REPLY from a CONFIRM. CONFIRMs don't have IA_* options in the REPLY. From 3315, 18.2.2: 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. Regarding Test 78 ( ./S_RFC3315_18.2.2_ReceiptConfirmMsgIgnore.seq), it has the same issue as Test 75. Regarding Test 80 (./S_RFC3315_18.2.3_ReceiptRenewMsg.seq), I don't understand what failed. If you could take a look and let me know what was expected (Can't found all the special optionsNG: Option check is failed.)? Regarding Test 81 (./S_RFC3315_18.2.3_ReplyNoBidingStutusCodeReceiptRenewMsg.seq), this seems to be looking for the status code option in the wrong place? Regarding Test 83 (./S_RFC3315_18.2.3_ReplyReceiptRenewMsg.seq), I'm not sure what went wrong either? Regarding Test 86 (./S_RFC3315_18.2.4_ReplyReceiptRebindMsg.seq), I think a similar problem (as in 83) exists? Regarding Test 93 (./S_RFC3315_18.2.7_ReceiptDeclineMsg.seq), I'm not sure why it would look for an IA_NA option in a REPLY to a DECLINE (except if the binding were unknown). See RFC 3315, section 18.2.7. Regarding Test 107 (./S_RFC3315_22.12_ServerUnicastOPWithRelayAgentOP.seq), it isn't clear what the purpose of the test is. From the log during the test, it implies that it is doing some kind of unicast test. However, the Relayed REQUEST does not have a Server Identifier option in it. So it is not testing what it thinks it is. Regarding Test 108 (./S_RFC3315_22.13_StatusCodeOP.seq), I don't understand why the TN would be looking for a Status Code option. Regarding Test 123 (./S_RFC3633_10_MultiIAPDPreOP.seq), this (at least from my interpretation of the RFC) is not the way a client can request multiple addresses. To do so, it must use multiple IAs. It is at the choice of the server as to how many addresses are assigned to a specific IA. Regarding Test 128 (./S_RFC3633_12.2_ClientInitPDRebind.seq), I don't understand what failed and the reported error is rather odd - Comparing Opt_DHCPv6_SID not found: Frame_Ether.Packet_IPv6.Upp_UDP.Udp_DHCPv6_Rebind.Opt_DHCPv6_SID in Packet HASH(0x824090c)? Regarding Test 130 (./S_RFC3633_12.2_ClientInitPDNoBinding.seq), the NoBinding status code is only returned if the binding (IA type and IAID) are not valid; a "bad" prefix is indicated by returning 0 lifetimes. See RFC 3633, 12.2: If the delegating router finds that any of the prefixes are not in the requesting router's binding entry, the delegating router returns the prefix to the requesting router with lifetimes of 0. - Bernie > -----Original Message----- > From: haoda [mailto:haoda@64translator.com] > Sent: Thursday, January 12, 2006 11:41 PM > To: dhcptest@tahi.org > Subject: [dhcptest:00099] Re: Release-0.3 TAHI DHCPv6 conformance test > > 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 >100_2.html (attatchment)(tag is disabled)
100_3.html (attatchment)(tag is disabled)
100_4.html (attatchment)(tag is disabled)
100_5.html (attatchment)(tag is disabled)
100_6.html (attatchment)(tag is disabled)
100_7.html (attatchment)(tag is disabled)
100_8.html (attatchment)(tag is disabled)
100_9.html (attatchment)(tag is disabled)
100_10.html (attatchment)(tag is disabled)
100_11.html (attatchment)(tag is disabled)
100_12.html (attatchment)(tag is disabled)
100_13.html (attatchment)(tag is disabled)
100_14.html (attatchment)(tag is disabled)
100_15.html (attatchment)(tag is disabled)
100_16.html (attatchment)(tag is disabled)
100_17.html (attatchment)(tag is disabled)
100_18.html (attatchment)(tag is disabled)
100_19.html (attatchment)(tag is disabled)
100_20.html (attatchment)(tag is disabled)