From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6AD5D3858D32 for ; Tue, 5 Sep 2023 12:19:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6AD5D3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693916349; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Xw6gWD3clOsZPaxTiQ0RJymd03HnyKlWBbxLKVIE6q8=; b=ESKd7FM7+AhzoLfuGAOrBv6flV8qyzOWQg2xg9vo/7ZocmeCn0NzTcCgR729Qah5IrktF8 NkTIlvxDEkAga8BDQv5qoM5qcCMYw0q0KKa0Icle8HR5Grnh7Pjdsi7PZsLIFAD108hWpH ylXt35GHDc1sJ01fngFK3X95Bdua73o= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-546-ZhiFnBoKMGu6ebtZqcaolw-1; Tue, 05 Sep 2023 08:19:07 -0400 X-MC-Unique: ZhiFnBoKMGu6ebtZqcaolw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 77B9428EA6FC; Tue, 5 Sep 2023 12:19:07 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.42]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F1A14C03291; Tue, 5 Sep 2023 12:19:06 +0000 (UTC) From: Florian Weimer To: Andreas Schwab Cc: Andreas Schwab via Libc-alpha Subject: Re: [PATCH] Update getaddrinfo to RFC 6724 (bug 29496) References: <87v8cqsznx.fsf@oldenburg3.str.redhat.com> Date: Tue, 05 Sep 2023 14:19:05 +0200 In-Reply-To: (Andreas Schwab's message of "Mon, 04 Sep 2023 18:16:35 +0200") Message-ID: <87jzt47qyu.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Andreas Schwab: > On Sep 04 2023, Florian Weimer wrote: > >>> @@ -1653,7 +1667,7 @@ rfc3484_sort (const void *p1, const void *p2, voi= d *arg) >>> =09 in_addr_t netmask2 =3D 0xffffffffu << (32 - a2->prefixlen); >>> =20 >>> =09 if ((in2_src_addr & netmask2) =3D=3D (in2_dst_addr & netmask2)) >>> -=09 bit2 =3D fls (in2_dst_addr ^ in2_src_addr); >>> +=09 bit2 =3D a2->prefixlen; >>> =09} >> >> This is an undocumented change that I can't find in RFC 6724. > > See Appendix B, changes to the rules, "Changed the definition of > CommonPrefixLen()". So it's the =E2=80=9Cup to the length of S's prefix=E2=80=9D part here: | 2.2. Common Prefix Length |=20 | We define the common prefix length CommonPrefixLen(S, D) of a source | address S and a destination address D as the length of the longest | prefix (looking at the most significant, or leftmost, bits) that the | two addresses have in common, up to the length of S's prefix (i.e., | the portion of the address not including the interface ID). For | example, CommonPrefixLen(fe80::1, fe80::2) is 64. There's an erratum for this because not all addresses have interface IDs, so this is just confusing. In any case, new code still does not implement the rule that prefers longer common prefixes. Our rule goes like this, if I understand the code correctly: * If one source/destination pair is on the same subnet and the other is not, prefer the first. * If both source/destination pairs are on the same (but potentially distinct) subnets, prefer the smaller subnet, the one with the longer prefix. I still think the second, length-based heuristic is dubious. In any case, it doesn't match what's in the RFC (and there's an old comment to that effect). To reiterate, I think that's fine, and we should go further. >>> @@ -1672,18 +1686,33 @@ rfc3484_sort (const void *p1, const void *p2, v= oid *arg) >>> =20 >>> =09 int i; >>> =09 for (i =3D 0; i < 4; ++i) >>> =09 { >>> +=09 uint32_t mask1, mask2; >>> +=09 if (i * 32 >=3D a1->prefixlen) >>> +=09=09mask1 =3D 0; >>> +=09 else if ((i + 1) * 32 > a1->prefixlen) >>> +=09=09mask1 =3D 0xffffffffu << (32 - (a1->prefixlen & 31)); >>> +=09 else >>> +=09=09mask1 =3D 0xffffffffu; >>> +=09 if (i * 32 >=3D a2->prefixlen) >>> +=09=09mask2 =3D 0; >>> +=09 else if ((i + 1) * 32 > a2->prefixlen) >>> +=09=09mask2 =3D 0xffffffffu << (32 - (a2->prefixlen & 31)); >>> +=09 else >>> +=09=09mask2 =3D 0xffffffffu; >>> +=09 if (((in1_dst->sin6_addr.s6_addr32[i] >>> +=09=09 ^ in1_src->sin6_addr.s6_addr32[i]) & htonl (mask1)) !=3D 0 >>> +=09=09 || ((in2_dst->sin6_addr.s6_addr32[i] >>> +=09=09 ^ in2_src->sin6_addr.s6_addr32[i]) & htonl (mask2)) !=3D = 0) >>> +=09=09{ >>> +=09=09 bit1 =3D fls (ntohl (in1_dst->sin6_addr.s6_addr32[i] >>> +=09=09=09=09 ^ in1_src->sin6_addr.s6_addr32[i]) >>> +=09=09=09 & mask1); >>> +=09=09 bit2 =3D fls (ntohl (in2_dst->sin6_addr.s6_addr32[i] >>> +=09=09=09=09 ^ in2_src->sin6_addr.s6_addr32[i]) >>> +=09=09=09 & mask2); >>> +=09=09 break; >>> +=09=09} >> >> Why use the common prefix length for IPv6 addresses? RFC 6724 pretends >> that IPv6 assignment is strictly hierarchical, but in reality, it's >> not. Shouldn't we do the same thing as for IPv4 addresses? > > That's the same consequence as above due to the changes in > CommonPrefixLen. But it doesn't implement the same algorithm, as far as I can tell. I think we should use this in both cases: * If one source/destination pair is on the same subnet and the other is not, prefer the first. Thanks, Florian