Re: the race to the bottom problem

Gyan Mishra <hayabusagsm@gmail.com> Fri, 06 November 2020 14:27 UTC

Return-Path: <hayabusagsm@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 0C7363A11D3; Fri, 6 Nov 2020 06:27:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 UM4uNJvczt8x; Fri, 6 Nov 2020 06:27:44 -0800 (PST)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 2130D3A11CE; Fri, 6 Nov 2020 06:27:43 -0800 (PST)
Received: by mail-vs1-xe2a.google.com with SMTP id y78so757160vsy.6; Fri, 06 Nov 2020 06:27:43 -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=uhG8TaAKsn5JJxchJpipCUJ7jXnNXhOrxMOK39VIWz0=; b=ga85vDKpNkHdi02M114D/vkv7CKBSDiw3Vy0wCXhoCdICMdNlGKiZKNdiJKZHZU6sg IfSt5lQSc+rvTwLbqEaNC1HcnQJCE5zptPS5Bn85EgRXtS0kAgduF6YrC/eX8TwF9ARt 9J4HBtMl3FjeHLq5sPd2GjcEZQTVRrZBcKlTJpbvP/tH69ZDwNBGr680gkjrF9Ukbfce P4ZnEj2eMxH/lCFMmR/ilPa+RVcpyVk5gf4neUuSbO16GIQe0CN1vufq/HR7d+SRRlIo ZvMPd3w+jCvdrutlunDbFluajBVYwFRzjKZqesmVOYabYvrWmNjEC/x+iE27+vdqEVlo y4MA==
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=uhG8TaAKsn5JJxchJpipCUJ7jXnNXhOrxMOK39VIWz0=; b=tNxhz2UXlBHqCASwA2qzof/C6OaJ25sbH7eE7IcEpERPwRk0I3/lT3JPtvNY2I7iAR Y35CoxkjiqKXiJB19hs66Dx3h+W9IzAYJ97SAtf4+5lVfym6fViXdCfFU+6lH80FMk1/ P5CNGffKsup8+Y4MQVp+la7G9or50CmM6hJlnW8GUXqDkNce2/ku39DiaRcfCMeBpWu/ gO8k1mtT67w1aCpv0qOIlto3KxGUT8vvID/bwdpvuV/f2tZM6msMGNfCHaogSau4G04f tDMsaTpNjXxrFK7fwVLa6bEmt2ecof6JxAkH2DBTBoxew6aC0lfcrd4oPa1nO9CXONCF obIw==
X-Gm-Message-State: AOAM531rUCmuNRBeJsRwWVO/n5zdq+kJ2A+Gns9JzLqBZde+hFBRBXIv /XTsVb1yYJRgGMepM9mDyTpZCGabxySDHDDy/CA=
X-Google-Smtp-Source: ABdhPJy3uSwVvyL75ibMNpaac+juyn4aKfMxi+TlaNGOvkI1qKLLoPNviaqxbNVxNy28Wqbq3Sfc+esaczpOWaTj0JM=
X-Received: by 2002:a67:e9c5:: with SMTP id q5mr1095856vso.5.1604672862973; Fri, 06 Nov 2020 06:27:42 -0800 (PST)
MIME-Version: 1.0
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.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>
In-Reply-To: <905bcc26-a223-53d0-6675-c35579b9a8be@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 06 Nov 2020 09:27:32 -0500
Message-ID: <CABNhwV3wG_VsFk2FRgXL=_6K9=RwAwAX=0dBNVr5PPReLhEySw@mail.gmail.com>
Subject: Re: the race to the bottom problem
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: 6man WG <ipv6@ietf.org>, Fernando Gont <fgont@si6networks.com>, draft-mishra-6man-variable-slaac@ietf.org, otroan@employees.org
Content-Type: multipart/alternative; boundary="000000000000fa72c205b37103c2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jSzp5b8sSwdkPi30fUqNz1TRiJ4>
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: Fri, 06 Nov 2020 14:27:46 -0000

On Fri, Nov 6, 2020 at 9:14 AM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 06/11/2020 à 11:36, Fernando Gont a écrit :
> > On 6/11/20 07:04, Alexandre Petrescu wrote:
> >> I have been reminded in private about 'race to the bottom'.
> >>
> >> In the Variable SLAAC solution draft we do touch on the problem:
> >>
> >>> The "race to the bottom problem" - is the problem where allowing
> >>>  prefixes longer than 64 to be used in SLAAC will lead to 65, 66
> >>> and so on, up to 127 and 128 allocations.  At that point the
> >>> bottom would be reached and thus impossible to extend the network
> >>> further.
> >>
> >> A solution is then proposed in section 8 titled "Greater than 64
> >> bit prefix usage by ISPs is strictly prohibited".
> >
> > Then we'd need an RFC for formally creating the Internet
> > police/militia. (possibly a very bad timing for an already bad
> > idea).
>
> So we need to attenuate that 'strictly prohibited' wording and improve a
> way forward.


     Along with updating the verbiage in the draft we can create a 3GPP
mobile handset address allocation draft that that recommends only /64
allocation.

A RIPE BCOP may help as well for mobile operators.
This is all a theoretical fear that operators will race to the bottom, but
until we remove the 64 bit boundary, we don’t know for sure either way.  My
thoughts are that large operators such as Verizon as I can influence the
stance Verizon takes on allocation guidelines, that they will not change
and will remain at /64.  Verizon as a major stakeholder can influence other
operators as well on the stance. The complexity of management vlsm is
allocation for operators is not worth the saving and what is the real
savings.  Most operators have massive IPv6 assignments they got decades ago
so they never have to go back to the well again for more.

>
>
> Alex
>
> >
> > Thanks,
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD