Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

otroan@employees.org Fri, 20 January 2017 18:17 UTC

Return-Path: <otroan@employees.org>
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 5EEA6129405 for <ipv6@ietfa.amsl.com>; Fri, 20 Jan 2017 10:17:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.335
X-Spam-Level:
X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 ZfDO8uXi76T4 for <ipv6@ietfa.amsl.com>; Fri, 20 Jan 2017 10:17:15 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE05127076 for <ipv6@ietf.org>; Fri, 20 Jan 2017 10:17:15 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 19 Jan 2017 23:52:46 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 8AD95D788D; Thu, 19 Jan 2017 15:52:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=rMbLiTWCj5lmgCyCZfrJUj3GwPs=; b=p534nK0/dZGZiITH1A r2hm3U8OzsOr9op6fh6lFE1n4jscm2yhmpS5SAWAq0PE/nsh/gzLIIUEorApuqGm MzZa5AzmJLdKOS66dZRwcosgl5fbBgd42zuQA0+FpV0Za3t6R8+igQwVapORDa5i /3scPBiKSB+n76xMhVRYyglp0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=hyIzdM2mBn7w4nhI0XDmbO6PYhLbCKzRnFMEcv6SDU1nlo5YPp2 /LJfRzQoFz+v0F6zEfTee37SrFsf4jgg/SMRYb5z3VG/BMgO+C7FQKVgiuroNwAk a+aJuU4BWej6/bqfhE2PHFvGkhUbJQlovVVQZuaSXsbVstd6NGCKjrDQ=
Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 1D299D788A; Thu, 19 Jan 2017 15:52:46 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id ECFEA78D9CE5; Fri, 20 Jan 2017 00:52:43 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
From: otroan@employees.org
In-Reply-To: <CAN-Dau2ygz+iTtZ_hLLPMPs-tVYjeQUaknLeCj82ba938DZ9-A@mail.gmail.com>
Date: Fri, 20 Jan 2017 00:52:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DF96FB9-E922-4351-9D44-A80B0568194B@employees.org>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <CAN-Dau06R3iYRpYLADhvHox4C9qdsJCuxFsJapRhOQcWT4qk_g@mail.gmail.com> <CAO42Z2weZcoHiBzN94QAQ9WGhWR16PmMMFNg=5YLmr_dhPjjpA@mail.gmail.com> <fcf580ec-3617-ca5f-5337-37acb6e928ba@gmail.com> <CAKD1Yr25zNeQGvNJa=WzCjKMd9LaYrSwG=o4tUWn1Zc2ASZjrA@mail.gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <CAKD1Yr3wyza0_enWErMhmKKkA1ZOXPv5GG8dMT8HUQZsB5--UQ@mail.gmail.com> <CAAedzxppi5g_S05-m+B2jKMYePapPM0_wMA4XioYgwipwbKVHQ@mail.gmail.com> <CAAedzxoY6MGyvzDvUcZ44ka=5RcGwQ16fzRp29445Pa7mQYNHA@mail.gmail.com> <CAN-Dau36r2UgXPfdcdEAJ914QqvVvjGJK+=mgE9Y2tpBiDSRig@mail.gmail.com> <CAKD1Yr3RpUaNKkyTPHPWWew80cyGkiT1p7vYwfejESP4tQw31A@mail.gmail.com> <CAN-Dau0OsD4RcVUN+me98g6SJ=oaAr4HoqGtP88PTbMU_-kuGQ@mail.gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <CAN-Dau0Fkb-M8VM9iL9xwy89bir5PhNHJ3D1VFrnNppVXNyeOg@mail.gmail.com> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> <CAN-Dau2ygz+iTtZ_hLLPMPs-tVYjeQUaknLeCj82ba938DZ9-A@mail.gmail.com>
To: David Farmer <farmer@umn.edu>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0Yu0T-I7KY6GpFTr6fhR3pcX8Kk>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 20 Jan 2017 18:17:16 -0000

Dave,

> Given that what we are left with is policy, I think it is quite harsh of you to declare that there is no consensus on the current text on the IETF list.
> There are good technical arguments for why each host needs more than a single address, and if we end up in a situation similar to IPv4 where each address used has to be justified, then we have lost. There is a justified fear that allowing the 64 bit boundary to slide, we will end up in a situation similar to IPv4 addressing. E.g. charging per address.
> 
> I'm a little worried that your fighting yesterday's battle.  To be honest, I'm less worried about charing for more than one IP address. I'm much more worried about charging for more than one subnet. In fact, I'm worried a hard and inflexible boundary at /64 reinforces a model for charging for more than one subnet.
> 
> If that happens would you prefer people use NTPv6 or NAT66?  I'd prefer a more flexible subnet boundary, that allows the18 quadrillion addresses in a /64 to be broken into smaller subnets. 

Therein lays the paradox. If the IETF were to standardise arbitrary prefix length > 64 you end up being charged per address. If implementations don't support arbitrary prefix lengths > 64 you end up having to do NAT66, ND proxy...
Which is why all implementations should support arbitrary prefix length, but not tell anyone. ;-)

> 
> Furthermore, we are talking about giving individual devices their own subnets.  I like this model and with today's scale that will be fine.  But, longer-term this has me worried, especially if we keep a inflexible /64 boundary. 

That would require extreme waste in the first 64 bits...
2^64 number of addresses is an awfully big number.

> This is where the IETF has to perform a fine balancing act. On one side ensure that the 64 bit boundary stands, at the other side ensure that all implementors do not enshrine a hard-coded boundary in their implementations.
> 
> Ok, are you willing to put that in the document?  The /64 requirement, is a political consideration, not a technical one.  Because other than /64 subnets are clearly technically possible, we have evidence of it in RFC 7421. 

But unless we also kept some technical limitations, would anyone accept the boundary if it was purely policy?
(And at this point there is surely a lot more technical reasons than just SLAAC.)

Best regards,
Ole