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

David Farmer <farmer@umn.edu> Tue, 17 January 2017 05:35 UTC

Return-Path: <farmer@umn.edu>
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 26E0B129A69 for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 21:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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=umn.edu
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 Fok7ojjV74hT for <ipv6@ietfa.amsl.com>; Mon, 16 Jan 2017 21:35:22 -0800 (PST)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5665212947B for <ipv6@ietf.org>; Mon, 16 Jan 2017 21:35:22 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id C3B8693C for <ipv6@ietf.org>; Tue, 17 Jan 2017 05:35:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4GM0OSkBV_l for <ipv6@ietf.org>; Mon, 16 Jan 2017 23:35:21 -0600 (CST)
Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 80C00812 for <ipv6@ietf.org>; Mon, 16 Jan 2017 23:35:21 -0600 (CST)
Received: by mail-vk0-f71.google.com with SMTP id k127so80353968vke.7 for <ipv6@ietf.org>; Mon, 16 Jan 2017 21:35:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zvMp/IxZ2gvb3QGhGa0bUT23d9np3jeYdEx52EsYvg4=; b=BzOvZqpt7IugjKW/pQ/7+HpKJuedfXXaNEfullI9jxK+qVlvBlGm+kUj0jdPjzJuWs ZIU9KpfWBYKVQWPUwhD7YMgmWsQFmixVDOGShDYhFIlR5G9Cw8gIBgrSVM4ScCc1MM9n pLpqPWgjZ1gU+eJoiYyYP5t+vscCdYfKwgCDO1jFtEOjvhaKnLc4ypQOldgBDJKAdVG8 JYUxZN/PNjlCKb8kV74e7qxiI8ZOlB/y8YFXnjE82NDcGv+ll6PGQMCMZUn79vb0HvwM EFj7AE1DPr2FrrlF6H4ZTDQ8gXmAlYTju5rcrNzZkYnnLZ2u4KGR/YLNsHTng5aZbwjy FlXw==
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=zvMp/IxZ2gvb3QGhGa0bUT23d9np3jeYdEx52EsYvg4=; b=K0Pd8woY4lykV1ZK8CBBBjN2FQhXYfs4xAO3fa9/XCAo51V12MO/19CZh+dzOD37Ob o2C1m4HbC8fLDQghfGkrOrOmK0hhfYvfHMEZcHWEM2+7pkOIyW1aUOqUQQfyuk08UPJr zgKFyy9gqOojdL6jt+qOEESaa99IOKIMu6E118GOOND164oSModYYdswT8OOSYfZLwjU BMgKan1TfBC+q7hkG48RJWnrt+FheM7alhfiaUuJV5q2z1Yl19rzQx1yA0848BBb7rI5 y+veL0tn+YPKpfghKUUTZKgDYcr2Rk5RJjIEA0HDGxXZ3t6bZlFXSyhog6c058DwGB3D MOLQ==
X-Gm-Message-State: AIkVDXLFxfEpcs3VFd2dxuKbt6abQO1xxwAJAmDqZwi48NgNbpRXQc12LU8pow6CV3532vPAghXGAXqBAcu5lcPyo6ASoXocyNL+uh+3yyDCCqeDPny3rSc8LMUaNgp90n6XLL638UjBT7W9E8g=
X-Received: by 10.31.114.133 with SMTP id n127mr18292326vkc.129.1484631320912; Mon, 16 Jan 2017 21:35:20 -0800 (PST)
X-Received: by 10.31.114.133 with SMTP id n127mr18292322vkc.129.1484631320724; Mon, 16 Jan 2017 21:35:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.84.15 with HTTP; Mon, 16 Jan 2017 21:35:19 -0800 (PST)
In-Reply-To: <CAKD1Yr3RpUaNKkyTPHPWWew80cyGkiT1p7vYwfejESP4tQw31A@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> <CAAedzxoY6MGyvzDvUcZ44ka=5RcGwQ16fzRp29445Pa7mQYNHA@mail.gmail.com> <CAN-Dau36r2UgXPfdcdEAJ914QqvVvjGJK+=mgE9Y2tpBiDSRig@mail.gmail.com> <CAKD1Yr3RpUaNKkyTPHPWWew80cyGkiT1p7vYwfejESP4tQw31A@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Mon, 16 Jan 2017 23:35:19 -0600
Message-ID: <CAN-Dau0OsD4RcVUN+me98g6SJ=oaAr4HoqGtP88PTbMU_-kuGQ@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/alternative; boundary=94eb2c1497b47e9a55054643aa8e
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/47iZ6eJje39E1lrGiHTEWGx16vU>
Cc: Erik Kline <ek@google.com>, 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 05:35:24 -0000

On Mon, Jan 16, 2017 at 10:52 PM, Lorenzo Colitti <lorenzo@google.com>
wrote:

> On Tue, Jan 17, 2017 at 1:32 PM, David Farmer <farmer@umn.edu> wrote:
>
>> reinserting "required" back in the phrase above just brings back the
>> conflict with section 2.4 and RFC6164, BCP198/RFC7608, because the
>> statement isn't scoped to SLACC.  64 bit IIDs are clearly the consensus
>> RECOMMENDATION, other than for point-to-point links, but saying they are
>> REQUIRED for other than SLACC is plainly false.
>>
>
> Required for what purpose? For things to work on a particular
> implementation? Or required by the standards? As far as the current
> standards are concerned, with the exception of /127, IIDs for global
> unicast addresses outside ::/0 are required to be 64 bits long, period. If
> we change that, we're making a substantive change to the standard.
>

What happens if they are not 64 bits long, do the proverbial Internet
police write a ticket?  Do I have to return my addresses to ARIN?  This
seems to be a false imperative to me.  If 64 bit IIDs are really required,
I'd like to see better motivation for this as a requirement.  I only see
motivation for this to be a recommendation, and I'm not the only one.

As for what is required for things to work on your favourite
> implementation, the list of of things that will work depends solely on your
> definition of work. For some people, things work "work" might "client
> applications can reach external servers", and the list of things that will
> work (even though it violates various standards) include numbering a
> 10000-person office with ULA and putting it behind a full-cone NAT66 that
> translates everything to one IPv6 address.
>
>
>> Manual configuration and DHCPv6 with other than 64 bit IIDs or /64
>> subnets, are in operational use in many places, this is clearly NOT
>> RECOMMENDED, but it is completely consistent with all the rest of
>> specifications of IPv6.
>>
>
> Citing the "rest of the specifications" here is not germane to the
> discussion. Using non-/64 IIDs conflicts with precisely the RFC that is
> authoritative on that topic, which is RFC 4291. Saying that it doesn't
> conflict with any other RFCs is a bit like saying that tax evasion is not
> prohibited by any other law than tax law: (in first approximation) true,
> but not really relevant.
>

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.


>   Furthermore, if the old text was correctly understood we would not have
>> needed RFC5942 and BCP198/RFC7608, therefore the old text is clearly faulty.
>>
>
> "Not clear" != "faulty". As explained before, there is no conflict between
> RFC 4291 and RFC 7608. RFC 7608 applies to forwarding, RFC 4291 applies to
> link addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can
> you clarify what you mean?
>

I never said there was a conflict between conflict between RFC5942 and
RFC4291, I was very careful about that.  I said there was a "conflict with
section 2.4 and RFC6164, BCP198/RFC7608".

I was saying that the need for RFC5942 and BCP198/RFC7608 are evidence that
the text in question is faulty[1], I think you would prefer misunderstood,
but in my opinion its more that, so I went with faulty.

[1} fault·y - adjective - working badly or unreliably because of
imperfections.

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