[Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Seth David Schoen <schoen@loyalty.org> Mon, 02 August 2021 05:59 UTC
Return-Path: <schoen@frotz.zork.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D00D3A0B4B for <int-area@ietfa.amsl.com>; Sun, 1 Aug 2021 22:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DEz2i4Xvbb7 for <int-area@ietfa.amsl.com>; Sun, 1 Aug 2021 22:59:17 -0700 (PDT)
Received: from frotz.zork.net (frotz.zork.net [IPv6:2600:3c00:e000:35f::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528853A0B40 for <int-area@ietf.org>; Sun, 1 Aug 2021 22:59:17 -0700 (PDT)
Received: by frotz.zork.net (Postfix, from userid 1008) id 2F9DA11992; Mon, 2 Aug 2021 05:59:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 frotz.zork.net 2F9DA11992
Date: Sun, 01 Aug 2021 22:59:16 -0700
From: Seth David Schoen <schoen@loyalty.org>
To: int-area@ietf.org
Message-ID: <20210802055916.GL550425@frotz.zork.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/c23abARrA8701dDbD2aBUiFFvrY>
Subject: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2021 05:59:20 -0000
Hi, John Gilmore, Dave Taht and I have proposed a recent Internet-Draft that relates to the Internet Area. We hope you'll read it and discuss it: https://datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/ With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to increase the number of unicast addresses in each existing subnet, by redefining the use of the lowest-numbered (zeroth) host address in each IPv4 subnet as an ordinary unicast host identifier, instead of as a duplicate segment- directed broadcast address. Our IPv4 Unicast Extensions team is working on several related proposals for improving address space utilization, of which this is the first. We are also editing I-Ds for each of the other proposals and will upload them to the datatracker when they're ready. Each proposal changes the status of some particular unused IPv4 addresses in order to make more address space available, and each has involved experimentation with real-world operating systems to explore the ease with which the proposed change can be made and learn about its consequences. These proposals would, if adopted and deployed, produce another tens to hundreds of millions of IPv4 addresses usable for unicast traffic. This can be accomplished by making quite small, easy to make, easy to test, incremental changes in popular TCP/IP implementations. (The Lowest Address patch for Linux is less than 10 lines long, and the BSD patch is similar. They interoperate with each other and are already addressable by unpatched implementations when distant from the local subnet.) As we will describe in more detail in future posts, we expect these changes will create enormous economic value, and they are not intended as an attack on the IPv6 transition.
- [Int-area] Introducing IPv4 Unicast Extensions wi… Seth David Schoen
- Re: [Int-area] Introducing IPv4 Unicast Extension… Derek Fawcus
- Re: [Int-area] Introducing IPv4 Unicast Extension… Bob Hinden
- Re: [Int-area] Introducing IPv4 Unicast Extension… Brian E Carpenter
- Re: [Int-area] Introducing IPv4 Unicast Extension… Seth David Schoen
- Re: [Int-area] Introducing IPv4 Unicast Extension… Seth David Schoen
- Re: [Int-area] Introducing IPv4 Unicast Extension… John Gilmore
- Re: [Int-area] Introducing IPv4 Unicast Extension… Derek Fawcus
- Re: [Int-area] Introducing IPv4 Unicast Extension… Carsten Bormann
- Re: [Int-area] Introducing IPv4 Unicast Extension… Ted Lemon
- Re: [Int-area] Introducing IPv4 Unicast Extension… Bob Hinden
- Re: [Int-area] Introducing IPv4 Unicast Extension… Andrew Sullivan
- Re: [Int-area] Introducing IPv4 Unicast Extension… Eliot Lear
- Re: [Int-area] Introducing IPv4 Unicast Extension… Brian E Carpenter
- Re: [Int-area] Introducing IPv4 Unicast Extension… John Gilmore
- Re: [Int-area] Introducing IPv4 Unicast Extension… Seth David Schoen
- Re: [Int-area] Introducing IPv4 Unicast Extension… Brian E Carpenter