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

David Farmer <farmer@umn.edu> Wed, 18 January 2017 18:09 UTC

Return-Path: <farmer@umn.edu>
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 66C7812945E for <ipv6@ietfa.amsl.com>; Wed, 18 Jan 2017 10:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 7knBci9EWE35 for <ipv6@ietfa.amsl.com>; Wed, 18 Jan 2017 10:09:32 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AFC12943E for <ipv6@ietf.org>; Wed, 18 Jan 2017 10:09:32 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 8D5F463C for <ipv6@ietf.org>; Wed, 18 Jan 2017 18:09:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoOJRb7FBMLg for <ipv6@ietf.org>; Wed, 18 Jan 2017 12:09:31 -0600 (CST)
Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 42B5A676 for <ipv6@ietf.org>; Wed, 18 Jan 2017 12:09:31 -0600 (CST)
Received: by mail-vk0-f70.google.com with SMTP id n19so11303065vkd.4 for <ipv6@ietf.org>; Wed, 18 Jan 2017 10:09:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ecRnXBq5KC5SRFDLXQCwtUuItLG/h65N0zDRp/dbrKE=; b=UuH2q7zTbz34BscIbnqHjvIxkxqR5ykGu4vRUs+/qEBgrflxR5uI/1kKhVKfvCoG61 CdPdA85BpuED/EDR/THju+xRxofYqIHg3kl+me3oUmy7EHQ8SYlpt6IndpyT0j2yd+Sy bj5LpzQSQvHz6ko5kxC9TCsToVYuzhtNj1dnyOLL3jJYBBYxvnaUb/b7dlc70dO+HBYA RhyDiWv3PMc9kShVrUR4hI05kAzzGNEaCgN0YD9X4NuJ7KsA2t9nscBKJJMoKcir8HtC NJIpV4zT1DNhAMMo/jYu2cq0jEPLnsilq/DLIVVCk/fG9NCRXFqCYE6B3xqztirWyCP4 WAfg==
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=ecRnXBq5KC5SRFDLXQCwtUuItLG/h65N0zDRp/dbrKE=; b=kwOSK69uNzYUbYoCDjTnyS85ustcwQucEqSqGbVd+fbBqO8wqSgMrzd2kOXGDhhHIK Q86+nPDRJybGKQAS58jz4tXBzL4yOyRZiPeW0WXc8exbuGknbygR3SvONKMzDuYZ1uFO 15LGrybvw28Uaftt+mESq4dQs5E60Y2/aO1cBBpLfHdSgEeSa8hKrh1tzq5xmbhxvNqf xTLY6aDa3K1wC+g2iUr36pgNCo3ZSbaCzp+OhhegwCfmco1qCLtAvnQt/JMzPh/8MPlf JeTrGbQ7toZGI/uPJVnoOPB3p9azB0/WhDoI8xDVFY7xfndWJd4azBGBw5dAeTRHS2CU /SWQ==
X-Gm-Message-State: AIkVDXJiKQaP9mAPuZXdA/Ef2MWdH8XWyE7JMr4izur7GWwXhIuUXfLyy9UVwCaE/ah4tQoM9q9jra3ZdNHIIYN0ISqF8btSIzoGV2c5ljJgaKRbXBOz1ms2ZFCD33IsxcSct1R7y9X60gtrp+0=
X-Received: by 10.31.49.216 with SMTP id x207mr2246683vkx.82.1484762970677; Wed, 18 Jan 2017 10:09:30 -0800 (PST)
X-Received: by 10.31.49.216 with SMTP id x207mr2246669vkx.82.1484762970455; Wed, 18 Jan 2017 10:09:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.84.15 with HTTP; Wed, 18 Jan 2017 10:09:29 -0800 (PST)
In-Reply-To: <CAKD1Yr1K5g8qBXoCrhS2+9BURxwbJtH822r54wpO8V82Qpr3Sw@mail.gmail.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <m2fukqbbwv.wl-randy@psg.com> <F6953234-3F85-4E28-9861-433ADD01A490@gmail.com> <m2wpdzhncn.wl-randy@psg.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <m2d1frhjfn.wl-randy@psg.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <CAKD1Yr1cvZ8Y3+bHeML=Xwqr+YgDspZGnZi=jqQj4qe2kMc4zw@mail.gmail.com> <m2lguffnco.wl-randy@psg.com> <CAKD1Yr1TrTiPRdyutobmb_77XJ7guNzLrg=H_p7qi4BfQ8V=GA@mail.gmail.com> <m2d1frfm6m.wl-randy@psg.com> <CAKD1Yr2Njjd8_Mr+6TRFF6C5pdcX4yFgpFVyEkykDuytu2B8mg@mail.gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.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> <CAKD1Yr1K5g8qBXoCrhS2+9BURxwbJtH822r54wpO8V82Qpr3Sw@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Wed, 18 Jan 2017 12:09:29 -0600
Message-ID: <CAN-Dau1o_rqJt5ZPg2Q6Z-WQX_Nj0fUrURc5PaqKJW-ky3vKLg@mail.gmail.com>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary=001a114409b26e1dde05466251ea
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SYN8Bsi5kMRt5o-FNIBinqQIlKg>
Cc: Erik Kline <ek@google.com>, 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: Wed, 18 Jan 2017 18:09:34 -0000

