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

otroan@employees.org Tue, 17 January 2017 21:32 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 0B5A31295B5 for <ipv6@ietfa.amsl.com>; Tue, 17 Jan 2017 13:32:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.264
X-Spam-Level: **
X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, 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 Bt73Kt_yMMSN for <ipv6@ietfa.amsl.com>; Tue, 17 Jan 2017 13:32:36 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id D57911294FC for <ipv6@ietf.org>; Tue, 17 Jan 2017 13:32:36 -0800 (PST)
Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 17 Jan 2017 21:32:36 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EDBE2D788A; Tue, 17 Jan 2017 13:32:35 -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=6D+wnJjPlccjCCQtG4GUI+KlRrY=; b=AqV4Iw0RU11iiKX3eL UcZzsk5cgdEbaU2yXDsC5omJVobeQCXds2RE3Bng+S9Q7SnD8S8pZv6/lq7YY3mm DX3JWKL3WsMD3BhNHVfmMX3N9vbBtueHkf+BBdMfePBsgrIRdDJfXD9BYbNUQhYl 1eHy9eDx1CN/FgTm8FLdnUpb8=
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=rfTXfaXDP2rSoJ78miVQjRGg3kHfcwEro+8JK67pIg+yf/GJF1P W88eH5zHIa2au4i2+mdsgHm3O9VdzF6vxIUO3eBLGHeG+EP3SLiYVapSN8XXoY8G 8cUWh+csmCOY2ngjDKDcmWYbx9eAsmko830M87bU4YDFjIC8sKpV/05g=
Received: from h.hanazo.no (unknown [46.228.50.218]) (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 6BC53D788D; Tue, 17 Jan 2017 13:32:35 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2E4BD767C827; Tue, 17 Jan 2017 22:32:33 +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-Dau0Fkb-M8VM9iL9xwy89bir5PhNHJ3D1VFrnNppVXNyeOg@mail.gmail.com>
Date: Tue, 17 Jan 2017 22:32:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: David Farmer <farmer@umn.edu>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/WQBeBdVDBmi1dnumUPGzC2hRPTU>
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: Tue, 17 Jan 2017 21:32:38 -0000

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