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

Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> Sat, 15 July 2017 13:51 UTC

Return-Path: <pch-b7900FA3D@u-1.phicoh.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 41BB4131BEB for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 06:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 QUhSkNO2MCdJ for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 06:51:12 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE0131BB2 for <ipv6@ietf.org>; Sat, 15 Jul 2017 06:51:11 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dWNTQ-0000FNC; Sat, 15 Jul 2017 15:51:08 +0200
Message-Id: <m1dWNTQ-0000FNC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
From: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>
Sender: pch-b7900FA3D@u-1.phicoh.com
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> <b6de67ac86804b308003454f9dc760 7e@XCH15-06-11.nw.nos.boeing.com>
In-reply-to: Your message of "Thu, 13 Jul 2017 18:16:03 +0000 ." <b6de67ac86804b308003454f9dc7607e@XCH15-06-11.nw.nos.boeing.com>
Date: Sat, 15 Jul 2017 15:51:04 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JqOmpRYHDZJKsTCIucsrlnRD5AM>
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: Sat, 15 Jul 2017 13:51:13 -0000

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

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.