Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Lorenzo Colitti <lorenzo@google.com> Fri, 03 March 2017 04:50 UTC

Return-Path: <lorenzo@google.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 CF8CC12948B for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 20:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=google.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 bvqFnsQ3efrU for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 20:50:10 -0800 (PST)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 1A21F129484 for <ipv6@ietf.org>; Thu, 2 Mar 2017 20:50:10 -0800 (PST)
Received: by mail-ua0-x233.google.com with SMTP id c11so51789435uaa.0 for <ipv6@ietf.org>; Thu, 02 Mar 2017 20:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T23ksa/5LDGbU8NLM7/nhaUQnJliki2N7eieTO8Rrlw=; b=CWXFA9ZAVG+Q7l5lO5xH6DWf4BKRiLIrjIhf7lKtzn8U2Tu5FQLZVyHc3HGp2NME6T TH38DGSc/UbfNa8AcVfoqYxiVU7IJNX2x4vMqJQkme3B3uP7bVe+DotrRQAqunkNFE3W oEx9HS8t1RdJbCPkz29Xut/OcbZzX8yCUQhm41vF9QrI+19ffUwK1ktg2N/LJmF1Xocp ebenEwEtCi+Cy54zymET8eS7WRHo/C0C3jj6so1bCBO2mUImWDTNMZrmLiXzQaTOArWr FMT110YBReovOrt/F2dwCmNbq3sDxWCnWbAkKJ56s4lrDMlFAVw6fnQnZRsIG0nA2u6Q KjlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T23ksa/5LDGbU8NLM7/nhaUQnJliki2N7eieTO8Rrlw=; b=rA3V3Dcnl2ysPYEl1c4yVF1YFfwnvrKPTiICWplNfV0vt06Jj+3PukK+jtAuWRYHwb ywQSI9r/64V5DryiZDCAT7TM2iy5C32bQRogsbLFLQC6qkDmIG1xEVqd1BFEU2r/a/OA QKZyNSv+rXnmjeC0E+gcSrY4VhGXHDOmVFLAoGWpfExQnf/FDqEXRTAKw7zQPbHheyFY 4uYLHWPrdokBMoNRXLcCPsOi9ArFlMX/LGsdyDQB1Jcy1kg+XXpHlxzoPDZb1WdDS5eD ail1s/9YakiPdlOtHsXjo0nC5AiXtIaerSGMAFHdlaI1UowzVHNjWOaEp71P7Ao2vkCa K3kA==
X-Gm-Message-State: AMke39kKlEZFb4DiZVGKWTjtz79WHLfH5ORQhmjIxRjLvIn9hmP4fEzLxpzgDPz2fAoMQKzcrU4QCOwN9ACt/mmK
X-Received: by 10.176.82.93 with SMTP id j29mr349480uaa.57.1488516608923; Thu, 02 Mar 2017 20:50:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 20:49:48 -0800 (PST)
In-Reply-To: <58B89AD3.3000806@foobar.org>
References: <CAKD1Yr0wK8EiAbz39EZz-xZLtsSV2JROSzNECKtGo36Zc=RZ0Q@mail.gmail.com> <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <CAKD1Yr3c_utoa7vgXAGipe4-hbRQ3+2JY=ZZVhetX2zSCJ_FQA@mail.gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <CAKD1Yr0qwwfH2a2ND7Va7tHigVTQ=iWkEwicxhTYpjuYMJnARg@mail.gmail.com> <58B6A02E.50501@foobar.org> <CAKD1Yr3j88RP=Hc3Xa-cMwOUZ1Td1uej0AHsNEKoAchoCe-ghQ@mail.gmail.com> <58B74D22.5010104@foobar.org> <CAKD1Yr3Du9U8UF98dhFSG6RBmTVdP5zqbpmYiraWejj_aLaY6A@mail.gmail.com> <58B89AD3.3000806@foobar.org>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 3 Mar 2017 13:49:48 +0900
Message-ID: <CAKD1Yr3yXsntsJXR2xSU9P2bQibXPhH_XAMQkktX0_hM=1xQHw@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Nick Hilliard <nick@foobar.org>
Content-Type: multipart/alternative; boundary=94eb2c1916a4b7e6e40549cc4721
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XDjZm6D1Rf2EDWerE7k1y7wieiM>
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Mar 2017 04:50:12 -0000

On Fri, Mar 3, 2017 at 7:21 AM, Nick Hilliard <nick@foobar.org>; wrote:

> > Let me rephrase the question. I asked for use cases for longer-than-/64
> > prefixes and listed the ones I have seen so far:
> >
> >   * "I only need 3 addresses" (but not "I only need 3 addresses and
> >     here's why I can't accept 2^64 instead of 3")
> >   * ND exhaustion attacks
> >
> > Do you have additional use cases? "This is the way we've done it for 20
> > years" is not a use case.
>
> Thank you for rephrasing the question in a neutral way.  Here is my answer:
>
> https://www.ietf.org/mail-archive/web/ietf/current/msg101724.html
>
> We will probably need to agree to disagree on it.
>

Actually, I agree with the comment itself. What I would like you to do is
implement your comment. I think what I above call "use cases" is what your
linked email calls "field deployment issues". If so, then my question
becomes: can you provide concrete examples of said field deployment issues?
What can't you do if all your subnets are fixed to /64?

If we don't have concrete examples, all we have is "some operators say
fixed /64 is bad". But we don't know why they say it's bad, and how bad it
is, or even how many of those operators say it's bad. If nobody disagreed
with the staetments being made by the operators on this thread, that would
be fine. But because there *is* disagreement, then reaching consensus
requires finding a balance between what those operators say is best and
what others in this thread (mostly host developers) say is best. That
requires concrete examples, so that we can all look at the engineering
tradeoffs together.

I'm going to ask again: what's the harm if all your IID lengths are /64 or
/127? What can't you do? (Other than use IPv6-translatable addresses, which
we should have an exception for.) You're free not to answer that question
at all, or to answer it with more general statements around operator
feedback being important to standards development, as you have so far, but
if you don't answer it with specific examples, I don't expect that you'll
be able to convince the other side of the debate any more than you have so
far.