<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=shift_jis">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY>
<DIV>Hi, Amit,</DIV>
<DIV> </DIV>
<DIV> Thank you for your report.</DIV>
<DIV> I have examined the test scripts.</DIV>
<DIV> </DIV>
<DIV> Fistly, let me explain the First RT.</DIV>
<DIV>-------------------------------------------------------------------------</DIV>
<DIV> In Section 14 of RFC3315, there are following specification:</DIV>
<DIV> </DIV>
<DIV> "RT for the first message transmission is based on IRT:</DIV>
<DIV> RT = IRT + RAND*IRT ".</DIV>
<DIV>---------------------------------------------------------------------------</DIV>
<DIV>Normally, RAND should be a Random value between -0.1 and 0.1.</DIV>
<DIV>---------------------------------------------------------------------------</DIV>
<DIV> In Section 17.1.2 of RFC3315, the following words were
written.</DIV>
<DIV> </DIV>
<DIV> "Rather, the client collects Advertise messages until the first
RT has elapsed.<BR> Also, the first RT MUST be selected to be
strictly greater than IRT<BR> by choosing RAND to be strictly
greater than 0."</DIV>
<DIV>----------------------------------------------------------------------------</DIV>
<DIV> So,as to first Solicit retransmission time(First
RT), RAND becomes a Random value between 0 and
0.1. </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> Then, please let me explain the three test cases one by
one.</DIV>
<DIV> =========================================================================================</DIV>
<DIV> 1. C_RFC3315_17_1_2_SolWaitAdv.seq</DIV>
<DIV> </DIV>
<DIV>(1) Test case<BR></DIV>
<DIV>Client
Server</DIV>
<DIV>|
| </DIV>
<DIV>| ---------------> | Solicit</DIV>
<DIV>| <--------------- | Advertise (preference = 0 or less than
255)</DIV>
<DIV>| ---------------> | Request</DIV>
<DIV> </DIV>
<DIV>(2)Specifications of RFC3315</DIV>
<DIV> </DIV>
<DIV> "If the client is waiting for an Advertise message, the
mechanism in<BR> section 14 is modified as follows for use in the
transmission of<BR> Solicit messages. The message exchange is
not terminated by the<BR> receipt of an Advertise before the first
RT has elapsed. Rather, the<BR> client collects Advertise
messages until the first RT has elapsed.<BR> Also, the first RT MUST
be selected to be strictly greater than IRT<BR> by choosing RAND to
be strictly greater than 0."<BR></DIV>
<DIV>(3) Explanation</DIV>
<DIV> </DIV>
<DIV> when Client receives the Advertise message from low-preference
DHCPv6 Server,</DIV>
<DIV>It must wait first RT. When First RT pass, the Client will accept this
DHCPv6 Server,</DIV>
<DIV>and then send Request to Server(In fact, multicast to server, but with
Server identifier </DIV>
<DIV>option).</DIV>
<DIV> And first RT is not very identical to the specification
in section 14 of RFC3315.</DIV>
<DIV>In regulation, Fisrst RT = IRT + RAND*IRT , but RAND must
be larger than 0.</DIV>
<DIV> </DIV>
<DIV>(4) The limitation of test script</DIV>
<DIV> </DIV>
<DIV> Because it is Client who determines when to accept the Server
and when to send request,</DIV>
<DIV>the TN(Server End) cannot know the accurate time of Client and ONLY use the
time when </DIV>
<DIV>receiving the message from Client.</DIV>
<DIV> This instance is obvious example. The Client can ONLY use the
time when receiving Request.</DIV>
<DIV>So, this time interval (Actually, this interval should be between the
time Sending Solicit and the time ACCEPTING Server) </DIV>
<DIV>will include the Client diposing time and network transmission time.</DIV>
<DIV> But I think this delay should be very small value and must less than
0.1s.</DIV>
<DIV> Therefore, If you find the time is not in right range, because, the
First RT must less than IRT.</DIV>
<DIV> </DIV>
<DIV>(5)Implementaion </DIV>
<DIV> </DIV>
<DIV> In RFC3315, there are the recommended value about
IRT and RAND.</DIV>
<DIV> SOL_TIMEOUT 1 sec</DIV>
<DIV>
RAND
[-0.1, +0.1] , uniform distribution </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>2.C_RFC3315_17_1_2_SolNoWaitAdv.seq</DIV>
<DIV> </DIV>
<DIV>
<DIV>(1) Test case<BR></DIV>
<DIV>Client
Server</DIV>
<DIV>|
| </DIV>
<DIV>| ---------------> | Solicit</DIV>
<DIV>| <--------------- | Advertise (preference = 255)</DIV>
<DIV>| ---------------> | Request</DIV></DIV>
<DIV> </DIV>
<DIV>
<DIV>(2)Specifications of RFC3315</DIV>
<DIV> </DIV>
<DIV> "If the client receives an Advertise message that does
not<BR> include a Preference option with a preference value of 255,
the<BR> client continues to wait until the first RT elapses."</DIV>
<DIV> </DIV>
<DIV>(3) Explanation</DIV>
<DIV> </DIV>
<DIV> In this case, the Client receive the DHCPv6 server with
highest preference value which is 255.</DIV>
<DIV>So the Client will accept this server and immediately send Request message
to the Server.</DIV>
<DIV> </DIV>
<DIV>(4) Limitation of test script</DIV>
<DIV> </DIV>
<DIV> Because it is Client who determines when to accept the Server
and when to send request,</DIV>
<DIV>the TN(Server End) cannot know the accurate time of Client and ONLY use the
time when </DIV>
<DIV>receiving the message from Client.</DIV>
<DIV> This instance is obvious example. The Client can ONLY use the
time when receiving Request.</DIV>
<DIV>So, this time interval (Actually, this interval should be between the
time Sending Solicit and the time ACCEPTING Server) </DIV>
<DIV>will include the Client diposing time and network transmission time.</DIV>
<DIV> </DIV>
<DIV> This test assumes that the Client will complete all operations in
First IRT.</DIV>
<DIV> So the PASS condition is interval between the receptions of Solicit
and Request, is not great than IRT.</DIV>
<DIV> </DIV>
<DIV>(5)Implementaion </DIV>
<DIV> </DIV>
<DIV> In RFC3315, there are the recommended value about
IRT and RAND.</DIV>
<DIV> SOL_TIMEOUT 1 sec</DIV>
<DIV>
RAND
[-0.1, +0.1] , uniform distribution </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>3.C_RFC3315_17_1_2_SolNoAdvRT.seq</DIV>
<DIV> </DIV>
<DIV>
<DIV>
<DIV>(1) Test case<BR></DIV>
<DIV>Client
Server</DIV>
<DIV>|
| </DIV>
<DIV>| ---------------> | Solicit</DIV>
<DIV>|
| Server donnot response to Client</DIV>
<DIV>| ---------------> | Client-retransmitted Solicit</DIV>
<DIV>| <--------------- | Advertise (preference = 255)</DIV>
<DIV>| ---------------> | Request</DIV>
<DIV> </DIV>
<DIV>
<DIV>(2)Specifications of RFC3315</DIV>
<DIV> </DIV>
<DIV> "If the client does not receive any Advertise messages before
the<BR> first RT has elapsed, it begins the retransmission
mechanism<BR> described in section 14."</DIV>
<DIV> </DIV>
<DIV>(3) Explanation</DIV>
<DIV> </DIV>
<DIV> This is the test case including test of First RT
and Reaction of Advertise to Retransmitted Solicit.</DIV>
<DIV> The judgement is the interval between the receptions of
solicit and retransmitted solicit, should be between IRT and IRT +
RAND*IRT.</DIV>
<DIV> </DIV>
<DIV>(4)Limitation of test script</DIV>
<DIV></DIV>
<DIV> </DIV>
<DIV> No.</DIV>
<DIV> </DIV>
<DIV>
<DIV></DIV>(5)Implementaion </DIV>
<DIV> </DIV>
<DIV> First RT = IRT + RAND*IRT RAND should be larger
than 0 and less than +RAND.</DIV>
<DIV> As recommended in RFC3315, First RT should be value between
1sec and 1.1sec.</DIV>
<DIV>===================================================================================================</DIV>
<DIV> </DIV>
<DIV>Above words are my understanding of Solicit Retransmission
and Acceptation of Advertise.</DIV>
<DIV>Base on those, the test scripts were written.</DIV>
<DIV> </DIV>
<DIV>What do you think about those?</DIV>
<DIV>If you find I is misunderstanding the specifications or you have
some advice, please contact me.</DIV>
<DIV>You will be appreciated very much.</DIV>
<DIV> </DIV>
<DIV>By the way, do you have used all of test scripts?</DIV>
<DIV> </DIV>
<DIV>Best regards,</DIV>
<DIV>zhang </DIV></DIV></DIV></DIV></DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>I have few more doubts on the following scripts....</DIV>
<DIV> </DIV>
<DIV>C_RFC3315_17_1_2_SolWaitAdv.seq</DIV>
<DIV>C_RFC3315_17_1_2_SolNoWaitAdv.seq</DIV>
<DIV>C_RFC3315_17_1_2_SolNoAdvRT.seq</DIV>
<DIV> </DIV>
<DIV>Here Its comparing the for the time periods.</DIV>
<DIV> </DIV>
<DIV>These 3 test cases are failing saying "Not in right time range!"</DIV>
<DIV> </DIV>
<DIV>I am sending first solicit message random time between 0-1 second, but stil
they are failing.</DIV>
<DIV> </DIV>
<DIV>Can u please check and tell me whether there is some problem in the script
or i need to modify something in my code itself.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</DIV>
<DIV> </DIV>
<DIV><BR><BR><B><I>zhang <zhang@64translator.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><M!
name="GENERATOR" content="MSHTML 6.00.2900.2769" ETA>
<DIV>Hi, Amit</DIV>
<DIV> </DIV>
<DIV> You are welcome.</DIV>
<DIV> And I appreciate your report.</DIV>
<DIV> If you have other problems about DHCPv6 client test cases,
please contact me.</DIV>
<DIV> </DIV>
<DIV>Best regards,</DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>Thanks for your support.</DIV>
<DIV> </DIV>
<DIV>I have tested "Transmit DHCP using Unicast Address", its working fine. No
bugs in that test script, that test case got passed.</DIV>
<DIV> </DIV>
<DIV>You send the new test scripts for MRD after modification, i will test and
let you know the results.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit<BR><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="M! SHTML 6.00.2900.2769" name=GENERATOR>
<DIV>Hi, Amit </DIV>
<DIV> </DIV>
<DIV> First, thank you for your report.</DIV>
<DIV> </DIV>
<DIV> I am very sorry, It is a BUG.</DIV>
<DIV> This test case will be deleted in next release version
because it is the same test case with that of "Transmit DHCP using
Unicast Address".</DIV>
<DIV> If the latter test is OK, this test can be ignored.</DIV>
<DIV> And I have look into the source code, and configuration of
server address of ServerUnicast Option is wrong. </DIV>
<DIV></DIV>
<DIV> And I have a question to you. Have you performed the test
of "Transmit DHCP using Unicast Address".</DIV>
<DIV> I want to know the result of that test.</DIV>
<DIV></DIV>
<DIV> By the way, about fix of MRD, I think I
will finish them by this friday.</DIV>
<DIV> I am very sorry to have you wait.</DIV>
<DIV> </DIV>
<DIV> Thank you! .</DIV>
<DIV> </DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi zhang,</DIV>
<DIV> </DIV>
<DIV>I have one more doubt in client test cases.</DIV>
<DIV>There is one test case to check the "Format of Server Unicast Option".
Here the script is sending the server unicast address as
fe80::250:daff:fe91:ddba, which is my DHCP client PC eth0's link l!
ocal address.<BR></DIV>
<DIV>When my client sends the renew msg to that address, its saying Could
not get Renew Message and gets failed.</DIV>
<DIV> </DIV>
<DIV>Please explain me this...</DIV>
<DIV> </DIV>
<DIV>Thanks and regards,</DIV>
<DIV>Amit</DIV>
<DIV> </DIV>
<DIV><BR><B><I>zhang <zhang@64translator.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<DIV>Hi amit,</DIV>
<DIV> </DIV>
<DIV> Thank you very much for your report.</DIV>
<DIV> </DIV>
<DIV> Now I cannot draw a con! clusion from your
description.</DIV>
<DIV> Following words are just my deduction.</DIV>
<DIV></DIV>
<DIV> I think there may be the problem of nut.def.</DIV>
<DIV> For example, if using Linux OS, the
Link0 will be set as following,</DIV>
<DIV> Link0 eth0
aa:bb:cc:dd:ee:ff </DIV>
<DIV> </DIV>
<DIV> From your description, the reason may be that you
use "LINK0" other than "Link0". </DIV>
<DIV> And so you cannot get the variable of
Link0_addr.</DIV>
<DIV> Can you try to examine that and the path of
nut.def ? </DIV>
<DIV> Or else, you can send your nut.def to me.</DIV>
<DIV> </DIV>
<DIV> Thanks,</DIV>
<DIV> Best regards,</DIV>
<DIV> Zhang
</DIV>
<DIV> </DIV><DI! V>
<HR>
<DIV></DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>I tried testing the "Use of upstream address when sends DHCP
message"</DIV>
<DIV>I even checked that the Nut.def file has proper MAC address assigned
for LINK0.</DIV>
<DIV> </DIV>
<DIV>I even printed the value got for ! MAC address in
get_nut_link_number() function in DHCPv6_common.pm file. Its the same
value which i have assigned against LINK0 in Nut.def file.</DIV>
<DIV>The test case is failing because its comparing this MAC adress with
Link0_addr field. I have no idea from where he is getting the value
for this variable. I tried printing this variable but could not print
that.</DIV>
<DIV> </DIV>
<DIV>I am sending the messages from my client to the script on eth0. And i
have set eth0's MAC address(of my client) to LINK0 in Nut.def
file.</DIV>
<DIV> </DIV>
<DIV>Could you please look into ! the same and tell me what to do.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</D! IV>
<DIV> </DIV>
<DIV><BR><B><I>zhang <zhang@64translator.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<DIV>Hi amit</DI! V>
<DIV> </DIV>
<DIV> You question makes me think more about the test
case. Thank you very much.</DIV>
<DIV> </DIV>
<DIV> Now I can reply to you.</DIV>
<DIV> </DIV>
<DIV> 1. Use of upstream address when sends DHCP
message</DIV>
<DIV> </DIV>
<DIV> In RFC3633, " When a requesting router
sends a DHCP message, it SHOULD be sent on<BR> the interface
associated with the upstream router (ISP network).
The<BR> upstream interface is typically determined by
configuration." is decribed.</DIV>
<DIV> </DIV>
<DIV> ----I think this test is us! ed to test the
upstr! eam interface that the Requesting Router is using.</DIV>
<DIV> It is a better way to use Interface MAC address
to determine whose interface(Link) Requesting Router is using.</DIV>
<DIV> I am very sorry, there is some inconsistenc! e
between the test script and the test specification.</DIV>
<DIV> I will change the test specification to make
them consistent.</DIV>
<DIV> By the way, when you test , please
set Nut.def file, and set Link0 as your upstream
interface.</DIV>
<DIV> The test will check MAC address and
determine if It is Link0. It is the limitation.</DIV>
<DIV> </DIV>
<DIV> 2.About MRD test.</DIV>
<DIV> </DIV>
<DIV> ----I think my consideration is
not enough to these test cases.</DIV>
<DIV> I think they are BUGs.</DIV>
<DIV> And I am considering how to fix th! em. I need
some time! .</DIV>
<DIV> After fixing, I will contact you.</DIV>
<DIV></DIV>
<DIV> what about other test items? If you have other
questions, I will be glad to discuss them with you.</DIV>
<DIV> </DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang</DIV>
<DIV> </DIV>
<DIV>Thanks for your immediate response. I wil test with the .seq file
you have sent.</DIV>
<DIV> </DIV>
<DIV>I have two more doubts.</DIV>
<DIV>1> There are two test saying "Use of upstream address when sends
DHCP message".</DIV>
<DIV> I wanted to know what exactly are
these two test cases. Becauses these test cases are failing giving an
error as </DIV>
<DIV>"NUT Link MAC Address is 00:50:da:91:dd:ba<BR> Upstream Link
number should be Link0 ."</DIV>
<DIV> </DIV>
<DIV>In the script he is comparing the Ma! cAdrress with some variable,
i could not understand that...</DIV>
<DIV> </DIV>
<DIV>Plz tell me what we ne! ed to do exactly.</DIV>
<DIV> </DIV>
<DIV>2> Two test cases are to verify the MRD of Confirm message and
Rebind message.</DIV>
<DIV>What i am doing is, my DHCP client stops retransmitting when the
next retransmission time exceeds MRD of that message.</DIV>
<DIV>But the scr! ipt stil waits for some more time and he compares two
messages and say they are not same.</DIV>
<DIV> </DIV>
<DIV>Please clarify this doubt also...</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</DIV>
<DIV><BR><B><I>zhang <zhang@64translator.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<DIV>Hi, amit</DIV>
<DIV> </DIV>
<DIV> Thank you for your report.</DIV>
<DIV> </DIV>
<DIV> I am sure that this is a bug, and
I have fixed it.</DIV>
<DIV> We will fix this bug ! in next version.! </DIV>
<DIV></DIV>
<DIV> I attach two files to this mail. </DIV>
<DIV> You can use them to continue
your test.</DIV>
<DIV> </DIV>
<DIV> If you find some other problems, please cont! act
us.</DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi...</DIV>
<DIV> </DIV>
<DIV>I have implemented DHCPv6</DIV>
<DIV>I am testing my client and server using the tahi test
scripts.</DIV>
<DIV> </DIV>
<DIV>I have a doubt in one of the client script.</DIV>
<DIV> </DIV>
<DIV>The script is :
C_RFC3633_11_1_AdvWStatusCodeNoPrefixAvail.seq</DIV>
<DIV> </DIV>
<DIV>Here he says receiving advertisement with Status code
"NoPrefixAvail" but what i found was he is sending advertisement with
Status code "Success" but he in the reply for request message he !
sends Status code "NoPrefixAvail".</DIV>
<DIV> </DIV>
<DIV>But while sending the reply message he is sending wrong
transaction ID.</D! IV>
<DIV> </! DIV>
<DIV>Can u plz clarify this...</DIV>
<DIV> </DIV>
<DIV>Thanks.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Amit<BR><BR><B><I>dhcptest-admin@tahi.org</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid; MAR: 5px">Cautio!
n: If you reply this mail, your reply will be sent to the mailing
list!<BR>post articles <DHCPTEST@TAHI.ORG><BR>commands
<DHCPTEST-CTL@TAHI.ORG><BR>maintainer
<DHCPTEST-ADMIN@TAHI.ORG><BR><BR>Welcome to our mailing list
<DHCPTEST@TAHI.ORG>!<BR><BR>This mail contains the fundamental usage
of the mailing list server.<BR><BR>1 How to use this
server<BR><BR>Plaese send commands in the mail body not subject to
the address<BR><DHCPTEST-CTL@TAHI.ORG>.<BR><BR>The command syntax is
as follows:<BR><BR>help<BR><BR>mget last:10 mp<BR><BR>Plaes! e send
the "help" to the address <DHCPTEST-CTL@TAHI.ORG>for help
and<BR>server functions overview<BR><BR>help<BR><BR>to get general
in! formation on this list<BR><BR>guide<BR><BR>If you want to make a
contact with the mailing list maintainer, please<BR>e-mail
to<BR><BR>dhcptest-admin@tahi.org<BR><BR>ML server exists to
descrease routine works by maintainers. Please try<BR>to use server
functi! ons as co! uld as possible.<BR><BR>dhcptest@tahi.org
Maintainer<BR>dhcptest-admin@tahi.org <BR><BR><BR></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find
your partner now.
<HR>
</DIV></DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
</DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
</DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
</DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
</DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<P>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com">Yahoo! India Matrimony</A>: Find your partner
now.
<HR>
</BODY></HTML>