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

Lorenzo Colitti <lorenzo@google.com> Thu, 23 February 2017 08:25 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 A1F5712A138 for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 00:25:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9yBmfkOT92kb for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 00:25:32 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 39F4212A130 for <ipv6@ietf.org>; Thu, 23 Feb 2017 00:25:30 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id t8so15919081vke.3 for <ipv6@ietf.org>; Thu, 23 Feb 2017 00:25:30 -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=NLG1PBZS0bjXRCxdQ0Y1uN13s1edUWR/HUMzWFbFGQw=; b=qmuAZWTSxC6H44zSaWfpEU7yNEnnGNLnYFDxVO3ca3NzlPs69STFo/hWpgI/CRDhgz 1+SPzEOgu155bKwE23CftGIPf8LoRGc9fHZa9o5tEFEuzPL7g3uuK9FBzLKr38oTa5XR SD/WkayqiHte5pfHHq+rEeZCJj2Ad49XNFTsfBX9fhEmW5AOCSt2sjNstpCDav+4jTOk +xKv2EAvxl3qBtWUubCBH0Llxoz/nJTF0LviLoYmOzW6/DxZQaHyuoMTC+aNDXxlkQPU EXmfk0Z567H8uWhZ6V501pE4sCYADLt+5i/a6wexAK7UTprVOKkiyAXcsJu+fB7LA3wO Dvrw==
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=NLG1PBZS0bjXRCxdQ0Y1uN13s1edUWR/HUMzWFbFGQw=; b=TnR3DvTISZG2kjczlVtiqiU4TczUJIF4unRUVKpA6fWgL7qD0EKxInap9fjn1IL1Ut NJqq/2yOPEJTxVSoM//otZ33reGWHdLy7jruNVt0Lhh/FCdV+hdSDIt56d/fB5G/qalg AR25fQKOYdku+Gcj1F0caT3A/BVDP2hCghDbVBoPcQ7KENb2n3uOJKM0IP59+0sKJkWt hOy2s4NSj5nRmPia/36nl/q/JTGvWMpEgYJkvFyLxUayljODlq8uoxu0lKWgY8+mkYVN 7sxT4SD2Pz5rz0EX+Zv+lTFbi3RXqEwkemR+Ui1eG3Kj2tBkAGfw4ViEqgDKNVKxLqRN Pz1Q==
X-Gm-Message-State: AMke39mfibtGL2JKK/edKANkPO3q93LdNOKN108c8FKWvRto01jPB5ALbNXBlTlf1IK0D0frh1Us9CWYXo/xyHuw
X-Received: by 10.31.248.193 with SMTP id w184mr18574384vkh.10.1487838329004; Thu, 23 Feb 2017 00:25:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Thu, 23 Feb 2017 00:25:08 -0800 (PST)
In-Reply-To: <30dda6a9-2683-8157-1b75-9aa154b8deb7@si6networks.com>
References: <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@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>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 23 Feb 2017 17:25:08 +0900
Message-ID: <CAKD1Yr1hSj0VQQ4vkxnnATxbW3eM2G3WK57OR-fNffydHz5BTw@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=94eb2c14bd2a15f11205492e5b1b
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nNi7VzVXNpMUR3S_cIKbzeuDdxw>
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 08:25:32 -0000

On Thu, Feb 23, 2017 at 4:33 PM, Fernando Gont <fgont@si6networks.com>;
wrote:

> My understanding is that Randy et al are trying to get rfc4291bis to
> reflect operational reality, but you want to progress the document with
> no changes, essentially meaning that you want to publish a document as
> full standard which doesn't agree with how the protocol is being deployed.
>

I think we all agree that the document doesn't agree with what Randy et al
deployed, because the document matches the existing standard and Randy et
al chose to violate the standard. What I'm saying is:

   1. The "operational reality" that Randy et al want to match is not
   widely deployed (in terms of number of links). The overwhelming majority of
   links on the Internet (of which backbone links are just a small number)
   follow the standards.
   2. There are hosts that follow the standards and only support /64 in
   some cases, or rely on /64 to provide useful functionality. Changing the
   standards to match said limited operational reality will render those hosts
   noncompliant.
   3. We should not render compliant hosts noncompliant because a minority
   of links purposely violated the standards.

If, even at the time of publication our documents already do not reflect
> reality, we are not going to be taken seriously.
>

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. Thus,
changing the document as suggested by Randy et al will actually cause the
document to reflect reality less than it does today.

Repeating a "classful addressing is bad" mantra isn't going to change those
facts.