Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Nov 2022 00:28:35 +0100
From:      tuexen@freebsd.org
To:        Zhenlei Huang <zlei.huang@gmail.com>
Cc:        freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: ICMPv6 over lo0
Message-ID:  <CB93E7D6-6390-4DB3-9278-86C882E8A6A1@freebsd.org>
In-Reply-To: <05FB9658-5293-4154-BB50-2E3A189DD306@FreeBSD.org>
References:  <DDDFD026-72AF-4558-93E4-60D361C671DF@freebsd.org> <D353907A-2295-46B8-9F3A-C4AC0370C8E0@FreeBSD.org> <05FB9658-5293-4154-BB50-2E3A189DD306@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 16. Nov 2022, at 16:15, Zhenlei Huang <zlei.huang@gmail.com> wrote:
>=20
>=20
>> On Nov 16, 2022, at 11:19 AM, Zhenlei Huang <zlei@FreeBSD.org> wrote:
>>=20
>>>=20
>>> On Nov 16, 2022, at 5:14 AM, tuexen@freebsd.org wrote:
>>>=20
>>> Dear all,
>>>=20
>>> when using the master branch of today (or 13.1) I get when running
>>>=20
>>> tuexen@ampere128:~ % ping6 -c 1 -b 30000 -s 20000 ::1
>>> PING6(20048=3D40+8+20000 bytes) ::1 --> ::1
>>> 20008 bytes from ::1, icmp_seq=3D0 hlim=3D64 time=3D0.709 ms
>>>=20
>>> --- ::1 ping6 statistics ---
>>> 1 packets transmitted, 1 packets received, 0.0% packet loss
>>> round-trip min/avg/max/std-dev =3D 0.709/0.709/0.709/0.000 ms
>>>=20
>>> which is expected. What I don't expect is:
>>>=20
>>> tuexen@ampere128:~ % tcpdump -i lo0 -n
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol =
decode
>>> listening on lo0, link-type NULL (BSD loopback), capture size 262144 =
bytes
>>> 22:06:38.835630 IP6 ::1 > ::1: frag (0|1232) ICMP6, echo request, =
seq 0, length 1232
>>> 22:06:38.835639 IP6 ::1 > ::1: frag (1232|1232)
>>> 22:06:38.835641 IP6 ::1 > ::1: frag (2464|1232)
>>> 22:06:38.835641 IP6 ::1 > ::1: frag (3696|1232)
>>> 22:06:38.835642 IP6 ::1 > ::1: frag (4928|1232)
>>> 22:06:38.835642 IP6 ::1 > ::1: frag (6160|1232)
>>> 22:06:38.835643 IP6 ::1 > ::1: frag (7392|1232)
>>> 22:06:38.835644 IP6 ::1 > ::1: frag (8624|1232)
>>> 22:06:38.835644 IP6 ::1 > ::1: frag (9856|1232)
>>> 22:06:38.835645 IP6 ::1 > ::1: frag (11088|1232)
>>> 22:06:38.835645 IP6 ::1 > ::1: frag (12320|1232)
>>> 22:06:38.835646 IP6 ::1 > ::1: frag (13552|1232)
>>> 22:06:38.835647 IP6 ::1 > ::1: frag (14784|1232)
>>> 22:06:38.835647 IP6 ::1 > ::1: frag (16016|1232)
>>> 22:06:38.835648 IP6 ::1 > ::1: frag (17248|1232)
>>> 22:06:38.835648 IP6 ::1 > ::1: frag (18480|1232)
>>> 22:06:38.835649 IP6 ::1 > ::1: frag (19712|296)
>>> 22:06:38.836002 IP6 ::1 > ::1: frag (0|16336) ICMP6, echo reply, seq =
0, length 16336
>>> 22:06:38.836006 IP6 ::1 > ::1: frag (16336|3672)
>>> ^C
>>> 19 packets captured
>>> 19 packets received by filter
>>> 0 packets dropped by kernel
>>>=20
>>> Why is for the Echo Request an MTU of 1280 used, whereas for the =
response an MTU of 16384
>>> is used.
>>>=20
>>> Since
>>> tuexen@ampere128:~ % ifconfig lo0
>>> lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>>> options=3D680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
>>> inet6 ::1 prefixlen 128
>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
>>> inet 127.0.0.1 netmask 0xff000000
>>> groups: lo
>>> nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL>
>>> is used, I would expect an MTU of 16384 also be used for the Echo =
Request instead of
>>> the minimum IPv6 MTU of 1280.
>>=20
>> I believe MTU of 16384 should be used for Echo Request.
>=20
> That is by intuition.
Sure. My fault.
>=20
> RFC 3542 introduced IPV6_USE_MIN_MTU and FreeBSD implemented it in =
33841545909f4.
>=20
> IPv6 is different from IPv4 of fragmentation, intermediate routers are =
not allowed to do fragmentation
> and thus PMTU is a must (or a minimal MTU should be chosen).
>=20
> Section 11.1 in RFC 3542:
> >  For unicast destinations path
> >   MTU discovery should be performed by default.  For multicast
> >   destinations path MTU discovery should be disabled by default.
>=20
> For simple ping6 program it seems disable performing PMTU for both =
unicast and multicast destinations
> by default is lightweight. In most cases we do not send large payload =
via ping6.
Well, I use it for testing reachability as a function of the packet =
size.
So I did not expect that it uses the minimum MTU instead of the =
interface/route MTU.
But now I know that I have to use -u when using IPv6.

Best regards
Michael
>=20
>>=20
>>>=20
>>> Is this intended? At least for me, it is not expected...
>>>=20
>>> Best regards
>>> Michael
>=20
>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CB93E7D6-6390-4DB3-9278-86C882E8A6A1>