Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

Lorenzo Colitti <lorenzo@google.com> Mon, 20 February 2017 01:13 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 5C7AF129606 for <ipv6@ietfa.amsl.com>; Sun, 19 Feb 2017 17:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 A9mJ7Qw4ytBB for <ipv6@ietfa.amsl.com>; Sun, 19 Feb 2017 17:13:55 -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 B64FB129457 for <ipv6@ietf.org>; Sun, 19 Feb 2017 17:13:55 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id x75so54089466vke.2 for <ipv6@ietf.org>; Sun, 19 Feb 2017 17:13:55 -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=OyMeamIKrV/Xss1qvVXFpV3uiDax6e1EwinxQlXBe3U=; b=gNxIPnlArvyCCrEZW9v5/rsP0vpJcokAchAIHxCkQP1uIRgksYy4JQpv3+6fW6Cyaq Kh1/JEpXnbrbTfMQcViO/G1strYWyZSu0a9H6cwMFSGXMVrMzuddJj/q/tn8K/FnCeNP A0IKXg9OuJfpIEWhFs/jQlMRSVUoGtdf3zwFlKZYGVE3dmva6Y3BQK/zI+OpPxjn+lrx Lj55duTlOf5yuEvPDuqNmPkYnmZOWYCoth50evzi5cnKW7DMe49hCuAq00suhtpuV5lh CV8cQV8O93sDPTDEZ87xm5sMBg+6B0axDgiqKl7e7p4D3Bl46Gbt0nGgNtztJTBz5749 fZPw==
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=OyMeamIKrV/Xss1qvVXFpV3uiDax6e1EwinxQlXBe3U=; b=IaAfYxz3f1jFEI/oeOl4b9aBwe8XABa+VnjvxzJI3nrokLkoJjs+WkIbcXgwCqVD6I +MWWGOlezSsVAw4NbesYlfC5tbzv11MXYCsq3F7GT8mATzUw/ZgoXWgZZibsiu6SU4Sc jOi27lk7dEOswFkz/PKPgJAFfL8rbEl65HtIbFKPEU6wT6GbhxkFayddRIb3yOXVdij+ HTFgKho2PNMZrDeb0tlP3UpCEYXBSv7gMlPiKIXlYrhc01tbOQzIRiAm0oA0AeWkKJwy ct4wEHOYbea79+3BagW/Iric9D+qN4RexRPwODTr89Ikvtie/zf/MZnJ5ougdw2I1Jeo TPww==
X-Gm-Message-State: AMke39npoJuLEKJUwsjr0vQKxXYR+KaVhsWDeCWubfnpZ/NqNv0rNWKbATUtsp9/J5+EMIsJYwZEvfGAU2enKzP5
X-Received: by 10.31.248.193 with SMTP id w184mr9511580vkh.10.1487553234534; Sun, 19 Feb 2017 17:13:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Sun, 19 Feb 2017 17:13:33 -0800 (PST)
In-Reply-To: <CAN-Dau3gXG8O2Fx_rdBJD8cokKMDJFN7D_MDsmzORmpgDUfVPQ@mail.gmail.com>
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org> <CAN-Dau3gXG8O2Fx_rdBJD8cokKMDJFN7D_MDsmzORmpgDUfVPQ@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 20 Feb 2017 10:13:33 +0900
Message-ID: <CAKD1Yr2bSc6yDmOh=mJ-Z3YvemNfUEbPKGzLs-MxP7RQzqBgZA@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: David Farmer <farmer@umn.edu>
Content-Type: multipart/alternative; boundary=94eb2c14bd2a2158cb0548ebfa11
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OK_G1hUoRC5t6_OZfw1US5l7d1o>
Cc: 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@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: Mon, 20 Feb 2017 01:13:57 -0000

On Sat, Feb 18, 2017 at 2:32 AM, David Farmer <farmer@umn.edu>; wrote:

> The proposed text appears to make the Interface-ID length an operational
>> choice.
>> How is that _not_ changing the 64 bit boundary?
>>
>
> This has always been an operational choice.  You are mis-interrupting the
> intent of the 64 bit boundary, you seem to be saying it intends to specify
> the IID length for every interface on the Internet. If that was the intent,
> then RA's would never have needed a prefix length, nor would you need to
> specify a prefix length when manually configuring an interface.  If this
> requirement intended to specify the IID length of every interface on the
> Internet, then the requirement would have been sufficient by itself, we
> would have been done at that point. However, the fact that RAs have prefix
> lengths, and we specify a prefix length when manually configuring an
> interface, belies the argument that this was not intended to be an
> operational choice from the beginning.
>
> So, for other than SLAAC, the 64 bit boundary has only ever been in
> operational guidance, there are serious consequences to not following the
> IETF's operational guidance in this regard, this is discussed in
> [RFC7421].  However, it is an operational choice to follow that guidance or
> not. Interpreting this requirement as ever taking away that operational
> choice, shows this as a false imperative.
>

The fact that (most) glonal unicast IIDs are 64 bits is not an operational
choice, it is defined by the standards. The reason that it is a parameter
in various parts of the protocol is *not* that it is an operational choice;
the reason is to leave open the protocol to a future change in the
standards and future address allocations where IIDs are not required to be
64 bits long.