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

Lorenzo Colitti <lorenzo@google.com> Wed, 18 January 2017 07:37 UTC

Return-Path: <lorenzo@google.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 7D85F120727 for <ipv6@ietfa.amsl.com>; Tue, 17 Jan 2017 23:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 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_LOW=-0.7, 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=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 jY97o1QxdaC3 for <ipv6@ietfa.amsl.com>; Tue, 17 Jan 2017 23:37:10 -0800 (PST)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 00C95129667 for <ipv6@ietf.org>; Tue, 17 Jan 2017 23:37:09 -0800 (PST)
Received: by mail-vk0-x22d.google.com with SMTP id x75so3051758vke.2 for <ipv6@ietf.org>; Tue, 17 Jan 2017 23:37:09 -0800 (PST)
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=XYI4+CfBHYbuvliN/1HqxjPjy8YF92ZWwAALkXluzd4=; b=sU+eLHyaoSMSDWm9AShi/TLjWoAyakit3uoocbKsVlJDUTai5UInmPzOqslWVWEJ+8 arTviyvSI4TMSo2SBAwL5MaEHI0KchDgu69bKUKdahZEDEpDK/Tk2X8JtBS1QOh8AgeI V71jOytajWTmj9aB0OJ4qAUmiMaEf+fmyvsLg4RxDTxayXWyAAcUhu/Ya7tWIxmH5r8A CGkLJvjQ22Cnr2+2JET1H6E1oSuH9w0VRtPuGljarNNNs0HIDN8HQ/RMOEH8vl0x0B/j rI/tZUcU+H7aYAihhnxKcchNNoq18MieEjLaNdTLiJCXJmP7mZVbnSfAdDia3Dw06ase NcUA==
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=XYI4+CfBHYbuvliN/1HqxjPjy8YF92ZWwAALkXluzd4=; b=QGsN3YS3/V0SkD7LkC5AH/1pFrwN9qxDdHp5JSj8IoTXVLxAoGS6rXCMwZV8NxPO/Z 1beqrAwvI3LordzOFYr4aejXRmOnBmhx5iA80AXqnfhLuG3gB+dhIYYzQLG7yihzvpYz 7UVzH25XShy1BBn+QAWJ1whEOGqVqMSjRmSRWEVHVIK0avhcSsF4PdVp9bvzpR+j/mOl mRoCHk9NeZv1kjQpu8icNRAjjx+IfP8vQtp6IxlG1ln7BOXkVlqgeryhAtoXIjNOvFOD dJALw+p1fUBDV7nOm5m8rJ34l773MisRZLxy23ZPyv6W/TO0ftkc1qfa9nF7PPIp560f kM7A==
X-Gm-Message-State: AIkVDXJA4oPC0/72vWrIwOEcX94DlZmxlxdlGFDocMx0+srfBB8iOLE7f6v5wlKiw6VSf/fBILDOckUWnvysa/Zi
X-Received: by 10.31.72.69 with SMTP id v66mr936328vka.156.1484725028952; Tue, 17 Jan 2017 23:37:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Tue, 17 Jan 2017 23:36:48 -0800 (PST)
In-Reply-To: <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org>
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>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 18 Jan 2017 16:36:48 +0900
Message-ID: <CAKD1Yr1K5g8qBXoCrhS2+9BURxwbJtH822r54wpO8V82Qpr3Sw@mail.gmail.com>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: Ole Troan <otroan@employees.org>
Content-Type: multipart/alternative; boundary="001a114d9c6ef0ec730546597b90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OtModpOI81-IYUsUPtEZz2PDT5M>
Cc: 6man WG <ipv6@ietf.org>, Erik Kline <ek@google.com>
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 07:37:13 -0000

+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
> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > ===============================================
>
>