Re: the race to the bottom problem

Ca By <cb.list6@gmail.com> Sun, 08 November 2020 01:01 UTC

Return-Path: <cb.list6@gmail.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 89B813A0EBE for <ipv6@ietfa.amsl.com>; Sat, 7 Nov 2020 17:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 nz9EWTwWJb2z for <ipv6@ietfa.amsl.com>; Sat, 7 Nov 2020 17:01:06 -0800 (PST)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 48A1C3A0E62 for <ipv6@ietf.org>; Sat, 7 Nov 2020 17:01:06 -0800 (PST)
Received: by mail-il1-x132.google.com with SMTP id g15so5022060ilc.9 for <ipv6@ietf.org>; Sat, 07 Nov 2020 17:01:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=10lfbkAhsy6RsP0mVbbpWADYt3XO8OFAZ9bOYk36bg0=; b=DwqtAKxl3WlD4RQbtjTmADWMK8fP6SWYr2VDWI/HaoeezQtX1zbDpx70sdKoo6Pclv 2ZPuNy++u5nYnFyBfUf/MdPYho/XRAp8tAefIs71BVjrMHcQNe83PGriIhS9VDJTwhpA u1IHlR529zwTw2BK4tR/AQ6u7VgMT66j34bZiDdSLCE5dkRnJtc+vP7dsmym6TywmXir ZbiiEchOJHw7M88Ozr+bDwlef82upI0zZKf5zxE6l7cqCkomryO95JzRaihCgyxUimGY //LGJTf/S1pXyhlbXZZid16IAbEUqtNeCP8k1JP6AjXIKCu96pTL3aMN1uiGkuc5tujB ZT/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=10lfbkAhsy6RsP0mVbbpWADYt3XO8OFAZ9bOYk36bg0=; b=SvhlaJrmeydZeQZ/Tq45A2mXb2kSdE+cJfolqJMvDMsAxPCCLbSuMn3xuHsU3pCZPq qgvcOvZXJuoXP29W39Lw+QDSNC930wdU5FU/Ia4bLYlO2RL4eIheTDIJsvXl7BR+pf7Q E3Y/oiJ5mXBArjEUB26k7yzPevG+T+l3HltdR9E44BMiUyH6WJrebPwpDYWROXuVWU4Q 5cde2fpx6D/qJIYSx05iIYh+sZXWG0BMQWprHGCqqDFSdvEpnzrUnl32iS9W/Jp90rWN JTzIuKoCNJ/bFUqW2Aq3CoWSztDFAHGTOXmGl8MrIZI6FNfQKvzgPbVHj+YKyVWUWb6m pjcA==
X-Gm-Message-State: AOAM531RBXb8XUuL4QM8cRkivznCMXTXUrfccUbIAkXyw5WYGC7b++LJ U4HD5pJx9x30WVu7hJoA52KI7bIrHl4X+AkSc5ATk+kA
X-Google-Smtp-Source: ABdhPJyjOxqrp9TCRC3twCR9PdrxEOpgtdu+G7PUPxpG2TEFoeo3IYNYJrxprywfWj3gPnwEFMIKegc3NwQH/Jr7cqg=
X-Received: by 2002:a05:6e02:e4f:: with SMTP id l15mr5408433ilk.190.1604797265293; Sat, 07 Nov 2020 17:01:05 -0800 (PST)
MIME-Version: 1.0
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <CABNhwV3L7kz=cWu8s3X=djVf4MCwewzbEgx09TWaKzCULCjYUQ@mail.gmail.com> <9A9CE8E7-3552-4FD8-A50E-1BDCA2CB813F@employees.org> <CABNhwV0LxM7EuKo2wNtVacjewsVqdhrmSiVBmB_EL-mqJYdU3A@mail.gmail.com> <CD9F9F09-2CBC-4A72-99C0-4A9A470357ED@employees.org> <9e787ed0-a221-e413-e030-ac2553dffc8e@gmail.com> <a21c9447-730b-e2c0-81f6-46deda57f507@gmail.com> <f4635fa9-45ca-f7ec-40a2-41764e1ca74f@si6networks.com> <905bcc26-a223-53d0-6675-c35579b9a8be@gmail.com> <AAE75F7F-F8DF-4B7F-9C50-3D6C91544997@ciena.com> <2b59b2de-3597-8d35-374d-75e9b10d4d83@gmail.com> <CAO42Z2zUvDE2ZSCnZa_525Hj7OthhEoDGZcd0D9xxZVW3D8aeg@mail.gmail.com> <CAKD1Yr1yiXR43mL45KbsZkKY7_YVhWFzW82LL6qed6mVPBjxaw@mail.gmail.com> <E87C175C-C06D-485E-B790-6BC3DB48F101@gmail.com> <3daa3475-68f8-88e0-9fc4-77a58c074fbf@foobar.org> <CAO42Z2zictx_PykbVUqfvODhQwztw47apAnOPjkncRSdqJBLPQ@mail.gmail.com> <e197fdca-2dc6-340b-bd4f-03b89ecc15e9@foobar.org> <b7c7f31c-825d-2a8e-4857-3526639649c4@joelhalpern.com>
In-Reply-To: <b7c7f31c-825d-2a8e-4857-3526639649c4@joelhalpern.com>
From: Ca By <cb.list6@gmail.com>
Date: Sat, 07 Nov 2020 17:00:54 -0800
Message-ID: <CAD6AjGTwPMbW1=SBCsSj15CA5BJY30JFsJoTpAgFYqDJrbUwYA@mail.gmail.com>
Subject: Re: the race to the bottom problem
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: IPv6 List <ipv6@ietf.org>, Nick Hilliard <nick@foobar.org>
Content-Type: multipart/alternative; boundary="000000000000ef385e05b38dfae6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fAbIahiKd9ZAZiYb7k_W8fsrRkE>
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: Sun, 08 Nov 2020 01:01:12 -0000

