Re: IID length text

Lorenzo Colitti <lorenzo@google.com> Tue, 17 January 2017 01:10 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 A00C5129954 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 17:10:27 -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 1OC0MBqrkjR6 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 17:10:25 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 9F33112994F for <ipv6@ietf.org>; Mon, 16 Jan 2017 17:10:25 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id x75so83553029vke.2 for <ipv6@ietf.org>; Mon, 16 Jan 2017 17:10:25 -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=3rPHtBaLTpPCh4xhUZET3I49OkY7jj0mI1XCTtlAMuk=; b=M7QL8Z/T8OT50spzFfMKxTEbV/lKIwpO28ivkI/HxR3stSF2hekFGdB5o0qo5FiG7o 6IUVINpfStduGgqU1pfJ5LrwtHWi0oJTpLVvsafGkTJLpNT2XZFnp6wPf4rE5PSLtRhG oxvKI7bp7HwcFZc9h6fUHWieW8Yso20J5mANuHlgyRntxPEbsryXPBpCkKoQeBXoP8vY VgyqYHytDe2H7suCyJe3ZZ5S5sxlNwBzdSLPG+k61z8S8aLcpzoPRDZwz1MyXG8mSTzE z5j+lhobEpNyjwNqHWvOB5lJDu3JeGiAOC0Enw51STW26ygG8BsvOUXrnG3iHg5tlo67 4FLw==
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=3rPHtBaLTpPCh4xhUZET3I49OkY7jj0mI1XCTtlAMuk=; b=lgX5HZB3sIdFoKO4Ht712YifhPzPyOsY1mzlsWG34D5WTc7650gooYxtDa5kLKb3wm Tj/p2NCOmXuY4/Uig41wNwsnXfoMrcF2wpyEhXGdLiVE2dXblEM55xNlZv/W/9mvnZnb CHcRiKx6H0gWoCOEIoFfCiuJMNX9y9CRHUJ8AHZGFSY2dlfKF3+dnEDiwjuFksXa79i0 SWNdRy+0YyvbAo4BM1FBqlSwdXoM93IycXTNFb3AiWYOBy+9hXaRHejZQXuJ0GrNKLaM s3dGRBI+PYSEvnz0FZEElJ0Xeolx4//iGuZowi6rn70PMhPkE8qnMsQ8lFg+WDYuMUjd uHVw==
X-Gm-Message-State: AIkVDXL32X6ouGcO8DtD3O7cW5n5dG2D/HVj+He33Ue626O4S7NvE18JTVNHDqhNWz5UuJ6Y57apACtbupMZVt5j
X-Received: by 10.31.170.15 with SMTP id t15mr2427395vke.6.1484615424553; Mon, 16 Jan 2017 17:10:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 17:10:03 -0800 (PST)
In-Reply-To: <94dffda9-0a88-cfa1-6281-5d788a7ca121@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> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <CAC8QAccN_=x9sTgTM71XFSYfUmSyaMHw_tFEw2QSr5iwi2wcGw@mail.gmail.com> <94dffda9-0a88-cfa1-6281-5d788a7ca121@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 17 Jan 2017 10:10:03 +0900
Message-ID: <CAKD1Yr1QTbLsbzxwy4-MCWeAxr0rRvDe5v-6DbA9aYaK48BaZw@mail.gmail.com>
Subject: Re: IID length text
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=001a11432250027b0305463ff701
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zcmW1glTTW0Tt89CoYk5VsuUSjM>
Cc: 6man <ipv6@ietf.org>, Alexandre Petrescu <alexandru.petrescu@gmail.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: Tue, 17 Jan 2017 01:10:27 -0000

Yep. It's an arbitrary choice, just like the choice to make IPv6 addresses
128 bits long, or the choice to make the header 40 bytes long. That doesn't
mean we should change it.

On Tue, Jan 17, 2017 at 7:23 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 17/01/2017 09:42, Behcet Sarikaya wrote:
> > On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
> > <alexandru.petrescu@gmail.com> wrote:
> >> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit :
> >>>
> >>> A modest suggestion:
> >>>
> >>> OLD
> >>>    For all unicast addresses, except those that start with the binary
> >>>    value 000, Interface IDs are required to be 64 bits long.
> Background
> >>>    on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
> >>>
> >>> NEW
> >>>    IPv6 routing is based on prefixes of any valid length up to 128
> >>> [BCP198].
> >>>    For example, [RFC6164] standardises 127 bit  prefixes on
> point-to-point
> >>>    links. However, consistent use of Stateless Address
> Autoconfiguration
> >>>    (SLAAC)[RFC4862] requires that all interfaces on a link use the same
> >>> length
> >>>    of Interface ID. In practice, this means that to guarantee
> >>> interoperability
> >>>    of SLAAC, a fixed length of Interface ID is necessary. For all
> >>> currently
> >>>    allocated unicast addresses, except those that start with the binary
> >>>    value 000, that length is 64 bits. Note that this value is an
> arbitrary
> >>>    choice and might be changed for some future allocation of unicast
> >>> address
> >>>    space. Background on the 64 bit boundary in IPv6 addresses can be
> found
> >>>    in [RFC7421].
> >>
> >>
> >> I agree with the change suggestion.  The new text and references are
> enough
> >> motivation to clarify that that 64bit limit is an arbitrary choice and
> might
> >> change in the future.
> >>
> >
> > 3GPP assigns 64 bit prefixes to each UE.
> > Extended Unique Identifiers defined are EUI-48 and EUI-64.
> > I don't think 64 bit limit is that arbitrary?
>
> It's a parameter, which we happened to set initially to 48
> and then changed to 64 because of FireWire. I don't know
> why 3GPP chose the same value. But indeed we (the IETF) chose
> it because of our now old-fashioned decision to copy Novell
> Netware by embedding layer 2 addresses in layer 3. A bad
> choice, as it turned out.
>
> The first two definitions of "arbitrary" in Merriam-Webster seem
> to fit, especially the second.
>
> "existing or coming about seemingly at random or by chance
> or as a capricious and unreasonable act of will"
> "based on or determined by individual preference or convenience
> rather than by necessity or the intrinsic nature of something"
>
> Regards
>     Brian
>
> >
> > Behcet
> >
> >> Alex
> >>
> >>>
> >>> Regards
> >>>    Brian
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> > .
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>