Re: I-D Action: draft-bourbaki-6man-classless-ipv6-06.txt

Lorenzo Colitti <lorenzo@google.com> Tue, 19 April 2022 00:39 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04803A1960 for <ipv6@ietfa.amsl.com>; Mon, 18 Apr 2022 17:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.609
X-Spam-Level:
X-Spam-Status: No, score=-17.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UK0YuXmWSrAC for <ipv6@ietfa.amsl.com>; Mon, 18 Apr 2022 17:39:39 -0700 (PDT)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 8CD093A195E for <ipv6@ietf.org>; Mon, 18 Apr 2022 17:39:39 -0700 (PDT)
Received: by mail-vk1-xa2a.google.com with SMTP id r8so4084032vkq.4 for <ipv6@ietf.org>; Mon, 18 Apr 2022 17:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+hgWK7Je6f4UPHKC0uo8HZwY/P3BY2WXfW9V0JXfGO8=; b=i//LV0CAPM915FasOJDrEHLT9IWcctXyqwdtAcLzEfvVjJblZDY+caFQUtHYWcrSDT gk7snSyksK2jff6ehDAQSIqfj9rFHgmXQYtPuLhKEX+IghXZITzoapixL4CFvyVAOhqa FEZUdx3+WpFum0xiwcWOvUleplCAk3GQp+FQlxZ75xc4zcP9UlL9FtxagQdNN+Ej9EIQ r+09RivBTd+CAmu4FV435TmLhXSwxFLLpQPC4qnRdMFG574z0/ZfaLq1LkEJBvDfk3iQ GU1L93tbwscdvEQ+DRVaWhwLqKzBqVRlRxArCahFgWRtbKqQih7B5oWahScZvVPi6kju U+xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+hgWK7Je6f4UPHKC0uo8HZwY/P3BY2WXfW9V0JXfGO8=; b=kMNSQ+Oyr84i+bw4+xFvicZZR4ff6VPYuD8wimFqbvkyx2zkoy1x7NBZuTcIXio6xt kmKk4iwBdQQl9Jmwyht0E9vmJtRCRyFO3yWixxYokQnjxnVw26BD6417TqWpGlAceD0U d9TopjqdWQ7DIxgNe7MzsJdmy49osJ9PkiEFVHCcGhnNbT7+aZuQUbb7fx11NFWx35gx LMmCo9rcZMvhCIiKYl37NyS2umkdvpUZo1fNYwFQ0KdRpiXv+eCA75Se2LTGxeXvALzG FVpvCHUH1pUftzohvHeobSevhYdGgVfJQT8TYTagK1cFp9PFjdZPCUUV23Ltg3DKQW79 za1g==
X-Gm-Message-State: AOAM532uzZ1H16pqP66C54x0hFjJ4Dck5BftECb+vJ9C/djOEEuDd44i 3VWb1Jm/bDNa18pLlZ9Y4eR3kxYeUVAIx4FfiMreGZ+QXoPj5Hrx
X-Google-Smtp-Source: ABdhPJw5SZjXS1sGZb6XnMaRogiVnjiExxqb3Wy9cNQ0MF1FBolQClRKfCRRiyyANb6VsCs5RR+WkZ6VQjnYa9tZ8Sk=
X-Received: by 2002:a1f:2943:0:b0:349:19a8:e26f with SMTP id p64-20020a1f2943000000b0034919a8e26fmr3380240vkp.30.1650328777300; Mon, 18 Apr 2022 17:39:37 -0700 (PDT)
MIME-Version: 1.0
References: <165030713553.2600.8991173749687838810@ietfa.amsl.com> <178caafd-cb72-64aa-78e4-ba0cb7198c2d@gmail.com> <A4B7B1A1-159C-4E62-A2D2-C37454FA60C1@psg.com> <CAO42Z2x2E+a31VCcZWyN0XFtio4+KGdS_N34ZzMgrb3eogQaNA@mail.gmail.com> <1c5d5c0c-d348-59f6-42cb-126af86ac6b8@gmail.com>
In-Reply-To: <1c5d5c0c-d348-59f6-42cb-126af86ac6b8@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 19 Apr 2022 09:39:24 +0900
Message-ID: <CAKD1Yr2-RYMEiRgGdcO9BiO-RHy0Ps9Ts673fYsJuT5PJy95_Q@mail.gmail.com>
Subject: Re: I-D Action: draft-bourbaki-6man-classless-ipv6-06.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, Randy Bush <randy@psg.com>, 6man <ipv6@ietf.org>, bourbaki@bogus.com
Content-Type: multipart/alternative; boundary="000000000000891d3405dcf71c71"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gypANHn9jsgZvfvPRiDJhRF4Xjw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2022 00:39:42 -0000

On Tue, Apr 19, 2022 at 7:26 AM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> > "Lets make IPv6 easier for people learn and adopt by making its
> addressing as complex as IPv4's", said no one ever.
> >
> > IPv6's addressing should be as simple as will do the job.
>
> But it doesn't only have one job. draft-bourbaki- is about its job as a
> locator for routing purposes, and all it really says is what BCP198
> (RFC7608) already says: the routing prefix is any length up to 128 bits,
> and longest-match routing always applies.
>

That's not what it's about - at all.  Even the abstract makes it clear that
it's about addressing, not routing:

=====
   The last
   remnant of IPv6 classful addressing is a rigid network interface
   identifier boundary at /64.  This document removes the fixed position
   of that boundary for interface addressing.
=====

and later the draft it says it's *also* about routing:

=====
   This document also clarifies that IPv6 routing subnets may be of any
   length up to 128.
=====

I continue to object to this document on the grounds that it makes it
impossible to achieve feature parity with IPv4 without abandoning
end-to-end connectivity. In IPv4, any edge network participant can
endlessly extend the network by using NAT. IPv6 allows this too, but in a
different way: because the address assignment unit is fixed at /64, and /64
always has enough room for more addresses, any network participant can
extend the network by ensuring individual /128s are routed or bridged
within their network. If we remove the fixed boundary, then that is no
longer possible without sacrificing end-to-end connectivity which is a
major improvement that IPv6 can provide over IPv4. I'm sure many others
feel the same way, which is presumably why the draft did not progress the
last time.

If the authors really intend this document to be about routing only, they
should ensure the text states that plainly. I'm sure it would be less
controversial and more likely to gain consensus.