Akisada-san,
Thanks for your kind response.
Yukiyo Akisada wrote:
> 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.
>
Indeed. I'll consider it.
> 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 for the information.
BTW, I found the way to enlarge the queue length.
I'd like to note it for the record. Just run the following command.
# sysctl -w net.inet6.icmp6.nd6_maxqueuelen=10
This works on FreeBSD6.1 or later.
On NetBSD4.0 or later, the command should be changed like this.
# sysctl -w net.inet6.icmp6.maxqueuelen=10
Thank you,
-toyo
> 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
>>
>>
>
>