Hi, Rommel.
You may already solved this problem,
but please let me clarify this behavior.
The packet loss often occurs when the packet is fragmented.
This behavior is related to
the number of waiting queues for the address resolution.
RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
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.
If the node has only 1 queue,
the initial fragmented packet is overrode by the subsequent fragmented packet
while the sender is performing the address resolution.
If you check tcpdump,
you will see that only 2nd fragmented packet appears on the wire.
The expected value depends on the implementation which you prepared.
For example of 1.6.D,
if all nodes have only 1 queue, 3 echo requests will be dropped.
TAR REF REF TAR
Router1 Router2 Router3 Host1
| | | |
|------>| | | NS
|<------| | | NA
|------>| | | Echo Request [1] (1500 bytes)
|<------| | | Packet Too Big
| | | |
|------>| | | Echo Request [2] (1st fragment)
|------>| | | Echo Request [2] (2nd fragment)
| |------>| | NS
| |<------| | NA
| |------>| | Echo Request [2] (2nd fragment)
| | |------>| NS
| | |<------| NA
| | |------>| Echo Request [2] (2nd fragment)
| | | |
|------>| | | Echo Request [3] (1st fragment)
|------>| | | Echo Request [3] (2nd fragment)
| |------>| | Echo Request [3] (1st fragment)
| |------>| | Echo Request [3] (2nd fragment)
| | |------>| Echo Request [3] (1st fragment)
| | |------>| Echo Request [3] (2nd fragment)
| | |<------| Echo Reply [3] (1500 bytes)
| | |------>| Packet Too Big
| | | |
|------>| | | Echo Request [4] (1st fragment)
|------>| | | Echo Request [4] (2nd fragment)
| |------>| | Echo Request [4] (1st fragment)
| |------>| | Echo Request [4] (2nd fragment)
| | |------>| Echo Request [4] (1st fragment)
| | |------>| Echo Request [4] (2nd fragment)
| | |<------| Echo Reply [4] (1st fragment)
| | |<------| Echo Reply [4] (2nd fragment)
| |<------| | Echo Reply [4] (1st fragment)
| |<------| | Echo Reply [4] (2nd fragment)
|<------| | | Echo Reply [4] (1st fragment)
|<------| | | Echo Reply [4] (2nd fragment)
| | | |
V V V V
Thanks,
On Wed, 17 Dec 2008 11:05:51 +0800
"Rommel Laranjo" <rslaranjo@gmail.com> wrote:
> Hello to all tahi users,
> I know this post is not related to using the TAHI script because I'm doing
> manual IPv6 Interoperability Testing.
> But I just hope someone would be kind enough to share their expert knowledge
> about Interoperability Testing.
>
> I am now performing Test IP6Interop.1.6: Path MTU Discovery and
> Fragmentation Part D steps 23 to 27.
> My question is this, is it normal to see packet loss about 90% or sometimes
> 80% when I ping from TAR-Router1 to
> TAR-Host1 ? and from TAR-Host1 to TAR-Router1 ?
>
> If there would be packet loss, how much would be the expected value?
>
> I gladly appreciate your replies.
>
>
> Thanks,
>
> Rommel
>
--
Yukiyo Akisada <akisada@tahi.org>