On Sat, Nov 7, 2020 at 4:00 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> I am not sure what data you are looking for Nick.
> By definition, no one complying with the RFCs is giving out prefixes
> longer than /64.
> By observation, folks are giving out /64s, when we would prefer they
> gave out /56 or even shorter.
> Given that there are policy statements from various groups about giving
> out shorter, adn those are being ignored, something is causing that.
> There may be multiple causes.
>
> History does tell us that ISPs give out very long prefixes even when
> they do not need to.
>
> Since there appears to be know way to observe a trend past /64, we have
> to look to history and analogy for data.  History is data.  We can argue
> about whether it is relevant data.  But it is all the data we have on
> the topic.


History tells us that ipv4 was scarce so people conserved addresses.

Operators have unlearend that lesson but the ietf has not. And so, ietf
people think operators are trying conserve addresses, this is not true.
Stop saying it. Stop saying “race to the bottom”, it does not mean
anything.

The current and future issue is that the mechanics of providing n number of
/64 is broken, dhcp pd is not being deployed in
Mobile. Accept reality. Mobile devices dont support it. Mobile networks
dont deploy it.

So, the problem statement in mobile is - how do we better make use of the
/64 that is provided or get more /64s in an effective way

No, yelling at operators and making punitive standards will not help.


>
> Yours,
> Joel
>
> On 11/7/2020 6:56 PM, Nick Hilliard wrote:
> > Mark Smith wrote on 07/11/2020 23:41:
> >> They're not assumptions if you have first hand experience of the
> >> history of the rise of IPv4 address conservation measures, and can
> >> remember what IPv4 addressing practices and mindsets were before IPv4
> >> addresses became precious.
> >
> > btdt, thanks.
> >
> >> The address conservation mindset is even more distinct and
> >> distinguishable when you've actually taught it through teaching IPv4
> >> VLSM in the mid 90s.
> >
> > this looks very much like an appeal to authority.  We're better than
> this.
> >
> > So once again, let's try to keep the topic about actual data concerning
> > ipv6 and this "race to the bottom" as it relates to ipv6.
> >
> > Nick
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>