IETF Logo Mail Archive

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

DY Kim <dykim6@gmail.com> Fri, 18 August 2017 00:44 UTC

Return-Path: <dykim6@gmail.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 73DB51323D4 for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 17:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9LWPeRfRFxuk for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 17:44:26 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 7DE36132652 for <v6ops@ietf.org>; Thu, 17 Aug 2017 17:44:25 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id c28so9124377pfe.3 for <v6ops@ietf.org>; Thu, 17 Aug 2017 17:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vCrLSefTujm8E4YKgCQBCQt1O80NxJFo1qTzSJBucck=; b=DylhLZxmxXlzT1wDj0rQdC/cCmwKV8TAhCNcNZaREM4FYc1aPzq4KyqWXcZ8079Vl1 x/w8gHhN51f0oDKc61KrIDo0rnNtXM84283WcNiXpSNHN0rjvJGrq5rgLTLJNw6Jh0t+ c3vGb1484NrAo1IkxERgtcUwQgcJhETt/qZv+u1xzrzXcmxVgcUf+rGqFax5da8yf9Mi 33+r3A8ut/PM0AWsRThWgI31wIARm+eKPitE3fLLmqMopy6fcCv63Gcv6kXe5hi8Eclg J9kc9Ax9adks7eXsTqyGQnzi+S0lbcPlXdK6EKClkFo75X8mWWTCoNufQSYDKVTT5ZMB l6pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vCrLSefTujm8E4YKgCQBCQt1O80NxJFo1qTzSJBucck=; b=RXK/E0X1dJHIMtUyZBA2FblKJsuHQm3G8ftWSTwXpKWGca3J/iqYldO9p1BppOIPNG SgkpiQfNxyD2scUFLtzKXHIRsJZyquSeXIFg4jjWhjLfNEMnuwk5yx3wFC6yNV9CSy9q 726Z/+aQ+viDDuaF524YkihRIVsA7cRsvOyIvNU5x7EAMvpbWLHyfG004DEPMIMsdKfx MKpUHQdr5hkhQid0Y2yCuumZBdznEmywN+13mAxh61YL/G9hQOturUURsVNSq4we+BOx sJiXMm6x6QNO/9rKucYEMEZ+UFQ8WlDDoDr5SjgBCtOWRsAnVODwLnILWssREqVf/Bfz E6vA==
X-Gm-Message-State: AHYfb5iCyXMTYX88qgU0RGCdd4IYqAsC55WUwu0vhG83CM6VnXVd1vgD wnMhLdisuzd0Cw==
X-Received: by 10.99.38.135 with SMTP id m129mr6819845pgm.393.1503017065058; Thu, 17 Aug 2017 17:44:25 -0700 (PDT)
Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id p2sm7104786pgr.4.2017.08.17.17.44.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 17:44:21 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: DY Kim <dykim6@gmail.com>
In-Reply-To: <CAJE_bqcimqX+L+F9SvZVNYV_Aj9NXVovbs=XzunfS9qDbiJw2A@mail.gmail.com>
Date: Fri, 18 Aug 2017 09:44:18 +0900
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Simon Hobson <linux@thehobsons.co.uk>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <392C32D2-E0C8-477B-9F95-834D193C706A@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>
To: 神明達哉 <jinmei@wide.ad.jp>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/W37o56ipmg88srAJowu5vYd0GZs>
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 00:44:27 -0000

Now, it’s said the IID should not be derived from the link-layer address, for privacy. If anything, the link-layer address shall be conveyed in an option field of a related packet.

Now, what still mandates the IID length be 64 bits?

---
DY

> On 18 Aug 2017, at 08:43, 神明達哉 <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.
> 
> If an implementation unconditionally hardcodes a particular value such
> as 64, then technically, it's non-compliant.  But as of today it's not
> distinguishable from truly compliant implementations based on
> externally visible behavior, since all known (at least as far as I
> know) such link-type specifications use the same single constant, 64.

v2.23.0 | Report a Bug | By Email