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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 13 August 2021 21:27 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 1EBF23A26FA for <int-area@ietfa.amsl.com>; Fri, 13 Aug 2021 14:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9rdP_bbCHtZf for <int-area@ietfa.amsl.com>; Fri, 13 Aug 2021 14:26:54 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C933A26F9 for <int-area@ietf.org>; Fri, 13 Aug 2021 14:26:54 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id b7so13689698plh.7 for <int-area@ietf.org>; Fri, 13 Aug 2021 14:26:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Lw5Rx73l+c/rduIbRKRY/hfVuzsButy+bTsqAiRqHjY=; b=YD9X0zpSbe1OkJaozAejJSn145ojKrIk9cAF5lPoFYKcwwHyKKBqEuDie8bMZXZEhu koqL3QrP5m1q2/2e2hC8/Duh0BRHsbS2FOpc0WXUEJzue7cqjiPBwOne4fw1qmUM9mK8 gi22k28zgXkLIkwPOcmjU1nYWAlflrlNSjA9K/14AT3YgzGiWcyGSWB21dbF19Eq5630 js7V6sJc9QRlCo8MfuXj0B0OQsW05WMlntteAguXt3VcwKGwa4FZ2N5aeOHDBuUX34W+ SQ0dHpMp7guKfh71Ji35uMAYyRE4JrUypqF13ipYCPILQ2/KlNO28ar6YGxuP83QZcJZ zSZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Lw5Rx73l+c/rduIbRKRY/hfVuzsButy+bTsqAiRqHjY=; b=R72nyPNCgv/lzkMDyHtjv/hDSIr39fGBRI5arSPie742tHjlT9GVX69hW05Bm+jQfT 2spmaMZCB7B8mwI1PY6wg+FMqydYFrG6gHJzQrlaiawRw/sstJzziEdgPVeYuENbzEAh OdSDuXRzHw7XyG4DOTrmKkSOg43jsi18urvbxZqiOwfLyqJiWROXMq2PDKoUjfeuNckI pQWdMgMVFmUWe6KPpFVlFpAwOYbOS80BwROHYz3rukA1VFZBHyNbLBd1w6N+q8YdAGlh 3pQXP23DPjKnHretEEe1VDMJNLFWnPw47DRfuO+38yuNdRSb+7fK7GtlroV3mF2qEg/N 9IJw==
X-Gm-Message-State: AOAM533hNb2sG3Qhmo413gnvY2hD0H7bz3BdY5dvrfU+cb8FO2WDfE1j /MuGthfgpU2NSIsxjCImvRJpL6YCAhxUiw==
X-Google-Smtp-Source: ABdhPJxVgqsCHDRKX4ZmQAAUyDNXmCuDTc3L2PTsMsOR+v4oNVT7re7vj+1R27gizltS+nyqdJfY4g==
X-Received: by 2002:a17:90a:458c:: with SMTP id v12mr4575857pjg.50.1628890012993; Fri, 13 Aug 2021 14:26:52 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id u24sm3478169pfm.81.2021.08.13.14.26.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 14:26:52 -0700 (PDT)
To: Seth David Schoen <schoen@loyalty.org>, Carsten Bormann <cabo@tzi.org>
Cc: int-area@ietf.org, John Gilmore <gnu@toad.com>
References: <20210813184903.GX550425@frotz.zork.net>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <b508c068-eea3-76ed-06f2-47db0c18ebea@gmail.com>
Date: Sat, 14 Aug 2021 09:26:48 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <20210813184903.GX550425@frotz.zork.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/xVvv10AtBNZN1H5DnR7DU1mFjX4>
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: Fri, 13 Aug 2021 21:27:00 -0000

On 14-Aug-21 06:49, Seth David Schoen wrote:
> Carsten Bormann <cabo@tzi.org> wrote:
...
>> a cost that is better invested in accelerating the migration to IPv6.
> 
> IETF could deny the community a forum in which to form a consensus
> about how IPv4 can usefully evolve.  

"The IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. Future IETF protocol work will then optimize for and depend on IPv6." [https://www.iab.org/2016/11/07/iab-statement-on-ipv6/] So any IETF effort
on "evolving" IPv4 is really not on the radar. Patching it up operationally is
in scope, of course. That's what you seem to be proposing.

> But it can't force everyone to
> spend an equivalent amount of energy on doing one particular other
> thing, like "accelerating the migration to IPv6".  As we discussed in
> our message responding to Brian Carpenter and Andrew Sullivan, that is a
> false dilemma. 

Not really; the total effort available to get documents through the IETF
process is a finite resource. (Not the effort to create -00 drafts, which
appears to be an infinite resource, but the process that follows, which is
already far too slow because the pipeline is full. Actual the Suez Canal
is a better analogy, because each step in the process works like a basin
and a lock, with finite throughput.)

> Neglecting or abandoning IPv4 isn't an IPv6 transition
> strategy.

As I've been saying for 15+ years, we don't have a transistion strategy,
we have a co-existence strategy. That's indeed orthogonal to a marginal
extra supply of IPv4 addresses.

     Brian