Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

Mark Smith <markzzzsmith@gmail.com> Sun, 16 July 2017 06:31 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926FF1271DF for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 23:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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=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 GpRpiuJlSbZ2 for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 23:31:14 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 A8E57126B7F for <ipv6@ietf.org>; Sat, 15 Jul 2017 23:31:14 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id r126so63689498vkg.0 for <ipv6@ietf.org>; Sat, 15 Jul 2017 23:31:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YQ+CY/apj5t/YGl3GM7wW9trpjrBX0X9h6pBu0luaho=; b=ambunfGCCEv7t3mgqUozEELYZti75IqC1+aGSMzHHGJ1wPhFLi3yt08xQTAUcoUoBf /5TKJpnGzQTAUT+P4IgdzG0iNkgZooFvxbgEXkTsa/x3LDX2MeZps38+zoZQpG4idqxx UAKPEquQvw0PeF6petnaP8Jubv+7be5h08poBhT/JF2Pag0xWUBwJ5pI8NqW/a7Hqxbm hM7xg+0SaR8IpdjAmQBrY3jW3HHlNNbiGNCnckEaogMJWhytcgYiisTsNOe07Iq+5AJ2 YxMBRFUNcUC/WS7uniDXyUgiC9dwcgMHIRW1m2eL81MdxQ2Eub65VLb0wKDxYlBmoOYO aqGQ==
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=YQ+CY/apj5t/YGl3GM7wW9trpjrBX0X9h6pBu0luaho=; b=pJDqMo4MvbxrhCXRqAJpeOxHKfEbve7kLeKBmD5PEL5XcJLWByGAL2V4rqrO4f+aLs aIXbgcZAKTO/XZfz5ncMQHaf7R/sD2uRTzPwDFtq/E3n8lAX4oNfp7OX4xN9xaXosuP0 VDl0lBBtluNT5oorLJVggRurY1SsNZcMMYgQ3K26DUuLJRA8Jx82uYnIcOm+fUWet2Bz 3ibVd9GdS8fIPzZJN3sg80JFJ3ZIhw79nmmtGpRSWmbd2AYog2hf7speROfP6boNXVFW NnZxCrSP7ak6Z75Mu2qMHmKNbzMqGENHokOmN4TSmlbwGcf6FvzR44bRzXlK7FVe5bQr K0Lg==
X-Gm-Message-State: AIVw113z4ZqYXq/47oZGCkbAGidC7pBiHV/7r8LQFX37caNK0CH0sRbT hJpUB7Une/rNy4UfxUBmPUoL/ks+reik
X-Received: by 10.31.238.196 with SMTP id m187mr9649953vkh.96.1500186673649; Sat, 15 Jul 2017 23:31:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.18.105 with HTTP; Sat, 15 Jul 2017 23:30:42 -0700 (PDT)
In-Reply-To: <m1dWNTQ-0000FNC@stereo.hq.phicoh.net>
References: <CAN-Dau2zgthR2w9e5ZVUdGc-vm+YvK2uTUJ8O=vrcv0jNc58RA@mail.gmail.com> <CAKD1Yr2+Si_tzNF8p6ASf4=StgFSX9Gm3TEj9iiqdE2gHQaNmQ@mail.gmail.com> <CAN-Dau03r_CKW53kegaLa=F_R_RG4cWaCT1j6idrqPm9UuN03A@mail.gmail.com> <5963BF27.1050300@foobar.org> <ff09ffcd-df65-4033-8018-fbe7ae98cff8@gmail.com> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <CAN-Dau1bxm5y0v_6kUBc_ym39bSSxepjdwrzcS7YHWD=CV9-bw@mail.gmail.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x+282VK7nMFHjcCz9tBmJ_=d4OhkiRZFZDLcZhakGB1Q@mail.gmail.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x7ER2fUietjT3Ns-jpCqscCmVDVubiM0Dgw1_L0bkw=A@mail.gmail.com> <c7b140bf69104cd3877a7da03fbf17e7@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <m1dVbRc-0000GQC@stereo.hq.phicoh.net> <b6de67ac86804b308003454f9dc7607e@XCH15-06-11.nw.nos.boeing.com> <m1dWNTQ-0000FNC@stereo.hq.phicoh.net>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 16 Jul 2017 16:30:42 +1000
Message-ID: <CAO42Z2yqQaxthfWOtABzL+pk_CUgRD=KY4U68yPvvrzB0Qr20A@mail.gmail.com>
Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
To: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/b-D7wynosoWEuqtkYXPMAuOKiuA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jul 2017 06:31:17 -0000

On 15 July 2017 at 23:51, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>> > However, since the mid 90s we have a protocol for dense allocation of
>> > addresses. Where in the 64-bit IID space you can fit an entire universe.
>>
>> In a flat universe, maybe. No one is disputing that 64 bit IIDs
>> allow for many hosts in a single subnet prefix. But we also discovered
>> in the 1980s and 1990s how bad it is to create gymongous IP subnets.
>
> Just in case you missed it, I'm advocating that 64 bit IIDs only apply to
> SLAAC and not to DHCPv6 IA_NA.
>
> So using DHCP, a /64 prefix can be subdivided exactly as you want. You can
> for example hand out a /96 prefix using IA_PD to every link and then
> per link you still have more than enough addresses.
>

More than enough addresses for what specifically? Privacy and security
get lost with /96 prefixes.

Trying to accommodate /64 per multi-subnet site is trying to
accommodate irrationality. When a the smallest GUA allocation from an
RIR provides 4 billion /64s and a ULA provides 65 536 /64s (and of
course you can generate more of your own ULA /48s if that is not
enough), being miserly with IPv6 /64s is irrational.

We can go down that path, and we'll end up trying to engineer around
greater and greater irrationality - "If you make something idiot
proof, someone will just make a better idiot."  We know the likely
final end-result of accommodating >/64s would be a /128 per site and
IPv6 NAPT, because irrational people will treat IPv6 addresses as
though they're gold rather than lead, because they can.


> Note that I believe Lorenzo's argument is valid. The reason we can expect a
> /64 to be there is that SLAAC requires a /64. If we relax that requirement
> then soon we will see longer prefixes pop up and are back to square one.
>
> For DHCP I don't care. For SLAAC I just don't want the collision risk. So
> keep SLAAC at 64 and use DHCP for anything else.
>

Collision risk also exists in DHCPv6. There is no requirement that a
single prefix is exclusively using stateful DHCPv6 or exclusively
using SLAAC. OpenWRT by default provides addresses via SLAAC and
stateful DHCPv6 from within the same prefix.

rfc3315bis is adding an a MUST DAD check because of this.

Worse, OpenWRT uses the same IPv4 address range size for IPv6 stateful
DHCPv6. Your host can have SLAAC generated 64 bit privacy addresses
and 64 bit RFC7217 stable addresses, and then if it too supports
stateful DHCPv6, then it's stateful DHCPv6 addresses will be from an
address space smaller than 8 bits, from within a GUA prefix.

Regards,
Mark.




> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------