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

Ole Troan <otroan@employees.org> Thu, 17 August 2017 07:37 UTC

Return-Path: <otroan@employees.org>
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 8A3D21327FF for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 00:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 7JkdTl1jd5hA for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 00:37:48 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C759C132436 for <v6ops@ietf.org>; Thu, 17 Aug 2017 00:37:48 -0700 (PDT)
Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 4C0A02D4FD7; Thu, 17 Aug 2017 07:37:48 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 30986F8FF53F; Thu, 17 Aug 2017 09:37:50 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <33706CF4-26EC-4C30-98AD-8939C9CA9DB6@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_BBA4662A-AA89-44B5-BAB7-A785A9567BE8"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 17 Aug 2017 09:37:49 +0200
In-Reply-To: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org>
Cc: v6ops list <v6ops@ietf.org>
To: Simon Hobson <linux@thehobsons.co.uk>
References: <CAO42Z2wJBCo1yjguWSy-jzSvndeZTPgtN71FfdEhvqrVAUhZUA@mail.gmail.com> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <B6A257C9-7E8A-452D-9C0F-0B10A31990CB@thehobsons.co.uk> <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>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/f05VcsC3dib828AYFAt2BB8E_H4>
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: Thu, 17 Aug 2017 07:37:50 -0000

> Simson,

Stumbling fingers, apologies, that should of course be "Simon".

/ot

> 
>>> /64 gives you something that no longer prefix does: the ability to run SLAAC and connect unlimited devices behind the host.
>> 
>> From previous discussions, I am led to believe that SLAAC will work with other (longer or shorter) prefixes. It is only the deprecated EUI64 method that *needs* 64 bits.
> 
> That's not quite correct, at least not in a historical context.
> While the term "Modified EUI-64" was most commonly derived from a MAC address it was also used for interface identifiers derived by any other means. Be it serial numbers, random tokens or manually configured. By that definition an interface-id generated with the method in 7217 is still a Modified EUI-64.
> 
> With regards to your "will work" comment. Sure, it is just software, we can make anything work.
> I am not aware of any implementation supporting that though. Certainly the ones I am involved with do not.
> 
> Someone pointed me at this paper which is quite relevant for this discussion.
> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/State-the-Problem-Before-Describing-the-Solution.pdf
> 
> Best regards,
> Ole
>