IETF Logo Mail Archive

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:36 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 E61461327EB for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 00:36: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 wbp8CxXV2kYm for <v6ops@ietfa.amsl.com>; Thu, 17 Aug 2017 00:36: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 DC5AD132436 for <v6ops@ietf.org>; Thu, 17 Aug 2017 00:36: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 540AE2D4FD1; Thu, 17 Aug 2017 07:36:45 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 356AFF8FF3DD; Thu, 17 Aug 2017 09:36:44 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_108A4CBD-5F2A-4A23-9F56-7804BBD61BF0"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 17 Aug 2017 09:36:43 +0200
In-Reply-To: <B13F6A0A-BF0A-404B-A332-5A228F4AFC07@thehobsons.co.uk>
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>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/zkbjFdO_uzglEDfxAWD3rdjI8bU>
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:36:51 -0000

Simson,

>> /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

v2.23.0 | Report a Bug | By Email