IETF Logo Mail Archive

Re: [**EXTERNAL**] Re: the race to the bottom problem

Nick Hilliard <nick@foobar.org> Sun, 08 November 2020 21:45 UTC

Return-Path: <nick@foobar.org>
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 F166F3A0E61 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 13:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 juhG5xMVZT8r for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 13:45:20 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B753A0E5E for <ipv6@ietf.org>; Sun, 8 Nov 2020 13:45:19 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 0A8LjGf8010463 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2020 21:45:17 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Subject: Re: [**EXTERNAL**] Re: the race to the bottom problem
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 'IPv6 List' <ipv6@ietf.org>
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> <AAE75F7F-F8DF-4B7F-9C50-3D6C91544997@ciena.com> <2b59b2de-3597-8d35-374d-75e9b10d4d83@gmail.com> <21BC970D-8708-4090-A984-02E6E1305B94@gmail.com> <25099A60-8685-4226-8328-AA87376B62D2@ciena.com> <SN6PR02MB4512023A8418FA3BFA79F412C3EB0@SN6PR02MB4512.namprd02.prod.outlook.com> <8bc14b7a-9b4c-6f03-4e11-4fe02947fd31@gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <321718b8-41c4-8b85-6c0e-7d7cfeea6784@foobar.org>
Date: Sun, 08 Nov 2020 21:45:15 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.36
MIME-Version: 1.0
In-Reply-To: <8bc14b7a-9b4c-6f03-4e11-4fe02947fd31@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YEcLbVPN3xTVlZYmibt_ESQ3WJo>
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 21:45:22 -0000

Brian E Carpenter wrote on 08/11/2020 21:35:
> Just get 3GPP to change its /64 rule in accordance with RFC6177 and I
> suspect that this entire problem will go away.

can we shine the light on the other side of this statement?

Is the IETF beholden to 3GPP to the extent that it feels hidebound to 
maintain /64 as a generic autoconfiguration boundary for all ipv6 access 
mechanisms in perpetuity?

Nick

v2.23.0 | Report a Bug | By Email