Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

Lorenzo Colitti <lorenzo@google.com> Fri, 18 August 2017 01:17 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D2013269A for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 18:17:15 -0700 (PDT)
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, 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 kLze02lVKgFr for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 18:17:14 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 5F783132143 for <v6ops@ietf.org>; Thu, 17 Aug 2017 18:17:14 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id j32so28707287iod.0 for <v6ops@ietf.org>; Thu, 17 Aug 2017 18:17:14 -0700 (PDT)
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=EuezXgdf6J7hpqbpw/sK09UyMsakgvYE4HTAidonJLw=; b=XhnDVgLS+OpBzEwqnLkhgW1BKU/xfRpMuDQ+eu3A3vZBOMY1vWkCfIqEwDy8WE/UTo w8cElXiLnyHGsIndrcfVCQFaxYrSzoI27jWzU+CpcbCu1uArY1++60sJm/VdvyucMw3N eAmngUHm+u1kiejmNTKnvwR4q5+6hVvhbpt++vG/g8VfBaDKTbQpsHslKC+/dHQZOqBO uzljIXOHEdUNw0rLL8YNaE6Q8Wrn3EyHy49EbksnhkXldOjudN9maF47Hckv/uhktFeB qp7HmmVLeLrPSU3Xm4hg1Rrq2GKXymY56srcgY9/JVVJEGb0j+NQlXWk959vDgbGW+PK 0C2g==
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=EuezXgdf6J7hpqbpw/sK09UyMsakgvYE4HTAidonJLw=; b=YHnA7vHzUpjQexof+cxfL+GwML1aY9xwFRTCuH+9vr6D0WNKXjd/sbuvATJWUJl1/U 0YfgeZFLQJirCqgTE38oT3EVqblsKLrc8/V8rKF+fAm1532jc8iJpH8InYZ9FB/zW/9D hLx8BzuNch2Q6wRKTRYjlFlq4tXW5PM55peJYv8xuv+fhdgwz4dyhXe0gsk4VI7Wsy+B 0SuhcGO+ezkZv1RM50+9r+hUmossuuqzmcUlza/E0j1mCcoPcq65M8YRIxtBx7ts4/IU KqHJAZ4MQ0HOUuA/DrsbFkdd4/7MN2Tc/4CIp5uKnFWtzbe1ZURLm/iiAyCW0j3se4lE rAEw==
X-Gm-Message-State: AHYfb5ggm4iMutmbdz+s9m55LK8eIV/1ofxJn/xnQ8AI/vERK33etWfI 06VQOeMddHT65GOnhIqFCjmO4tjyXUZW
X-Received: by 10.107.56.214 with SMTP id f205mr7021231ioa.208.1503019033354; Thu, 17 Aug 2017 18:17:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.27.203 with HTTP; Thu, 17 Aug 2017 18:16:52 -0700 (PDT)
In-Reply-To: <CAJE_bqcimqX+L+F9SvZVNYV_Aj9NXVovbs=XzunfS9qDbiJw2A@mail.gmail.com>
References: <CAO42Z2wJBCo1yjguWSy-jzSvndeZTPgtN71FfdEhvqrVAUhZUA@mail.gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <BD3B4153-2EEF-4BFB-832D-D126A75AEC11@thehobsons.co.uk> <CAN-Dau2jzbQPuE5diEz-XzfRBHY=O1znE8hfy8P-Eee=MVwC_w@mail.gmail.com> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <CAO42Z2xXXjKUZ8qQY+b1NgDagX2ZJkqL5gieD+_js59ucp0EMw@mail.gmail.com> <20170810055819.GQ45648@Space.Net> <CAO42Z2xtfsYbw+Wf=ZjyFCmnDbhL17QCkWWRJ7F1+BgGCRiipg@mail.gmail.com> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <CAKD1Yr0uBU-LczaZJ5SdNpb_FpB0qfZJ0kNnr=gEviD+F3DTZw@mail.gmail.com> <B13F6A0A-BF0A-404B-A332-5A228F4AFC07@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <DCFE724E-B207-4527-82A1-5A268AC29989@gmail.com> <E673D8E0-7A55-490C-8316-77E178026C58@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <CAJE_bqcimqX+L+F9SvZVNYV_Aj9NXVovbs=XzunfS9qDbiJw2A@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 18 Aug 2017 10:16:52 +0900
Message-ID: <CAKD1Yr1Lcp5P2m7rvKTfuYXv=k1k5z_9q4RyJkWCfZzgjG0b9g@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: DY Kim <dykim6@gmail.com>, Simon Hobson <linux@thehobsons.co.uk>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="001a114ac8ca93a5140556fce375"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hxmH2HRP8tFUM52tDHsWc9IiL2Y>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Aug 2017 01:17:16 -0000

On Fri, Aug 18, 2017 at 8:43 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:

> This is not correct.  SLAAC implementations faithful to the spec
> should leave the IID length (and therefore its prefix length) open to
> the underlying link-type specification (such as RFC2464).  It's not
> open to be configurable/settable by the admin.
>

Actually, even more than that. For everything except ::/3 (which it is
unlikely that any implementation will encounter), IIDs are 64 bits long
because of RFC 4291.

Personally, I think this is why there is such a lack of consensus on
4291bis. The lack of consensus is about the future, not the
present.Currently, any new link layer that is defined has to either use
64-bit IIDs or update 4291. And any new address assignment mechanism that
is based on IIDs has to use 64-bit IIDs. If we change 4291bis to allow
non-64-bit IIDs, that all goes out of the window.

For example: if we remove the 64-bit boundary in 4291, does it instantly
become valid to create RFC7217 addresses with 5-bit IIDs?