<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; =
charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version =
6.5.7638.1">
<TITLE>Tests that check for DNS and Domain Search Options</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hello,<BR>
<BR>
Many of the tests in the RFC 3646 and RFC 3736 sections of the DHCPv6 =
Self Test Suite 1.01 (and earlier) are failing for us for the wrong =
reason.<BR>
<BR>
The way our (client) product is currently behaving it requests these =
options:<BR>
<BR>
13 OPTION_STATUS_CODE<BR>
12 OPTION_UNICAST<BR>
23 OPTION_DNS_SERVERS<BR>
24 OPTION_DOMAIN_LIST<BR>
7 OPTION_PREFERENCE<BR>
<BR>
Many tests, for example, RFC 3646 - Test DHCP_CONF.4.1.1: Option Request =
option Format<BR>
PartA: Option request Option Format(DNS Recursive Name Server =
option)<BR>
<BR>
fail because option 13 is not option 23, according to the code:<BR>
<BR>
if($sol($optionCode != 23) {<BR> # Logging of failure message.<BR>
}<BR>
<BR>
Shouldn't the test be re-written to check whether or not option 23 is =
among the options requested<BR>
rather than whether or not it is the first option requested?<BR>
<BR>
Also, I know our client shouldn't be requesting option 12, Server =
Unicast, as that option should only appear in Reply messages coming from =
a server. I don't think you have any tests yet that check for the =
appearance of options in different message types as described in =
Appendix A of RFC3315.<BR>
<BR>
<A =
HREF="http://tools.ietf.org/html/rfc3315#page-98">http://tools.ietf.org=
/html/rfc3315#page-98</A><BR>
<BR>
Thanks.<BR>
<BR>
Scott Langley<BR>
Adecco Technical<BR>
slangley@tadboise.com<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>