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