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

Lorenzo Colitti <lorenzo@google.com> Thu, 17 August 2017 00:13 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 6008A13242B for <v6ops@ietfa.amsl.com>; Wed, 16 Aug 2017 17:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 mAOLIMkRVBI1 for <v6ops@ietfa.amsl.com>; Wed, 16 Aug 2017 17:13:15 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 E01B5126BF0 for <v6ops@ietf.org>; Wed, 16 Aug 2017 17:13:14 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id m34so24267082iti.1 for <v6ops@ietf.org>; Wed, 16 Aug 2017 17:13: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=Qg1eTbqms1NGg+aQK9jQiwyvpJT4BRxAYbRMyp1bytg=; b=s16Y4NMNA7qWdc82w6L17P9mhkmW9ZbdcgLOdP7k5uUhdkfKmxgaZKPlR5PIcjljc+ U80t2LUpEVfnhH0IeJaCL/QqtCTcl5F3jtpxe2w5G7GLVRs7wpP4bEuHqmCBpn242y1B Jbc/T/Ml4rLPsjZhpMb9Gx7Jce3djsQx5bkXZevi09HWjTilfspuxVDioXabpz/9IKw+ 8ds8Ks2EcfFPM+34T92AcmiKJeQNM1+MttvRwFRasOXSgvqMSIlfRBwLqaDLjhb0KUWP PMhSLxddTUmPDjSSrCA066ETDo2zikJtcy7xVLFjQRiLUuvt/5y4bfu52DYnYDgQkqZ5 OzoA==
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=Qg1eTbqms1NGg+aQK9jQiwyvpJT4BRxAYbRMyp1bytg=; b=On3c817i/zYpBC0zGEL/Hl326LQSk27gLIbylN4TExuclApiEaF7wYZuM66yKuNhi/ stsG04RLn/ExFqVaaUATNFPj4ItS2AnKXNXSEJF+TBQW7hMQ0Rol8DQFqFbeEm4E2wlU GBdYOnS0RBII/0Xuof32bXVvk7Wfs6ugSGDqn9A8xblmT9Ps1ueC0X1aUaIbCYL6eK4/ tXW9VOPyVUo/W/hw2FfarphHf5Rdwe5JxKHdw2NCKQ11JkZq+WtHe0nGs576sRf3TGa5 7a6fnP2yqjV5Lbg6/2cl6YaEXbvX0NcfLuQS3y0jMRLc8RQG8q52jqNknEQXIjxmnmoG BUqw==
X-Gm-Message-State: AHYfb5gczUzmFxD6jrUFoiovjGVtVxFm4L9UVOGUwK48Pduuj+/fx76A lwgZQ04okQll6XEYtWY30XjfmnY/tQ81
X-Received: by 10.36.25.70 with SMTP id b67mr221500itb.72.1502928793703; Wed, 16 Aug 2017 17:13:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 17:12:52 -0700 (PDT)
In-Reply-To: <B13F6A0A-BF0A-404B-A332-5A228F4AFC07@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>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 17 Aug 2017 09:12:52 +0900
Message-ID: <CAKD1Yr3+5E20tEU1Te=QVsVr1uQVHF1gLX_7NEFK0X1Q99eaPA@mail.gmail.com>
To: Simon Hobson <linux@thehobsons.co.uk>
Cc: v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143d716dfd7db0556e7e0c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/GO199C8QozN2V7_RtgooSduNwtA>
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 00:13:18 -0000

On Thu, Aug 17, 2017 at 4:47 AM, Simon Hobson <linux@thehobsons.co.uk>
wrote:

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

In practice it does not because every link layer specifies 64-bit IIDs.


> > No. Someone wrote code that gets a prefix via DHCPv6 PD, and blindly
> announces it in an RA.
>
> Are you suggesting that someone who realises that not everything is a /64
> would do that ? You've not really done anything to counter this being a
> case of "everything is /64" thinking and thus ignoring the potential for
> anything else. It may be a simple case of blindly re-announcing the prefix
> you got delegated - but it still comes down to not understanding that the
> prefix may be other than /64.
>

You could just as well answer that if someone thought that everything was
/64 they'd just reject non-/64 prefixes.


> > Already? 64 everywhere has been the standard for 20 almost years now. It
> predates pretty much every IPv6 network and every IPv6 implementation out
> there today.
>
> And that hardcodes in a restriction which IN THE REAL WORLD is known to
> cause issues. For example, you (incorrectly) only get a single /64 from
> upstream, but want to something other than a single host or very simple
> network. I agree that it shouldn't happen, but in the real world it does -
> you either stick with a simple basic network, or you run prefixes smaller
> than a /64.


If the ISP is well-intentioned, it will give you a /64. If the ISP not
well-intentioned, they will give you an allocation that is the minimum size
that clients are prepared to accept. So you will never be able to subnet
anyway - as soon as your device is willing to do SLAAC on a /80, that's
what your ISP will hand you. There's no point starting that arms race.