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

Erik Kline <ek@google.com> Tue, 17 January 2017 02:37 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 C9C85129434 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 18:37:18 -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 tTBuAPIhBnQK for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 18:37:17 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 B8D41129411 for <ipv6@ietf.org>; Mon, 16 Jan 2017 18:37:16 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id c85so181879048wmi.1 for <ipv6@ietf.org>; Mon, 16 Jan 2017 18:37:16 -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=TwtzmJs88HmZ/vD9vrHv7rqwShkXNepTpI+EmJG2B6o=; b=j0OqRIoOpG904pSGSaaUaTOsKXO2kPZOo/NYxRUD7s6zOQioh24oG7ic0hkm/oKyVp ZxyFP0QG67v4v56aFM0O3f7IT42Jsj+VEj+TgWxumKIglL3reOt1GaVMnvA5YA6fzu6k hUXShc3aRD4Thl63XyY1nSgLGipD4OQ0i4TrYnffsZajP7YQ/XFdIYZkI6r6mEX1p1l/ JFcWYYLMABUmdCcNMVc1JRrcRXBdgMmwrDiZzD8uyLa+xhxfifj/Xb3xkQTkPDpxThfV pOU67FBpunOTTAIGh4SkLXXZo0bhlqBlgnUFi9iT3RDouNyRuatTcxFGbe0ano+D5ELd 13wA==
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=TwtzmJs88HmZ/vD9vrHv7rqwShkXNepTpI+EmJG2B6o=; b=coi5aVFOEb/RfQxFNWgLXSMeeyKLF03jEYPaW+HQKUbvObVYpby6W1Te5ymSd5uVF7 6lB3jb8IOphF/TQRdYn17E+N7vj1WSP6qOPuCl2dJcZmFnk+CKseNwQGDqQHc77Cqkh2 jK0Vwk9QV4qiqu5ictZph5SLg1TK3I26HdCh3BkK2CpAddFmvz9KYNd188WdY5uC9W54 jDW8lmALSap8XLjmry7bpEd5nQNbZiDZztlbXHFUrHuAcVMtalG+8rkHxdfHkmzNaW3f JGX5OMA2sQmtTjKYzDXaQ8yBYu+OOoFMWJK1hqSCm6ohU/yaigZgGtDMAiQ7AsXsdgWM ns/Q==
X-Gm-Message-State: AIkVDXL4vguMVI0hII/BL9tDdQjNDZQH3AmC58VDaH5T7+gsOuK/OFqLlshczy229yDV+o6RB2peY+l7WCld1/RF
X-Received: by 10.28.37.71 with SMTP id l68mr12489775wml.74.1484620635009; Mon, 16 Jan 2017 18:37:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.21.69 with HTTP; Mon, 16 Jan 2017 18:36:54 -0800 (PST)
In-Reply-To: <CAAedzxppi5g_S05-m+B2jKMYePapPM0_wMA4XioYgwipwbKVHQ@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>
From: Erik Kline <ek@google.com>
Date: Tue, 17 Jan 2017 11:36:54 +0900
Message-ID: <CAAedzxoY6MGyvzDvUcZ44ka=5RcGwQ16fzRp29445Pa7mQYNHA@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="001a114e275c98f8a90546412d65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8nZrFyE1xzG0ZYwiJ1A3LKQzxmI>
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:37:19 -0000

On 17 January 2017 at 11:18, Erik Kline <ek@google.com> wrote:
> 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.

Actually, I think the NEW text is pretty reasonable if we could
restore the word "required" for the currently allocated unicast status
quo:

From:

   ... For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is 64 bits.

To:

   ...  For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is required to be 64 bits.

We can always produce a document that updates 4291bis for 4::/3 or
whatever we want, and the new text states so explicitly.

But I'm not convinced we should change to text that could be read to
weaken the current situation.