[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.