Implementing TAHI for dummies
-----------------------------
12/11/02
jzwiebel

The current conformance test standard for IPv6 implementations can be found
at www.tahi.org.  This is a Japanese organization supported by several 
Japanese companies that in combination with other organizations is 
dedicated to the standardization of IPv6.  The TAHI conformance tests
are comprehensive and extensive.  However, if you cannot read Japanese,
the documentation on how to use these tools is limited and confusing.  This
document is an attempt to provide you with a road map that will help you
through this confusion.

The TAHI tool can be effectively used without connecting the serial port
of the TN to the NUT.  Unless you have a lot of time on your hands, you
may want to put this step off indefinitely.  However, approximately 50%
of the tests will require this capability.  This is especially true with the
neighbor discovery tests.

Many will want to be able to run this test from a remote location.  One of 
the best ways to gain an understanding of the tool while making the results 
widely available is to:

  1) install the tool following the INSTALL instructions, but ignore
     any references to the serial line communication requirements.
  2) install p5-Expect: /usr/ports/lang/p5-Expect
  3) install apache: /usr/ports/www/apache13+ipv6, start it up.
  4) cp -pR /usr/local/v6eval/ct  $SOMEWHERE
     where SOMEWHERE is in /usr/local/www/data to allow remote access
     to the reports via Netscape. 
  5) cd to $SOMEWHERE/ct and "make clean" "make document".
     This will build a complete web site that describes each of the
     tests that TAHI will perform.
  6) Access the web site and review several tests.  The first test
     is PingtoHost.  Note especially the synopsis.  PingtoHost.seq
     and PingtoHost.def will be found in the $SOMEWHERE/ct directory
     you have just created.  You can run this test manually from 
     this directory or from /usr/local/v6eval/ct/spec.
  7) Do a "man V6evalTool".  This describes the options available to
     you when running the *.seq files in ct/.  You may find the man
     on "V6evalRemote" to be useful, but only if you want to connect
     the TN to the NUT via the serial line.
  8) Configure your TN and NUT with IPv6 addresses on LINK0.
     You may want to try pinging the NUT from the TN.
  9) in the $SOMEWHERE/ct directory "./PingToHost.seq -pkt PingToHost.def"

You have now run your first TAHI conformance test case.  You may want to
run "make clean" "make test" in this directory after you have modified the
Makefile to run only those tests you are interested in.  

NOTE: the serial communication between the TN and the NUT is -NOT- set up.
NOTE: if you want to run tests agains a router, you need to configure
      additional interfaces.  (see below)

The remainder of this document describes pitfalls you may find when
setting TAHI up for the first time.  

INSTALL.[v6eval|ct]
-------------------

The INSTALL files explain how to build the TAHI source tree.  If you 
follow the instructions and build the tool on a IPv6 enabled KAME FreeBSD
system you will have little trouble building the tool.  The problems come
when you try to configure and use the tool.  Most of these problems are
related to setting up the tool to remotely control the NUT via a NULL
modem cable.  If you are setting up the tool for the first time, ignore
this information.  Further explaination is below

SUBDIRUSE
---------

The first problem you may run into is the name change of the FreeBSD
make macro SUBDIRUSE to SUBDIR.  This changed somewhere between FreeBSD 4.6
and 4.7.  The 2.0.2 TAHI tools are built for FreeBSD 4.7 and use the SUBDIR
macro.  If you want to avoid problems, the easiest thing to do is to make
sure you have FreeBSD 4.7 on your system (as of this date).

tn.def
------

This configuration file is described in both the INSTALL.v6eval and
INSTALL.ct files.  Most of the configuration items are concerned with
remote control of the NUT by the TN through the TN serial port connected
to a console port on the NUT.  This capability is very powerful, but it
is very difficult to set up and get right.  Even if you are trying to
set up a FreeBSD system as the NUT, this will be difficult to get configured
correctly.  In the end though, it is not required to make extensive use
of the TAHI tools.

The only lines you need to configure are those that match LINK0 and
LINK1 (if you are testing a router) to the real name of the interface 
on your TN.  Leave the others as default.

nut.def
------

The only configuration items of importance here are also those that match
LINK0 (and LINK1 if the NUT is a router) with the real MAC address of the
NUT -AND- the "type" value [host|router].  All other configuration items 
are used to set up the remote control of the NUT from the TN over the 
serial line.

The "System" entry is used to determine which set of remote-control 
scripts will be used by autorun.  These scripts are found in the 
/user/local/v6eval/bin directory.  You won't be using them if you follow
the steps outlined in this document.

nut type
--------

If the NUT type is a "router", you must set up the TN and NUT on LINK0 and
LINK1.  The NUT must be configured with an address of "3ffe:501:ffff:100/64"
on LINK0 and "3ffe:501:ffff:101/64" on LINK1.  The TN will automaticall use 
these prefixes whenever any router tests are run.

Serial communication
--------------------

The INSTALL files go into great detail about how to set up serial communication
between the TN and the NUT.  Do not consider doing this until you've had
the opportunity to run the tests a few times after manually configuring the
test setup.  The serial communication can be set up using any port out
and any port in.  INSTALL.ct shows how to set up /etc/ttys to use the
cuaa* drivers.  Many folks use ttyd0 as a serial console.  You need to
make sure that whatever port you use on the TN that "getty" is set to
"off".  On the NUT, "getty" is set to "on".

My experience has been that if I tried to run the TAHI "make test", out
any port other than cuaa0, the perl script would always hang waiting for
a "login" prompt.  Even when I did use cuaa0, the script would still
hang about 50% of the time on the "login" prompt.  When the script did
not hang, remote control of the NUT still always failed.  There was never
any problem using "cu -l /dev/cuaa?" to manually connect to the NUT.  

bpf filters
-----------

If you try to run these tests without configuring IPv6 on the TN you
will receive the following somewhat cryptic error:
  ipv6-bsd2# ./PingToHost.seq  -pkt PingToHost.def
   can't open bpf or socket
