Vlad ,
Thanks for your comments.
1) The last sentence of RFC 2461 - 7.2.3 sez:
"After any updates to the Neighbor Cache, the node sends a Neighbor
Advertisement response as described in the next section."
There is one Tahi P2 test that gives an error if an NA is sent, in
answer to an NS, when there is no Neighbor Cache update. However the
same code doesn't work with a long FTP transfer with a FreeBSD machine,
because FreeBSD sends occasional unicast NS that does not cause Neighbor
Cache updates, hence the problem.
2) RFC2461 - 5.3. Garbage Collection and Timeout Requirements, does specify
that there be cache purges, but doesn't spec the time delay between the purges.
The Tahi tests are wonderfully thorough, but espcially if you work on an embedded system that doesn't have "cu" (which Tahi uses for its out of band synchronization),
you have to solve the problem some other way.
Tx,
tim
Vlad Yasevich wrote:
Tim McFadden wrote:
Hi folks,
I have raised some of these issues before, but we (Interniche
Technologies, Inc.) are now getting closer to trying to officially pass
Tahi Phase 2, so would like to know what the current thought on these
issues is.
The code we use for Tahi P2 tests won't work for most long FreeBSD FTP
transfers, because FreeBSD sends occasional NS and relies on the NA reply.
What is this NS for? Is it part of NUD (i.e unicast NS)?
RFC 2461 - 7.2.3 sez that an NA is sent after an NS that updates the
cache and Tahi P2 checks that an NA is not sent otherwise. Hence, there
is then at least one interoperability problem forced on us by the Tahi
P2 tests.
Unless NS is ignored, there should always be an NA. I am really not
sure what scenario you are describing.
If this is a NUD scenario, do you implement reachability notification by
transport layer (tranport is making forward progress)?
We pass many Tahi P2 tests only because our code receives out of band
IPv4 traffic between tests from modified Tahi Perl scripts. For example,
we changed Tahi's
/usr/local/v6eval/bin/autorun to signal us via IPv4 ping to clear our ND
cache between tests.
The IPv6 spec does not specify the time delay between ND cache purges,
so we are free to do this.
In fact, IPv6 doesn't specify ND6 cache purges at all. It doesn't
matter how you do this, because all tahi wants is an empty Neighbor Cache.
We also changed other Tahi scripts, to issue out of band IPv4 signals,
to allow us to restart our IPv6 code (without reboot), so we don't have
to download a device before each P2 Stateless test.
I think that OK to as long as you comletely reset the IPv6 state...
-vlad
In summary, we do well on Tahi P2 and can interop well by knowledgeably
changing variables between tests.
Please comment, if you would.
Tx,
Tim McFadden
--------------------------------------
Interniche Technologies, Inc.
51 East Campbell Avenue, Suite 160
Campbell, CA 95008
408-540-1160x207
[EMAIL PROTECTED]
www.iniche.com
--------------------------------------
---------------------------------------------------------------------
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
---------------------------------------------------------------------
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
