From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id BC4DC3858425 for ; Mon, 4 Sep 2023 16:16:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC4DC3858425 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id F393C21846; Mon, 4 Sep 2023 16:16:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1693844195; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SISO8Euy3PnM103RTMeBr/OhczwTWB1LPjJ39bzoJGY=; b=PXvuKg/LzT7h+OaVh3XaPvgERsFzs+8BaTJ00+yEseXANo4REWvcCV39ETAomWAztcvVFG 1NJlQOiLXf560cusUjS0ujAd1JZxpWKr0kp/h2x5TbcZQNACIrU7qdFoafOfOvzFFUfhGl WsDhcOz4Nb+cbU2A8l0ntocsl6ywVdQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1693844196; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SISO8Euy3PnM103RTMeBr/OhczwTWB1LPjJ39bzoJGY=; b=SGjLcT89UeSfPa/XioQzNxcRX7sWB5nCTXwr5kjBC6iGvN5vkLmTj1Iz4lHmJWqn+hlVq3 IR7pkT7VCPNDHfCw== Received: from hawking.nue2.suse.org (unknown [10.168.4.11]) by relay2.suse.de (Postfix) with ESMTP id EDC272C142; Mon, 4 Sep 2023 16:16:35 +0000 (UTC) Received: by hawking.nue2.suse.org (Postfix, from userid 17005) id DF7DC4A04C0; Mon, 4 Sep 2023 18:16:35 +0200 (CEST) From: Andreas Schwab To: Florian Weimer Cc: Andreas Schwab via Libc-alpha Subject: Re: [PATCH] Update getaddrinfo to RFC 6724 (bug 29496) In-Reply-To: <87v8cqsznx.fsf@oldenburg3.str.redhat.com> (Florian Weimer's message of "Mon, 04 Sep 2023 17:53:22 +0200") References: <87v8cqsznx.fsf@oldenburg3.str.redhat.com> X-Yow: ... I live in a FUR-LINE FALLOUT SHELTER Date: Mon, 04 Sep 2023 18:16:35 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,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: On Sep 04 2023, Florian Weimer wrote: >> @@ -1653,7 +1667,7 @@ rfc3484_sort (const void *p1, const void *p2, void *arg) >> in_addr_t netmask2 = 0xffffffffu << (32 - a2->prefixlen); >> >> if ((in2_src_addr & netmask2) == (in2_dst_addr & netmask2)) >> - bit2 = fls (in2_dst_addr ^ in2_src_addr); >> + bit2 = a2->prefixlen; >> } > > 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()". > >> else if (a1->dest_addr->ai_family == PF_INET6) >> { >> @@ -1672,18 +1686,33 @@ rfc3484_sort (const void *p1, const void *p2, void *arg) >> >> int i; >> for (i = 0; i < 4; ++i) >> { >> + uint32_t mask1, mask2; >> + if (i * 32 >= a1->prefixlen) >> + mask1 = 0; >> + else if ((i + 1) * 32 > a1->prefixlen) >> + mask1 = 0xffffffffu << (32 - (a1->prefixlen & 31)); >> + else >> + mask1 = 0xffffffffu; >> + if (i * 32 >= a2->prefixlen) >> + mask2 = 0; >> + else if ((i + 1) * 32 > a2->prefixlen) >> + mask2 = 0xffffffffu << (32 - (a2->prefixlen & 31)); >> + else >> + mask2 = 0xffffffffu; >> + if (((in1_dst->sin6_addr.s6_addr32[i] >> + ^ in1_src->sin6_addr.s6_addr32[i]) & htonl (mask1)) != 0 >> + || ((in2_dst->sin6_addr.s6_addr32[i] >> + ^ in2_src->sin6_addr.s6_addr32[i]) & htonl (mask2)) != 0) >> + { >> + bit1 = fls (ntohl (in1_dst->sin6_addr.s6_addr32[i] >> + ^ in1_src->sin6_addr.s6_addr32[i]) >> + & mask1); >> + bit2 = fls (ntohl (in2_dst->sin6_addr.s6_addr32[i] >> + ^ in2_src->sin6_addr.s6_addr32[i]) >> + & mask2); >> + break; >> + } > > 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. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."