Re: ICMPv6 over lo0
- Reply: tuexen_a_freebsd.org: "Re: ICMPv6 over lo0"
- In reply to: Zhenlei Huang : "Re: ICMPv6 over lo0"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 16 Nov 2022 15:15:05 UTC
> On Nov 16, 2022, at 11:19 AM, Zhenlei Huang <zlei@FreeBSD.org> wrote: > >> >> On Nov 16, 2022, at 5:14 AM, tuexen@freebsd.org wrote: >> >> Dear all, >> >> when using the master branch of today (or 13.1) I get when running >> >> tuexen@ampere128:~ % ping6 -c 1 -b 30000 -s 20000 ::1 >> PING6(20048=40+8+20000 bytes) ::1 --> ::1 >> 20008 bytes from ::1, icmp_seq=0 hlim=64 time=0.709 ms >> >> --- ::1 ping6 statistics --- >> 1 packets transmitted, 1 packets received, 0.0% packet loss >> round-trip min/avg/max/std-dev = 0.709/0.709/0.709/0.000 ms >> >> which is expected. What I don't expect is: >> >> 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 >> >> Why is for the Echo Request an MTU of 1280 used, whereas for the response an MTU of 16384 >> is used. >> >> Since >> tuexen@ampere128:~ % ifconfig lo0 >> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 >> options=680003<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=21<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. > > I believe MTU of 16384 should be used for Echo Request. That is by intuition. RFC 3542 introduced IPV6_USE_MIN_MTU and FreeBSD implemented it in 33841545909f4. 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). 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. 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. > >> >> Is this intended? At least for me, it is not expected... >> >> Best regards >> Michael