Hi, Abe-san.
For 1st question)
You can use them for your environment.
Your list satisfies IPv6 Ready Logo requirements,
but I have a suggestion about it.
I feel that using other OS (ex, Open BSD) is better than KAME
because KAME already had stopped the activity long time ago.
If you have the product other than free software OS,
using the product is the best.
For 2nd question)
It is the correct behavior according to RFC 4861.
7.2.2. Sending Neighbor Solicitations
------------------------------------------------------------------------
3440 While waiting for address resolution to complete, the sender MUST,
3441 for each neighbor, retain a small queue of packets waiting for
3442 address resolution to complete. The queue MUST hold at least one
3443 packet, and MAY contain more. However, the number of queued packets
3444 per neighbor SHOULD be limited to some small value. When a queue
3445 overflows, the new arrival SHOULD replace the oldest entry. Once
3446 address resolution completes, the node transmits any queued packets.
------------------------------------------------------------------------
Thanks,
On Mon, 07 Jul 2008 14:46:02 +0900
Toyo Abe <tabe@miraclelinux.com> wrote:
> Hello,
>
> I have two questions WRT interoperability test for host category of phase2-core.
>
> One is whether the test environment is acceptable or not.
> My environment is as follows.
> LOGO:
> Our product, which is Linux box.
> REF-1:
> FreeBSD 6.0-RELEASE-p7
> REF-2:
> FreeBSD 6.0-RELEASE-p7
> TAR-Host1:
> FreeBSD 6.0-RELEASE-p7
> TAR-Host2:
> USAGI(usagi-linux26-stable-20050714.tar.bz2) on Debian3.1r8
> TAR-Router1:
> NetBSD 2.0.2
> TAR-Router2:
> KAME(kame-20080601-netbsd20-snap.tgz) on NetBSD 2.0.2
>
>
> Another one is related to IP6Interop.1.6(spec version is 2.8.4), which is
> Path MTU Discovery and Fragmentation test.
> This kind of question might be inappropriate here, but I'd like to know
> if anyone had seen the same problem before or has a workaround.
>
> interop.1.6.x requires TAR/REF box to send fragmented ICMPv6 ECHO packets
> to LOGO. However, all BSDs listed above conditionally fail to send out only
> the 1st fragmented packet.
> Usually they successfully send the fragmented pings. But they fail in case that
> no NCE for ping destination exist. When there isn't NCE for destination, BSD box
> initiates ND to figure out who is the destination. After it's completed, only
> the 1st fragmented packet appears to be dropped on BSD box.
> I'm wondering why, and worrying that if this will be a serious problem for
> getting Logo application.
>
>
> Thank you,
> -toyo
>
>
--
Yukiyo Akisada <akisada@tahi.org>