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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 06 November 2020 23:20 UTC

Return-Path: <brian.e.carpenter@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 CB1923A0E37; Fri, 6 Nov 2020 15:20:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.345
X-Spam-Level:
X-Spam-Status: No, score=-2.345 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, NICE_REPLY_A=-0.247, 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 RBVmxGERns6B; Fri, 6 Nov 2020 15:20:53 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 429363A0E2E; Fri, 6 Nov 2020 15:20:53 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id x13so2817639pfa.9; Fri, 06 Nov 2020 15:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e+SnbhLDdeiqdVOPBfZ1L3uvSoDLxFbA2we3L+dnRRk=; b=udNa02QBNrnqmbBjIBBcwGGfo40KhR9hXhYeCRZb0TaOONiHBk7E6MYnkoADSizEbC XkMbUkYvA4cKuDGO725pIMCGMqofEZi/ZETL4k3zbm7Y0j7KKq1ZwUV5gARbsEPZU7K/ 1wWcRfer9crxpKVDl0Nk60I6xiNWAUfprSCebYiQlgl1JOqUXO1gdXDs1MsVRb9lKTaI q9zv9OBfK5gVt3wJD3P6VlWWFE/jY2wDcRSFSaVVgzNJZcMWiMBkcLZpXRhD2QLauFgZ 2WXsK9nyDdD+7uvXhXt2Y2e6xA2yf0YSeoplWqyJ7yFVsFtRsJwm+4Nu+LvpLZWFIQEj IoSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e+SnbhLDdeiqdVOPBfZ1L3uvSoDLxFbA2we3L+dnRRk=; b=I9pbOkjT1VRq78NMS+ZHSTAvUp9WmX0Q8mwmWn0U1Mt5GTpY+PxMe21z2kO0NupMWQ 2uNfUgb/tzbJXRfZ+jLVZyI657GAho0EbdqcOoag+Z0eVn13bYlREJ9kK2UK+ck8hn+E thfGfgIFEFWXdGW3W/3TrY284nZhbcqgIt4MXLR0m6kEAzf9gAAz+XNVSsCTT5XryARK V1JjvsbssMCHiBDYUpzQ/F4/oBpLhnh/PWav0eZXqe49e3cPPs1LsOpr23onJTxWFO/E qLJXZR+IML4roYL8LLNJ8TanIRWekP/UulF1eaWmik23eGWW30uNYy1cAcpJlzrhvaN8 1P8A==
X-Gm-Message-State: AOAM532MuTZm20aB/beJrxwfMtAsBzaG1GWzdxbm5UjZPEv1hZVhuY7B /9H9Ovg/9gM+TmChcIn3WlHNGBiz/Ew5XQ==
X-Google-Smtp-Source: ABdhPJzmfB2f0IXNxRdKRG20ErncEHyFzE0Yq8x5rFEUFapDckm0R+vvA6zTbEYro5D3rdYNA/TOew==
X-Received: by 2002:a63:6c09:: with SMTP id h9mr3465302pgc.214.1604704852283; Fri, 06 Nov 2020 15:20:52 -0800 (PST)
Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id 128sm3352515pfd.110.2020.11.06.15.20.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Nov 2020 15:20:51 -0800 (PST)
Subject: Re: [**EXTERNAL**] Re: the race to the bottom problem
To: "Mudric, Dusan" <dmudric@ciena.com>, Bob Hinden <bob.hinden@gmail.com>
Cc: "draft-mishra-6man-variable-slaac@ietf.org" <draft-mishra-6man-variable-slaac@ietf.org>, 6man <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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <c5402655-9bfd-dafd-ceef-25b1f9c36770@gmail.com>
Date: Sat, 07 Nov 2020 12:20:47 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <25099A60-8685-4226-8328-AA87376B62D2@ciena.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/q3mTNV0k-hxwD0EluDw-aoMOJHI>
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 23:20:55 -0000

On 07-Nov-20 12:08, Mudric, Dusan wrote:
> The first sentence is taken out of the context. I actually said:
> 
> "- There is no race to the bottom. We are not trying to solve ISP problem by allowing longer than 64bit prefixes,
> - It is not about restricting the ISP prefix assignments to minimum one 64bit prefix, by imposing 64bit SLAAC prefix limitation on the clients,
> - Minimum of one 64bit prefix limitation should be imposed by other network elements, rather than clients. Edge routers can block >64bit prefixes,"
> 
> because I believe the race to the bottom can be addressed by other network elements (e.g. CE), not only clients.

But the consumer CE is very often supplied by the ISP, and it therefore does what the ISP wants. If that's different from what an RFC says, it's the ISP that wins.

   Brian

> 
> Dusan
> 
> On 2020-11-06, 5:11 PM, "Bob Hinden" <bob.hinden@gmail.com> wrote:
> 
> Brian,
> 
>> On Nov 6, 2020, at 12:09 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> On 07-Nov-20 03:30, Mudric, Dusan wrote:
>>> Would it help if the problem statemen clarifies that:
>>>
>>> - There is no race to the bottom. We are not trying to solve ISP problem by allowing longer than 64bit prefixes,
>>
>> Unfortunately, once you push code allowing >64 subnet prefixes for SLAAC into the wild, you do automatically give ISPs a path to to allocating longer prefixes to customers, and all history tells us that some of them will follow that path.
>>
> 
>> Once that code is out there, the race to the bottom is enabled.
> 
> I fully agree.   And once it is broken, there is no going back.
> 
> Also, I have yet to see any solution to having a mix of devices on the same link that can only support 64bit IIDs and ones that can support shorter IIDs.  I think there is an impossible transition problem.
> 
> Lastly and probably the most important, I have not seen a convincing argument why this is necessary.   The risk is breaking IPv6 in a fundamental way.
> 
> Bob
> 
> 
>>
>> Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the /64 default for SLAAC. (If it did, my name would not be on that draft.)
>>
>>   Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
>