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

David Farmer <> Tue, 17 January 2017 05:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26E0B129A69 for <>; Mon, 16 Jan 2017 21:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fok7ojjV74hT for <>; Mon, 16 Jan 2017 21:35:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5665212947B for <>; Mon, 16 Jan 2017 21:35:22 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id C3B8693C for <>; Tue, 17 Jan 2017 05:35:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z4GM0OSkBV_l for <>; Mon, 16 Jan 2017 23:35:21 -0600 (CST)
Received: from ( []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80C00812 for <>; Mon, 16 Jan 2017 23:35:21 -0600 (CST)
Received: by with SMTP id k127so80353968vke.7 for <>; Mon, 16 Jan 2017 21:35:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id n127mr18292326vkc.129.1484631320912; Mon, 16 Jan 2017 21:35:20 -0800 (PST)
X-Received: by with SMTP id n127mr18292322vkc.129.1484631320724; Mon, 16 Jan 2017 21:35:20 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Jan 2017 21:35:19 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <> <> <>
From: David Farmer <>
Date: Mon, 16 Jan 2017 23:35:19 -0600
Message-ID: <>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: Lorenzo Colitti <>
Content-Type: multipart/alternative; boundary=94eb2c1497b47e9a55054643aa8e
Archived-At: <>
Cc: Erik Kline <>, 6man <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jan 2017 05:35:24 -0000

On Mon, Jan 16, 2017 at 10:52 PM, Lorenzo Colitti <>

> On Tue, Jan 17, 2017 at 1:32 PM, David Farmer <> 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

David Farmer     
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