Re: the race to the bottom problem

Ca By <cb.list6@gmail.com> Sun, 08 November 2020 02:26 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 110A13A0EAD for <ipv6@ietfa.amsl.com>; Sat, 7 Nov 2020 18:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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] 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 yS62hseMLBqx for <ipv6@ietfa.amsl.com>; Sat, 7 Nov 2020 18:26:12 -0800 (PST)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 D4BD53A0EA9 for <ipv6@ietf.org>; Sat, 7 Nov 2020 18:26:11 -0800 (PST)
Received: by mail-io1-xd35.google.com with SMTP id o11so6264799ioo.11 for <ipv6@ietf.org>; Sat, 07 Nov 2020 18:26:11 -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=KrkTZeg7cNG4xIKmpJ09+/PS7oitAldKMOS/aIIR7iw=; b=gwRd7FHEj3UQ9rPesnIEjWzI9+8MJO7mHc7FSGhim9L2oB2UqlvHdNK+TkRbuaEbHL tqJnzMl0XIZFvy5ijAGFvyV/RMUIRnAAmpsIbZ/Rgvio6FK/lF/XUyZJE+1lVhOCLIUx 1RRRjSRyktDuoJLF5+nywB7Fm/obLfx+c/9IKC23TCd2joWqrZjGaPGvL878VknEcT8P qtj78AEG+AdUR5FWjk2WUWFOL2bv6EHuEp43G/zmofW+VCg1VIb4o1TPk9Q0PP5bP1bm R9E/b3++RWuuuOehUzCXIFPFW4PoztT9eq8kdu0q/jAx1Y5pf7SotB5r8asuE+vbmBRT uMuA==
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=KrkTZeg7cNG4xIKmpJ09+/PS7oitAldKMOS/aIIR7iw=; b=kI6TVRAuSN3IfjMHAQl4tNVmibJIOn5u0dBmM6l+PSGLQ5Foya6Eu4VMJOXWcgVXDy su8906gwAKlj0fPJUkiShFfJ5r7Edr0Az+nVXXoKYnrYyuVrFHE6EwwytUAH0QrT3aV6 HfO2BWxl/CcmwkflWCiFcMmPEJFaMXGUK6qs6z66+E1pQDOt1DzKQKJaPbALwLgqP+En 0bHFj6RB+XHI3SsmK8yxi1eoa931D264IS09bTtyTUUI8GED8g3yDNSl5kECmzCeolPA /Re9xHwfM7lPN5vi1IYArfoXdxNKKETdzUdvEAdzZ0oEPNiIW/bBl/GL3u1hUHlGsGAp wOGg==
X-Gm-Message-State: AOAM531aSzHrq9AfNxGnS88pcec1NXshNfeeA/v78U+JyTidltMok89R FZeyT0t+v1c/bFONYGfiCSJgMdOqmcfp3epvjCE=
X-Google-Smtp-Source: ABdhPJxY5kCPCpUaGp4M7edl+iv8qCw75b8aWdthmAoINeF4KIG7AkTb9//63jTJftOg7x0Ou9rJjJHsb6vB6gK73+Y=
X-Received: by 2002:a02:c547:: with SMTP id g7mr6567190jaj.88.1604802370979; Sat, 07 Nov 2020 18:26:10 -0800 (PST)
MIME-Version: 1.0
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <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> <CAD6AjGTwPMbW1=SBCsSj15CA5BJY30JFsJoTpAgFYqDJrbUwYA@mail.gmail.com> <8ef560cf-e256-7590-6090-5291f0256d26@gmail.com>
In-Reply-To: <8ef560cf-e256-7590-6090-5291f0256d26@gmail.com>
From: Ca By <cb.list6@gmail.com>
Date: Sat, 07 Nov 2020 18:26:00 -0800
Message-ID: <CAD6AjGSAYDq+3fs7E7LdxETOgXnnrUOrq_Z3GCBJgDyvisQgbg@mail.gmail.com>
Subject: Re: the race to the bottom problem
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: IPv6 List <ipv6@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="00000000000041cc1705b38f2b7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OL_1YNXKfs1XMZlWDeHI1mWYUa8>
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 02:26:13 -0000

On Sat, Nov 7, 2020 at 5:38 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 08-Nov-20 14:00, Ca By wrote:
> ...
> > History tells us that ipv4 was scarce so people conserved addresses.
> >
> > Operators have unlearend that lesson but the ietf has not.
>
> If that is true, why on Earth does 3GPP still ration each PDP context to
> one /64? That is for sure not the IETF's fault. We've told them and told
> them.
>
> It is not the case that the IETF hasn't learned the lesson. In fact, the
> lack of scarcity is exactly why "wasting" 64 bits on Interface IDs and
> handing out /48 or /56 to end users are the IETF recommendations. The
> pressure against those recommendations is *exactly* the race to the bottom.
>
> (In answer to Nick: the data for the race to the bottom don't come from
> IPv6. We're talking about IPv4, between about 1993 and today.)
>
> But Cameron, please tell us in detail why PD is problematic for some
> operators. That seems to be the sticking point here.
>

Honestly, i believe the issue is that dhcp-pd does not exist in 3gpp
deployments and there is no way to will it into place.  /64s are assigned
from the gateway using a local pool assigned the the gateway. Very simple,
no radius, no dhcp, no binding pd routing to assignments

So, just like with 64share, we need to work with what we have.

1. We have slaac, can slacc gives us more addresses ?

2.  Each attachment to 3gpp provides a /64, is there a real problem today
with scaling up attachments to get more /64 addresses on demand?  Probably
fine for 2 or 3 more /64 in the common home scenarios.

3.  Can we adapt 64share to slice up the existing /64 ?

4.  Other? Not dhcp-pd.

5.  Ndproxy ?

The problem that i have today, is that $dayjob has a very quick growing
4G/5G home broadband business.  Today, we use 64share to get ipv6 on to the
LAN. Works great. But, a lot of people are using “google wifi” mesh which
adds ... a 3rd layer of nat44 and kills ipv6 getting to the actual user
LAN. But, google wifi does support dhcpv6-pd. Might be nice if it supported
ndproxy





>    Brian
>