Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

Seth David Schoen <schoen@loyalty.org> Tue, 03 August 2021 00:14 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 7E6963A2268 for <int-area@ietfa.amsl.com>; Mon, 2 Aug 2021 17:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 gmVxp9s0ug4C for <int-area@ietfa.amsl.com>; Mon, 2 Aug 2021 17:14:44 -0700 (PDT)
Received: from frotz.zork.net (frotz.zork.net [69.164.197.204]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96AA3A2264 for <int-area@ietf.org>; Mon, 2 Aug 2021 17:14:44 -0700 (PDT)
Received: by frotz.zork.net (Postfix, from userid 1008) id 39A591198A; Tue, 3 Aug 2021 00:14:44 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 frotz.zork.net 39A591198A
Date: Mon, 02 Aug 2021 17:14:44 -0700
From: Seth David Schoen <schoen@loyalty.org>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: int-area@ietf.org
Message-ID: <20210803001444.GW550425@frotz.zork.net>
References: <20210802055916.GL550425@frotz.zork.net> <4C839DB1-AD99-4DF0-A7C6-D6F99B4BC335@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4C839DB1-AD99-4DF0-A7C6-D6F99B4BC335@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/UsJ0iPqN-U7s4XDQBsoAH3MmZmg>
Subject: Re: [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: Tue, 03 Aug 2021 00:14:47 -0000

Bob Hinden writes:

> Seth,
> 
> Do I understand correctly, that you are proposing that all hosts, routers, firewalls, middle boxes, etc. on the Internet, be updated in order to get a single extra IP address per subnet?  Plus then having to deal with the complexities of mixed implementations for a very long transition period.
> 
> To me this fails the cost benefit analysis.

Hi Bob, thanks for your reply.

Yes, we're proposing a change that affects all hosts and routers in
order to get an extra address per subnet.  As I described in my reply
to Derek Fawcus, this change -- unlike some of the other changes we
will propose :-) -- has a particularly nice incremental-deployment story
due to RFC 4632 and the largely correct existing behavior around it.

This is to say that, if you patch your own devices and then deliberately
number a host with the lowest address, the rest of the world can already
talk to that host under existing standards.  (Patching your devices has
little cost in functionality to you; you lose only a disused obsolete
form of directed broadcast.)

In this case, if you don't patch your devices, you can also already
talk to anyone else who does; there's no way for you to know!

Thus, the biggest benefit of officially standardizing this is to
encourage vendors to start changing this behavior now, so that it will
be correspondingly more likely that people who care will have
fully-patched or sufficiently-patched network segments in the future.
With this change, people who don't care or don't know the compatibility
details of devices on their local networks can just continue not to
assign the lowest address at all.  (Conveniently, the networks where a
single extra IPv4 address is most valuable are also generally the same
networks where it's easiest for the network administrator to know and
predict what software is running on the network segment.)

While our other proposals don't have these same properties, they also
imply much larger numbers of IP addresses becoming available, which
might change the cost-benefit comparison.