Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Fernando Gont <fgont@si6networks.com> Thu, 23 February 2017 09:03 UTC

Return-Path: <fgont@si6networks.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 86899129682; Thu, 23 Feb 2017 01:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TA_QAAS0AhOg; Thu, 23 Feb 2017 01:03:00 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713CF12966A; Thu, 23 Feb 2017 01:03:00 -0800 (PST)
Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E9AC680A1C; Thu, 23 Feb 2017 10:02:55 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Lorenzo Colitti <lorenzo@google.com>
References: <20170221001940.GB84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com> <20170222144147.GC89584@hanna.meerval.net> <7960ff2d-359f-429c-6e82-ef592f90bf53@gmail.com> <CAKD1Yr1W+AVt4Dixo9epB5VazxBsVMD+mrshwaE=n7SuX6eGDw@mail.gmail.com> <m2a89dveop.wl-randy@psg.com> <CAKD1Yr1igJiL_2BVi=RL_Wkd6V0O6WaPJ5fMS+ggVkTRAOdPXw@mail.gmail.com> <3f6b3814-34ee-e8e4-3746-85b3e7e208d8@si6networks.com> <CAKD1Yr0LHCT9_3QzaDY=XKWwSsA5CtE-4EqaQsp_Fp_3-Y56GA@mail.gmail.com> <30dda6a9-2683-8157-1b75-9aa154b8deb7@si6networks.com> <CAKD1Yr1hSj0VQQ4vkxnnATxbW3eM2G3WK57OR-fNffydHz5BTw@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <cf739026-c333-28d0-9c35-ad5b9a8336a0@si6networks.com>
Date: Thu, 23 Feb 2017 06:01:54 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr1hSj0VQQ4vkxnnATxbW3eM2G3WK57OR-fNffydHz5BTw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8657p6P3Vk7KJzMEDsXO3zzH9gA>
Cc: Randy Bush <randy@psg.com>, draft-ietf-6man-rfc4291bis@ietf.org, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@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: Thu, 23 Feb 2017 09:03:02 -0000

On 02/23/2017 05:25 AM, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 4:33 PM, Fernando Gont <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
> 
[...]
> 
> 
> But they do reflect reality. If you look at the whole Internet, think
> there are probably 1000 /64 links for every /65-126 link deployed today.
> Removing the fixed /64 boundary will cause way more than 0.1% of hosts -
> which *correctly* implemented a fixed /64 IID - to become noncompliant.

The proposed fix is to stick to /64 for slaac, and make /64 the default
for other cases (while allowing the operator to override it).

If your comment above was made on the basis that hosts would be
non-compliant because some might not be able to e.g. be configured with
a longer-than-64 prefix, then... that's what usually happens as you
update a spec.

OTOH, if your point is that we cannot do that in the process of moving
this document to full standard, my take is that it's better and more
productive to get the document right, than to cast it into stone "no
matter what".

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492