Hi, Mr. Volz,
I feel very glad to receive your reply.
> A suggestion: when the tests are run manually, it would be
> nice if there was a way to REPEAT a test.
I think maybe what you want is to run just one test script instead of all.
There is a method to do it.
Please add the "AROPT" option.
Like this,
% make AROPT="-s 17 -e 20" test
^|^^^ ^^^^^+ end test No. which you want
+ start test No. which you want
>When running through the complete
> tests, it wasn't always clear how the server should be configured and thus there
> were times when a test failed because I hadn't configured the server
> correctly.
Because of there are many kind of test targets of DHCPv6 servers,
only simple prompts(like... address,option...) is appears in the test process
to use for all of the test targets.
For more easy to understand by user, I'm thinking about how to improve it.
How about you think of it, please tell me.
Thanks.
> > > 2. For S_RFC3315_15_DiscardSolicitwithInvalidOP.seq,
> > > S_RFC3315_15_DiscardRenewwithInvalidOP.seq, and
> > > S_RFC3315_15_DiscardDeclinewithInvalidOP.seq,
> > > S_RFC3315_15_DiscardReleasewithInvalidOP.seq,
> > > S_RFC3315_15.10_ClientIDOPMatch.seq, I see nothing in RFC
... ...
> BV> Right. But I kind of view this differently. My view is that:
> A) Servers are usually designed for performance and checking
> for things
> that shouldn't be there and otherwise don't cause an issue, isn't
> something worth wasting processing power on. This is different than
> checking for things that are explicitly needed or would cause
> issues if
> present (such as having a server-identifier option in a REBIND).
> B) This requires constant maintenance because as new options are
> defined, new rules must be added to the server for some
> options to check
> whether they are present or not (a simple table or flag in an
> option can
> likely handle most cases). Until these new rules are incorporated, no
> checking can be done for them (a server can't simply drop a packet
> because it includes some unknown option code).
> C) It is a SHOULD and not a MUST.
Based A) & B), I think it looks not necessary to check the other option
in the DHCPv6 messages received by server. And if a new option is added
in the message, the process of only discard the message is not properly.
So I think whether the text in the RFC3315 need to be update because
it only said "diacard the message". Is it looks better, that is ,
'Server process the necessary option and discard the unknown and
invalid options.'
In our test tool, the "SHOULD" is be thinked of advanced fuction
and realized in the furture. In current stage, we only checked the options
listed in the RFC3315. As a validation tool for RFC, I think it is necessary
to cover all the items of "MUST" and "SHOULD".
> > > 5. In S_RFC3315_22.13_StatusCodeOP.seq, the following message
> > > is sent and the expected response is a Reply with a Status
> > > Code option? Why?
> > > What's wrong with this request? Is the absense of an IAADDR
> > > option in the IA_NA option supposed to generate an error? If
> > > so, this is mistaken as I don't see that an IAADDR option
> > is required.
> > >
> > > Or, is there something I missed in this test sequence
> > > (SOLICIT/ADVERTISE/REQUEST/REPLY)?
> > >
> > > R10: ----- RECEIVED -- R10 -----
> > > R10: -> received 56 bytes from fe80::200:ff:fe00:a2a2,
> port 1027
> > > R10: -> +- Start of REQUEST (3) message (56 bytes)
> > > R10: -> | transaction-id 101
> > > R10: -> | client-identifier (1) option (14 bytes)
> > > R10: -> | 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2
> > > R10: -> | server-identifier (2) option (14 bytes)
> > > R10: -> | 00:01:00:01:43:b2:b2:e5:00:03:ba:6c:9f:b9
> > > R10: -> | ia-na (3) option (12 bytes)
> > > R10: -> | (iaid 101010, t1 1h6m40s, t2 1h23m20s)
> > > R10: -> +- End of REQUEST message
> > > R10: ----- END OF RECEIVED -- R10 -----
> > The expected test result of it is check the format of status
> > code option.
> > Would you show me the log file of this test item.
> > I guess it is same as the problem 4. That is, the the test
> > expects the
> > Status Code option to be in the main part of the Reply. I
> > plan to change
> > it and let it accept both "in IA option" and "in main part".
>
> The server's REPLY didn't have a Status Code option. Thus my question
> about what was expected or intended for this test.
The goal of the test is to check whether a Status Code option is replyed
when the server can not assign address. In the initial setting of server,
the address pool has not been set up. So the addresses do not be assigned.
But in the log file in your email, this address have been assigned,
Addr= 3333::949c:6d58:d6ec:1057
I think that's why the status code option didn't appear.
> >
> > > 6. None of the relay tests appear to be working for me.
> > > I notice that the client requests are coming from and being
> > > sent to fe80::200:ff:fe00:a2a2, which works fine. However,
> > > the relay requests are coming from fe80::200:ff:fe00:a4a4 and
> > > this does not work (ie, replies aren't received). I am
> > > running on FreeBSD 6.0? Perhaps I missed up something in
> the setup?
&
> Thus, the TN is ignoring our Relay-Reply because the address
> isn't what
> it expected:
>
> ng compare _HDR_IPV6_relay_reply_nut_relay.SourceAddress
> received:2001:420:3800:4801:203:baff:fe6c:9fb8 =
> fe80::203:baff:fe6c:9fb8
>
> Perhaps we can look at the request's source address instead of the
> destination address when chosing the address to use in the
> Relay-Reply.
I think maybe they are same.
The check of source address of Relay-reply message is not necessary.
The script is updating for making actions like this.
Sincerely yours,
Haoda