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

Lorenzo Colitti <lorenzo@google.com> Wed, 01 March 2017 09:43 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 AC4F71298AB for <ipv6@ietfa.amsl.com>; Wed, 1 Mar 2017 01:43:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 Pkb_09W5Wbr7 for <ipv6@ietfa.amsl.com>; Wed, 1 Mar 2017 01:43:09 -0800 (PST)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 685BE1298C5 for <ipv6@ietf.org>; Wed, 1 Mar 2017 01:43:08 -0800 (PST)
Received: by mail-vk0-x230.google.com with SMTP id x75so6258568vke.2 for <ipv6@ietf.org>; Wed, 01 Mar 2017 01:43:08 -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=8o4o7szHK7b2JDQVkdhA69YKOexoVnzxk6mKQKphEzc=; b=vTvV0MPErA8QOtcDSGV0TwR1Jfr8vmMNPxG/ZHbJ/teYFs3kla/Q0rJIuPRKPxMJ7g VYU4PrhOLPzoYKAccoao1/qVOj6bJI9bIWKgAisMl/tmKCNdAOCw5EMavMkweF6nhILc QOyoo8/H9g6V9AvzGU96bR1+XspkW6jSLHz94forusT+22G1uHhYTuLiefYsahFTbJYi NMOs9BBvMaFUQXYXP5oxtPLAUGCBjIsUHWW9707Fa4TWRtRXGGGJcKT0opSc7mTsDFq+ g8AisyzhJwsO0jxa6WJeO2b9k/YtfZse3eQ/wiZFpSW6xoWlABbgt5slEDdu61I/e3CA +6Lg==
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=8o4o7szHK7b2JDQVkdhA69YKOexoVnzxk6mKQKphEzc=; b=jMxU3PmVVbkVkYHvzGVYvtetJ0avE0Vck0fS/OOnWmTNzw8yM4vQnYH/JTgWsVCYYP ImKn4PAB7wBbDZU5ubFj7EmVAUH3TS9GjxJWsEkriHuNP5E5UMxXLSjkSpvTi+yw4Xih Rwm8S0lbspxzsp6CsB7hypmOZwZSpB1Ezh3BQUr14gQrxhZoZoHiB3RWQw30NnMHVQek jk3L467Lvxfvc22L8ABQnoJawgF/KTCMWDbp6+Wf7dE1IYD+ATyQGA9UhuPiWHgrrFWo N8IWjXm/czMvmmupiJTPK3X9s7Rx3ILSogRWZ6pWpO00d+vLeeqMtO2MXGA4H0cXhsvL 4yPQ==
X-Gm-Message-State: AMke39n3DT+zOmv3pnlmg8v4oxx31Y5NQo5e6QyCDVh/9ljX7F2D/gKo6SXY8+RiPSkGNZvheI4CZTYaUzt9RSzQ
X-Received: by 10.31.59.197 with SMTP id i188mr2512115vka.45.1488361387257; Wed, 01 Mar 2017 01:43:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 01:42:46 -0800 (PST)
In-Reply-To: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <CAKD1Yr0qk_njAGnex_FZsYisCVw=eM8hXTr1v+wqvcfX_09wiQ@mail.gmail.com> <CAN-Dau0ohz3Wp55bs+eoFvSyoUjuKfjzKGSAsJS3wUt3z7TGtA@mail.gmail.com> <CAKD1Yr0wK8EiAbz39EZz-xZLtsSV2JROSzNECKtGo36Zc=RZ0Q@mail.gmail.com> <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 1 Mar 2017 18:42:46 +0900
Message-ID: <CAKD1Yr3c_utoa7vgXAGipe4-hbRQ3+2JY=ZZVhetX2zSCJ_FQA@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=001a1142f178c950700549a82360
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7g7F4LZ0SBlDCC4AgZjvfofzT-4>
Cc: 6man WG <ipv6@ietf.org>, james woodyatt <jhw@google.com>
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: Wed, 01 Mar 2017 09:43:10 -0000

On Wed, Mar 1, 2017 at 4:56 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com>; wrote:

> > I really don't understand this statement. How can you say that it's a
> > parameter, given that every RFC that has been published on this topic
> > starting from 1998 states that (most) IIDs are 64 bits long?
>
> Yes, I think we have a long tradition of expressing this badly, and now
> is a chance to get it right. It's clear at the point where it's
> introduced in RFC4291 that it's a floating boundary:
>
>   "A slightly sophisticated host (but still rather simple) may
>    additionally be aware of subnet prefix(es) for the link(s) it is
>    attached to, where different addresses may have different values for
>    n:
>
>    |          n bits               |           128-n bits            |
>    +-------------------------------+---------------------------------+
>    |       subnet prefix           |           interface ID          |
>    +-------------------------------+---------------------------------+"
>
> but later in the same document we state that (128-n) == 64. That is
> inconsistent; what we're trying to do now is fix that inconsistency
> in a way that is *also* consistent with running code, SLAAC, and the
> newly important privacy issues that require long, unpredictable IIDs.
>

Ah, I see the disconnect here: you're talking about the addressing
architecture, and I'm talking about unicast addresses assigned to actual
networks. Those addresses are called "all global unicast addresses except
the ones that start with binary 000" in 3513 and 4291, and "aggregatable
global unicast addresses" (specifically, 2000::/3) in 2373.

What I'm saying is that for that latter type of address, the IID length has
always been fixed to 64, and should continue to be.