<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV><FONT face="Courier New" color=#000000 size=2>
<DIV><FONT face="Courier New" size=2>I'm running the Self Test sui=
te in the following configuration:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>* Environment: FreeBSD 6.3</FONT><=
/DIV>
<DIV><FONT face="Courier New" size=2>* Test Tool version: v6eval 3.0.15=
</FONT></DIV>
<DIV><FONT face="Courier New" size=2>* Self Test package version 4-0-2<=
/FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>I have a question about the test v=
6LC.2.2.7E, which looks at the prefixes in Router Advertisements when a zer=
o-ending prefix is configured.</FONT></DIV>
<DIV> </DIV>
<DIV>The test adds the prefix 8000::/64 to the NUT, and looks at the next R=
A generated. In response, the NUT generates an RA with two prefixes: 3ffe:5=
01:ffff:100::/64 and 8000::/64. The first prefix corresponds to the global =
address configured on the interface for all the tests.</DIV>
<DIV> </DIV>
<DIV>The test then fails because it fails to recognize the 3ffe:501:ffff:10=
0::/64 prefix as valid.</DIV>
<DIV> </DIV>
<DIV>I can "fix" this problem by removing the 3ffe:501:ffff:100::/64 from t=
he interface for the test, and re-configuring it again afterward. The NUT t=
hen generates the RA with just the 8000::/64 prefix, and the test passes.</=
DIV>
<DIV> </DIV>
<DIV>
<DIV>However, the inclusion of both prefixes seems to be the correct behavi=
our. From RFC 4861:</DIV>
<DIV> </DIV>
<DIV> Prefix Information<BR>  =
; &n=
bsp; These options specify the prefixes that are on=
-link<BR> =
and/or are used for =
stateless address<BR> =
autoconf=
iguration. A router SHOULD include all its<BR>  =
; &n=
bsp; on-link prefixes (except the link-local prefix) so<B=
R> &=
nbsp; that multihomed hosts have =
complete prefix<BR> &n=
bsp; informatio=
n about on-link destinations for the<BR>  =
; &n=
bsp; links to which they attach. If complete<BR> &nb=
sp; =
information is lacking, a host with multiple=
<BR>  =
; interfaces may not be abl=
e to choose the correct<BR> =
ou=
tgoing interface when sending traffic to its<BR> &nb=
sp; =
neighbors.</DIV>
<DIV> </DIV>
<DIV>Should the test be changed to allow the 3ffe:501:ffff:100::/64 in addi=
tion to the 8000::/64 prefix? Or is expected that the NUT will remove the e=
xisting global address when the 8000::/64 address is added? Or should =
the NUT not include both prefixes in the RA?</DIV>
<DIV> </DIV>
<DIV>Thanks in advance,</DIV>
<DIV> </DIV>
<DIV>Peter Hunt</DIV>
<DIV>
<DIV>Software Engineer</DIV>
<DIV>Nokia S&S</DIV></DIV></DIV>
<DIV> </DIV></FONT></DIV></BODY></HTML>