From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D1C483B29D for ; Wed, 28 Feb 2024 06:40:59 -0500 (EST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 41SBevJL015326; Wed, 28 Feb 2024 12:40:57 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0394DA45DD; Wed, 28 Feb 2024 12:40:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-type:content-type:mime-version:user-agent:references :in-reply-to:subject:subject:from:from:message-id:date:date :received:received; s=dkim-irif; t=1709120455; x=1709984456; bh= OjvTXonjkK9kvusOI2L3eBML8IgR8GzPVFu6xoGwHck=; b=WWsbCGaP/dZR+iTz kWFtilMYNZjYGmyYwHKQYSc/X1JpX4/pwXZb0cEKaFGCtpiD/8VDO7sC/C/1/Xx3 QuhZXeO6AHv+YoBME9qt1HYtjCR+e1N4dsnwnGeUmncxqbtV0mn4o5OINzPtCVVQ E0U73vyjhdMH7/NXjd89UGZ3KmwQPkrgqepKattL+nEyuiFN87Nn/Pq+Zckwof+Y +N/6RqM0P6H7A9+akVLxJ+kBHNNwRnV6uTXK8MW8XYNQE8GGl8Tf6YRmYVUdm7C3 G4OqzIH2RVFCrRxURldExHFIbUAomPoXDIiqKJUe8dWjH50YIMb2XoCgxGJ+Ca0y B8Gneg== X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ZZiLtM3BLUK8; Wed, 28 Feb 2024 12:40:55 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0AF92A466B; Wed, 28 Feb 2024 12:40:54 +0100 (CET) Date: Wed, 28 Feb 2024 12:40:54 +0100 Message-ID: <874jdsizp5.wl-jch@irif.fr> From: Juliusz Chroboczek To: Rich Brown Cc: bloat@lists.bufferbloat.net In-Reply-To: <30F7E4EF-906B-41CD-9EDE-179106E8BFCF@gmail.com> References: <30F7E4EF-906B-41CD-9EDE-179106E8BFCF@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 28 Feb 2024 12:40:57 +0100 (CET) X-Miltered: at korolev with ID 65DF1BC9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 65DF1BC9.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 65DF1BC9.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: Re: [Bloat] mDNS X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2024 11:41:00 -0000 > But my point is that the OpenWrt router has no way to predict what > address/subnet will be assigned to its WAN port. In principle, the ISP should assign either a global address, or an address in the range 100.64.0.0/10 (RFC 6598). This range was deliberately chosen to not collide with RFC 1918 space, so that the NAT box can choose any RFC 1918 prefix on its downstream interfaces. In practice, however, ISPs don't necessarily obey the RFCs, and people do chain NAT boxes, so none of the above is guaranteed. > Consequently, at boot-time, OpenWrt should simply choose some different > subnet for its LAN subnet(s), and then advertise an mDNS name. I'm not sure how that could happen at boot time, it would need to happen whenever a DHCPv4 lease changes. This implies that the router might need to renumber if the ISP changes its allocation, and there are no renumbering procedures for IPv4 (I'm not sure if anyone implements RFC 3203). It would also make addressing non-deterministic, which would make debugging slightly more difficult. But then, we already have non-deterministic addressing in IPv6, so I guess that's something we can live with. -- Juliusz