Re: ICMPv6 over lo0
> On 16. Nov 2022, at 16:15, Zhenlei Huang wrote: > > >> On Nov 16, 2022, at 11:19 AM, Zhenlei Huang wrote: >> >>> >>> On Nov 16, 2022, at 5:14 AM, tue...@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 3 -s 2 ::1 >>> PING6(20048=40+8+2 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 metric 0 mtu 16384 >>> options=680003 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >>> inet 127.0.0.1 netmask 0xff00 >>> groups: lo >>> nd6 options=21 >>> 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 > >
Re: ICMPv6 over lo0
> On Nov 16, 2022, at 11:19 AM, Zhenlei Huang wrote: > >> >> On Nov 16, 2022, at 5:14 AM, tue...@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 3 -s 2 ::1 >> PING6(20048=40+8+2 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 metric 0 mtu 16384 >> options=680003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> inet 127.0.0.1 netmask 0xff00 >> groups: lo >> nd6 options=21 >> 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
Re: ICMPv6 over lo0
> On 16. Nov 2022, at 08:54, Andrey V. Elsukov wrote:
>
> 16.11.2022 00:14, tue...@freebsd.org пишет:
>> when using the master branch of today (or 13.1) I get when running
>> tuexen@ampere128:~ % ping6 -c 1 -b 3 -s 2 ::1
>> PING6(20048=40+8+2 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)
>> Why is for the Echo Request an MTU of 1280 used, whereas for the response an
>> MTU of 16384
>> is used.
>> Is this intended? At least for me, it is not expected...
>
> Hi Michael,
>
> I believe it is default behavior for ping6:
> ```
> -u By default, ping asks the kernel to fragment packets to fit into
>the minimum IPv6 MTU. The -u option will suppress the behavior
>in the following two levels: when the option is specified once,
>the behavior will be disabled for unicast packets. When the
>option is more than once, it will be disabled for both unicast
>and multicast packets.
> ```
>
> ```
> % ktrace ping6 -c 1 -b 3 -s 2 ::1
> % kdump | grep -A1 MIN_MTU
> 14793 ping6CALL
> setsockopt(0x3,IPPROTO_IPV6,IPV6_USE_MIN_MTU,0x7fffe614,0x4)
> 14793 ping6RET setsockopt 0
> ```
>
> ```
>if (mflag != 1) {
>optval = mflag > 1 ? 0 : 1;
>
>if (setsockopt(ssend, IPPROTO_IPV6, IPV6_USE_MIN_MTU,
>, sizeof(optval)) == -1)
>err(1, "setsockopt(IPV6_USE_MIN_MTU)");
>}
> ```
Hi Andrey,
thank you very much for the explanation! I wasn't aware of this.
Best regards
Michael
> --
> WBR, Andrey V. Elsukov
Re: ICMPv6 over lo0
16.11.2022 00:14, tue...@freebsd.org пишет:
when using the master branch of today (or 13.1) I get when running
tuexen@ampere128:~ % ping6 -c 1 -b 3 -s 2 ::1
PING6(20048=40+8+2 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)
Why is for the Echo Request an MTU of 1280 used, whereas for the response an
MTU of 16384
is used.
Is this intended? At least for me, it is not expected...
Hi Michael,
I believe it is default behavior for ping6:
```
-u By default, ping asks the kernel to fragment packets to fit into
the minimum IPv6 MTU. The -u option will suppress the behavior
in the following two levels: when the option is specified once,
the behavior will be disabled for unicast packets. When the
option is more than once, it will be disabled for both unicast
and multicast packets.
```
```
% ktrace ping6 -c 1 -b 3 -s 2 ::1
% kdump | grep -A1 MIN_MTU
14793 ping6CALL
setsockopt(0x3,IPPROTO_IPV6,IPV6_USE_MIN_MTU,0x7fffe614,0x4)
14793 ping6RET setsockopt 0
```
```
if (mflag != 1) {
optval = mflag > 1 ? 0 : 1;
if (setsockopt(ssend, IPPROTO_IPV6, IPV6_USE_MIN_MTU,
, sizeof(optval)) == -1)
err(1, "setsockopt(IPV6_USE_MIN_MTU)");
}
```
--
WBR, Andrey V. Elsukov
OpenPGP_signature
Description: OpenPGP digital signature
Re: ICMPv6 over lo0
> On Nov 16, 2022, at 5:14 AM, tue...@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 3 -s 2 ::1 > PING6(20048=40+8+2 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 metric 0 mtu 16384 > options=680003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff00 > groups: lo > nd6 options=21 > 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. > > Is this intended? At least for me, it is not expected... > > Best regards > Michael
