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

Erik Kline <ek@google.com> Tue, 17 January 2017 02:19 UTC

Return-Path: <ek@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 05D2B129438 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 18:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level:
X-Spam-Status: No, score=-5.9 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_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 2e9iElC33rLl for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 18:19:03 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 8704A129411 for <ipv6@ietf.org>; Mon, 16 Jan 2017 18:19:02 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id c85so181531118wmi.1 for <ipv6@ietf.org>; Mon, 16 Jan 2017 18:19:02 -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=yWVjaQ6xvgVd/Ew5qomGcY5crZ0h6arEkweohWeQI+c=; b=eUUFrUGzKWSiCWKm/4P0PhFoRKERaA9G0LimD6pxW8wUa/OtqBdxhQBBmPZY8t+OGj ZxQweeuUqxwyisJsYuDhw+irzQKEYLOgT8RbEvR06ZiRoRfKAHpsZGX9eAhCDeAGNpiW +8nT2U/r36W144umTFNJmd81gNpfrf+prfopDBc/+go6xg03PaT0OVpb/3e7Ye9mhqdj Y2VcFfrGrAMgSXREw3m8QWJaHmGnWUSb5m/0W/ix2Hr/uyCDEKOYsnx1WjVnMFsgUXfZ vURTiBeqrAjS70lFHZMjJ9ThaXKZGfwqNUEfL9ldvkQLpGhIhgoGlsM3wZUtyD75rRTL +coA==
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=yWVjaQ6xvgVd/Ew5qomGcY5crZ0h6arEkweohWeQI+c=; b=iXOjzkKAzb/BR0JcjJcgHk2vMA3kb0x5ANwqGyVC1QQZDznXHQPsX4D3/6BvP60ccc GS1GC+egUpSV2Zqah22j/oiCClYrJa3XjFJogkQJyucEUfagbH9g66tHGp3CO5Mq/Q6x qLof/BaVAZWzK77A02knqIawEkdSygejlYXB/cujfqOqh5r9o+V25UbjMO7jZLbOg28J BgJSjEPfv9l3ER/uSDuWnSUfM/5HzvN6L7KkFFCeDitsaAwGELIPqIdlNiDdaapwRXB+ ug1OqwRCtRb3VV3LLqBmKBZZco8yL6enQULy5uOuB7ufB2Nhdo4e/iP3nunVoQ0+d4j3 oSdg==
X-Gm-Message-State: AIkVDXILSSMI7FXRl71MwHt5d3V8uts0eQ2ZoUxAyoO3eKJTVxM0pvQxCe2o3xhBejUYPfB7W5N1MSwnMA9rGnJI
X-Received: by 10.28.157.201 with SMTP id g192mr13290865wme.29.1484619540802; Mon, 16 Jan 2017 18:19:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.21.69 with HTTP; Mon, 16 Jan 2017 18:18:40 -0800 (PST)
In-Reply-To: <CAKD1Yr3wyza0_enWErMhmKKkA1ZOXPv5GG8dMT8HUQZsB5--UQ@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>
From: Erik Kline <ek@google.com>
Date: Tue, 17 Jan 2017 11:18:40 +0900
Message-ID: <CAAedzxppi5g_S05-m+B2jKMYePapPM0_wMA4XioYgwipwbKVHQ@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/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114b314c619cce054640ec7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XrevVGsqgX5NLyQmd4Y5p8ktQHA>
Cc: 6man <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 02:19:05 -0000

On 17 January 2017 at 10:08, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter
> <brian.e.carpenter@gmail.com> wrote:
>>
>> > what's the specific rationale for this change? Is it a bug in 4291 which
>> > you're proposing that we resolve in 4291 bis? If so, what is the bug?
>>
>> The bug is that in SLAAC, the IID length is a parameter, not a constant,
>> and that in routing protocols, the prefix length is a parameter, not
>> a constant. The addressing architecture needs to recognise that.
>
>
> There is no bug here.
>
> What that text in 4291 says is that if you run SLAAC on a Global Unicast
> address not starting with ::/3, then the length of the IID is 64. But when
> running SLAAC on non-Global Unicast addresses, or Global Unicast addresses
> in ::/3, then the length of the IID is not specified in RFC 4291 (and
> presumably left up to the IPv6-over-foo documents).
>
> That is why, for example, RFC 2464 has to say that on Ethernet, the
> link-local address "is formed by appending the Interface Identifier [...] to
> the prefix FE80::/64". It also says that the IID length is always 64 bits
> and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the
> IID length were always 64 bits there would be no need to say that.
>
> Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to
> the addressing architecture, not the other way around. But that is not in
> any way necessary to resolve a conflict between the two documents, because
> there is no conflict.
>
>> > BTW: if the reason for the text is a perceived contradiction between the
>> > fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all
>> > bit lengths" - I don't see a contradiction.
>>
>> I suggest discussing that with Randy Bush.
>
>
> While Randy's "I want to use smaller subnets than /64 because classful
> addressing is stupid" is a valid position, that does not mean that there is
> a contradiction between the two specifications.
>
> So again - what is the text trying to accomplish? I don't see a bug in the
> specs. Therefore, it seems to me that the proposed text is changing the IPv6
> architecture in a pretty fundamental way, and I don't think it's reasonable
> to do that at the same time that we elevate it to full standard.

I would tend to agree.