For such a supposedly "fixed boundary" it's awfully schizophrenic. We
supposedly want the option to change it in the future if necessary.  So,
then it's not so fixed that it's intended to be immutable, which is why we
needed RFC 5942 and RFC 7608. It's not so fixed that we don't have
exceptions, we have standardized /127 subnets and 127 IIDs for
point-to-points links, with RFC 6164. It doesn't sound so fixed to me, and
it seems intellectually dishonest as a standards body to keep saying it's a
fixed boundary when their is so much evidence to the contrary.  If fact, I
believe it is down right dangerous and counter productive to our intent to
keep saying it's a fixed boundary.

If we are simply start calling it a "recommended subnet size" then the
issues that make a "fixed boundary" schizophrenic are no longer much of an
issue. Recommendations frequently have exceptions and they are allowed to
change as things evolve, "fixed boundaries" aren't suppose to do either of
those.  /64 subnets are properly a recommendation, all be it, a very
important recommendation, maybe even a fundamental.  But, just because a
recommendation is important doesn't turn it in to a requirement.  That is
intellectually dishonest and section 6 of RFC 2119 warns against it.

If we want/need to enshrine /64 subnets and 64 bit IIDs for SLACC I'm
willing to live with that.  But to enshrining /64 subnets and 64 bit IIDs
for all of IPv6 is a mistake. And, it's a mistake that I feel needs
correcting before this document is promoted to full Internet Standard.

So, how about;

   ... For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length should be 64 bits and for SLACC [RFC 4862]
   that length is required to be 64 bits.

On Wed, Jan 18, 2017 at 1:36 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

> +1
>
> I don't think we should change this text in a reclassification. The fact
> that there are such strong opinions about the fixed boundary suggests that
> people think that it's an important property of the standard.
>
> That text has been the standard for almost 20 years. If we want to change
> it, then let's do it the right way: write a draft of a document that
> updates 4291 (or updates whatever number 4291bis ends up being, if we can
> somehow resolve the current point and publish it), and see if we can reach
> consensus. I doubt that will be easy.
>
> On Wed, Jan 18, 2017 at 6:32 AM, <otroan@employees.org> wrote:
>
>> I would argue that we should not make any changes to this text (apart
>> from the eui-64 part).
>>
>> Cheers,
>> Ole
>>
>>
>>
>> > On Tue, Jan 17, 2017 at 4:00 AM, <otroan@employees.org> wrote:
>> > > What breaks if all IIDs in global unicast are not 64 bits?
>> Especially other than SLACC?  I would hope such a REQUIREMENT has a better
>> motivation that "we said so".  Citing the "rest of the specifications" was
>> simply my shorthand for I don't see what else breaks.
>> >
>> > RFC7421, section 4.2.
>> >
>> > There's also a set of political considerations, where one tries to
>> achieve balance between the provider's desire to have effective aggregation
>> and the end-users desire to have enough address space. We specifically want
>> to avoid provider's charging by the address.
>> >
>> > O.
>> >
>> > Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it
>> does not say to me "IIDs MUST be 64 bits", this is a subtle but important
>> difference.  Furthermore, RFC7421, section 4.3.2, also say there is
>> operational use of IID other than 64 bits, which to me disproves the
>> statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64
>> bits."
>> >
>> > So lets be clear, I'm not saying that we should RECOMMEND other than 64
>> bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC
>> 2119.
>> >
>> > So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to
>> the in my opinion the more proper "IIDs SHOULD be 64 bits".
>> >
>> > So, I would prefer:
>> >
>> >   ...  For all currently
>> >    allocated unicast addresses, except those that start with the binary
>> >    value 000, that length should be 64 bits.
>> >
>> > But, I'm willing to live with what Brian proposed:
>> >
>> >    ... For all currently
>> >    allocated unicast addresses, except those that start with the binary
>> >    value 000, that length is 64 bits.
>> >
>> > But, I can not accept what Eric proposed:
>> >
>> >    ...  For all currently
>> >    allocated unicast addresses, except those that start with the binary
>> >    value 000, that length is required to be 64 bits.
>> >
>> > Thanks.
>> > --
>> > ===============================================
>> > David Farmer               Email:farmer@umn.edu
>> > Networking & Telecommunication Services
>> > Office of Information Technology
>> > University of Minnesota
>> > 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
>> > Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
>> > ===============================================
>>
>>
>


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================