Re: ICMPv6 over lo0

> On 16. Nov 2022, at 16:15, Zhenlei Huang <zlei.huang@gmail.com> wrote:
> 
> 
>> 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.
Sure. My fault.
> 
> 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.
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
> 
>> 
>>> 
>>> Is this intended? At least for me, it is not expected...
>>> 
>>> Best regards
>>> Michael
> 
>