From nobody Wed Nov 16 15:15:05 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NC67t1Drxz4dGxQ for ; Wed, 16 Nov 2022 15:16:10 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NC67s1MW1z4Yqm; Wed, 16 Nov 2022 15:16:09 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="pxLtU/2w"; spf=pass (mx1.freebsd.org: domain of zlei.huang@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=zlei.huang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1030.google.com with SMTP id m14-20020a17090a3f8e00b00212dab39bcdso2663816pjc.0; Wed, 16 Nov 2022 07:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=Wb9QMoFPw3wgRJe+5kE0EM0h+SKvbiVcejz+ZlZARAk=; b=pxLtU/2wXW3l1YGE1Ktf1/5EQMZ20Y0GwLYe7IeKXubCKe/Lk/Rr6ddhDJxKZGYejj +ptzv7rvFeujCcCZelwr95O50FT7Wy3jxKnS6Obkogg1Dji6NS3+TpvKfHCv07dJqtXS OpVyJONkncLJHw8Fg6jPZoQvXKin6Wt6KYBBNsGvrTgkOUB4ZwPVAEmBsR82tAVcTEEj bnkTNg+9DGrYU4iowS6uT1psdclpWpMa/Um3mygBTFRA3d+C2ljaoy6hHXHFmlkA1KJj mI/x6R1CUbORwZ0h7sJqHVx3mt3McXgwKB7j0vASdB9LUYjH7yuoMc1KuMGTUgGof+PC KUOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Wb9QMoFPw3wgRJe+5kE0EM0h+SKvbiVcejz+ZlZARAk=; b=PWhhAntySCZUlstiAqcJ6ipPuxuBR+05AzkyPymRG1CRYzeov518tz9vC7mjsGfvWM MSvCmPDOhECTz0LEpPrYp0KkGd5lHReob+ByWlB2X2WMiih59XC+rfoXwPpOFgydcca8 e1O+w4rrluJq5Tc/A4+tKFSRPyxMNMTJ2dRZE4Ts/65afKqCZHDddY2tTmkH8qGsuYA4 4UeoEvyzzPnUEGNJ82+lh64g/Oxfmk2ZoAXy31WMx/7d//rEWW7lwUHv5Lks+1TxM54h u4pAgaOpdVINr+HCxwPwCrraXXsYe72I+LLZtGIGvBGafnKS2GsZ6CHp//bNRr0Y9utU LHIg== X-Gm-Message-State: ANoB5plaxFJAlcN0HdRS+aNRR6tx58Uy3KECiX4QULpM53QyT7vpth3f XRLLkMeU5w93E6WfexMRAZvXI5tHOGscoA== X-Google-Smtp-Source: AA0mqf7Kari3/xo7sKGD1QT/XbUoTufNXDUD8VMZkwtkdt7gFyEHYmtTS+acLQ/GdnbI8mtOdCzr0w== X-Received: by 2002:a17:903:110d:b0:186:ba52:1dc7 with SMTP id n13-20020a170903110d00b00186ba521dc7mr9368955plh.41.1668611767447; Wed, 16 Nov 2022 07:16:07 -0800 (PST) Received: from [172.17.252.129] (ns1.oxydns.net. [45.32.91.63]) by smtp.gmail.com with ESMTPSA id a11-20020a170902710b00b0018685aaf41dsm12284396pll.18.2022.11.16.07.16.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2022 07:16:07 -0800 (PST) From: Zhenlei Huang X-Google-Original-From: Zhenlei Huang Message-Id: <05FB9658-5293-4154-BB50-2E3A189DD306@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_578914C8-0B57-4ADA-A14B-0DA453CB8278" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: ICMPv6 over lo0 Date: Wed, 16 Nov 2022 23:15:05 +0800 In-Reply-To: Cc: freebsd-net To: tuexen@freebsd.org References: X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spamd-Result: default: False [-2.47 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_TO(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.967]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1030:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org] X-Rspamd-Queue-Id: 4NC67s1MW1z4Yqm X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_578914C8-0B57-4ADA-A14B-0DA453CB8278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 16, 2022, at 11:19 AM, Zhenlei Huang 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 metric 0 mtu 16384 >> options=3D680003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> inet 127.0.0.1 netmask 0xff000000 >> groups: lo >> nd6 options=3D21 >> 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. 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. >=20 >>=20 >> Is this intended? At least for me, it is not expected... >>=20 >> Best regards >> Michael --Apple-Mail=_578914C8-0B57-4ADA-A14B-0DA453CB8278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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=3D40+8+20000 bytes) ::1 = --> ::1
20008 bytes from ::1, icmp_seq=3D0 hlim=3D64 = time=3D0.709 ms

--- ::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

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=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.

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

= --Apple-Mail=_578914C8-0B57-4ADA-A14B-0DA453CB8278--