Abe-san,
> 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
Thanks for useful information.
I didn't know it!
On Wed, 16 Jul 2008 10:29:56 +0900
Toyo Abe <tabe@miraclelinux.com> wrote:
> 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
> >>
> >>
> >
> >
>
>
>
--
Yukiyo Akisada <akisada@tahi.org>