From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EB3F93B29E for ; Mon, 17 May 2021 20:16:14 -0400 (EDT) Received: by mail-io1-xd29.google.com with SMTP id n40so7658201ioz.4 for ; Mon, 17 May 2021 17:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=pYmpcuJB3O2WbEZ4bH5JHp9y4Uuy5jtLmfskJsNz/l0=; b=ooOJYgswc2I9YZxrg8ayMM/oygVOQ+AlrNHhiztVedIo45ODQZPUkbRmSmsD/+WP/l hAX07xOGivfh0/FIrliLEl3g5vMuLJ+aL81XsOaz86z8unI5kP/+v67WQSALSL6Spp7p Lm0Wu9MP6Q1pKUZAVXv8zkgl+5fJ0W6OCQgS/ZB9ME7xGXoCQZr0IC8NYR1H8NJfcsYY yvsyv/oxdbrmTs0DRI41kpuYQXMVOaI2f4LJsHyW369ZjVZlUx1en9GVLJkO93h9PLDg GfgVH6kW5yoJmA4yNSqOroDg6nUkv1RkEjpeUlOUka271BteeFccAzE4L6UVMh9xYQy9 4W7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=pYmpcuJB3O2WbEZ4bH5JHp9y4Uuy5jtLmfskJsNz/l0=; b=WXuDCg6kmONhDaq4k5nBtiJTbfie4zEyttOZw9WAGHpuF9wNHxUzxfE8MtigTkSE9P berIxosGLEmoB+ih9hKFNOFZZh4EvDuQSDnjzomUMNOcm/fXrw0qzrb5hNCTaNU1+wRS WxMfd4vsHY48jEeQohx4GK6s5MKc9F9EACnqSUgrdwEYqufokLBpYUovufo4zQQ39n0w B7PYR0+RCjfHBm/CfSTJftYmS268FhXvmC2tc3/z0+yYru6Q7iW7beoj+6tyCmshLFuQ ybVcVi+0ISWkfhdyr5XV2Of+t7Lw+x+yTqPP770ESBoVN4/MnuW0JA0YpWkS5oz6kR9B mO+w== X-Gm-Message-State: AOAM532eOAxw8Txv/B6+5JotpzObEGWQXVv9n19gPmfqSqYZZAIZiy2u ZgJHOu15r3dZST/9Zz0QaRnjoLIZtKdZlKkRKfGbdTQnm2k= X-Google-Smtp-Source: ABdhPJzgIN4/S8h3pgZEZ4HLkgQ4X9m7FOdxSZ4Q2eIXdz3Z6mxR5wcCDPQ+1ngyl0+RkGNzPYhrw7TrbfB3v6/Ws3I= X-Received: by 2002:a6b:6615:: with SMTP id a21mr2091037ioc.161.1621296974014; Mon, 17 May 2021 17:16:14 -0700 (PDT) MIME-Version: 1.0 References: <20210513043625.GL1047389@frotz.zork.net> In-Reply-To: <20210513043625.GL1047389@frotz.zork.net> From: Dave Taht Date: Mon, 17 May 2021 17:16:03 -0700 Message-ID: To: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Starlink] Fwd: [RESEND PATCH net-next 0/2] Treat IPv4 lowest address as ordinary unicast address X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 00:16:15 -0000 Over the past few years, I have been involved in trying to extend ipv4 a little bit longer, first making work in openwrt and linux the formerly reserved 240/4 address space. (260m addresses), then 0.0.0.0/8 (16m). I can think of no better place to deploy this new address space than in a large cgnat that might want its subscribers, at least, get to *each other* over the starlink network from isolated area to isolated area, and maybe, one day, with sufficient incentive, made globally routable. The arguments I made for making more ipv4 addresses were filmed here: https://www.youtube.com/watch?v=3D92aNK3ftz6M I got *brutally* tired of the RIR politics involved in trying to make these spaces allocatable (I don't know current prices (?), but at the time it was $20 per ip address), and wading through the ietf processes to get anywhere, and dropped out. The project just got the 0th' address of any given network usable and upstream in the net-next kernel. This is a huge win for very small netmasks, and finally retires the last vestige of BSD 4.2 from the internet. ---------- Forwarded message --------- From: Seth David Schoen Date: Wed, May 12, 2021 at 9:36 PM Subject: [RESEND PATCH net-next 0/2] Treat IPv4 lowest address as ordinary unicast address To: Cc: John Gilmore , Dave Taht , David S. Miller , Hideaki YOSHIFUJI , David Ahern Treat the lowest address in a subnet (the address within the subnet which contains all 0 bits) as an ordinary unicast address instead of as a potential second broadcast address. For example, in subnet 192.168.17.24/29, which contains 8 addresses, make address 192.168.17.24 usable as a normal unicast address (while continuing to support 192.168.17.31 as a broadcast address). Since EVERY network number or subnet formerly had its host number 0 reserved, this patchset adds 1 more usable host address to every network and subnet (i.e., 2^(32-n)-1 instead of 2^(32-n)-2 addresses available for assignment on each IPv4 /n subnet). For small subnets, this is a significant gain; instead of 6 usable host addresses, a /29 would now contain 7, a 16% increase. The reserving of host number 0 for broadcast came about in RFC 1122 from 1989 (page 31, "IP addresses are not permitted to have the value 0 or -1 for any of the , , or fields (except in the special cases listed above)" and page 66, "There is a class of hosts [4.2BSD Unix and its derivatives, but not 4.3BSD] that use non-standard broadcast address forms, substituting 0 for -1. All hosts SHOULD recognize and accept any of these non-standard broadcast addresses as the destination address of an incoming datagram."). This has been repeated in subsequent RFCs, always with backwards-compatibility rationales. Network troubles (broadcast storms) ensued when some early hosts on a LAN treated the lowest address as unicast and others treated it as broadcast. Multiple 1989 changes to IP successfully prevented these. The key was adding the layering violation rule requiring hosts to ignore all IP datagrams with unicast destination addresses that were received in low-level (Ethernet) broadcasts. That change is still in effect, and this patchset does not alter it. All operating systems since 4.3BSD, including all the current BSD OSes, now use the standard IP broadcast address. 4.2BSD has been obsolete for more than 30 years, and all modern hosts ignore hardware broadcasts containing unicast IP addresses, so there is no modern likelihood of broadcast storms even when hosts disagree on the unicast vs. broadcast status of a given address. Tests with this patchset show that other Linux hosts on the local segment simply ignore a host numbered with the lowest address, both for incoming and outgoing packet purposes. They don't interoperate with it, but they also don't cause broadcast storms or any other malfunction. If patched, they have no trouble interoperating with a host at the lowest address. Unmodified "distant" hosts that are not on the same segment successfully interoperate, as long as the gateway on the local segment, and the local host itself using the lowest address, have this patch. (Distant hosts have no way of knowing whether a given address is the lowest address in a faraway network segment, so they treat it no differently than any other unicast address.) This means that each local site can change this behavior locally, resulting immediately in global interoperability with the newly usable lowest local address. Modern software and documentation continues to use the definition of the directed, or "net-directed", broadcast address as "a host ID of all one bits". The Internet no longer gets any benefit from having two different broadcast addresses usable on every Ethernet segment. I have not been able to find any documentation that suggests that users or software should ever intentionally use the all-zero form, or that justifies it other than as a historic Berkeleyism. RFCs 1112, 1812, and 3021 state that hosts and routers need to maintain compatibility with the old form -- but they give no rationale other than the past existence of the 4.2BSD behavior. We're happy to provide more historical details or information about behavior of other systems in this regard by e-mail or as future patches to kernel documentation files. Seth David Schoen (2): ip: Treat IPv4 segment's lowest address as unicast selftests: Lowest IPv4 address in a subnet is valid net/ipv4/fib_frontend.c | 4 +--- .../testing/selftests/net/unicast_extensions.sh | 17 +++++++++-------- 2 files changed, 10 insertions(+), 11 deletions(-) -- 2.25.1 --=20 Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave T=C3=A4ht CTO, TekLibre, LLC