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

Lorenzo Colitti <> Tue, 17 January 2017 04:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58027129A30 for <>; Mon, 16 Jan 2017 20:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Status: No, score=-5.899 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=-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 uLr3p36LtKRZ for <>; Mon, 16 Jan 2017 20:52:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A202129A2F for <>; Mon, 16 Jan 2017 20:52:28 -0800 (PST)
Received: by with SMTP id r136so85701243vke.1 for <>; Mon, 16 Jan 2017 20:52:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nW+OFa7mt63TUIE6LCa0Mc7XZgXRqaCbmrYdgqF2V8o=; b=JBH6h4lon4kuBEO8GmXRLOUP6pt+f4H5XqBSoX0+YXNx4aFay5gB307JY4rPCVEG5h v9RzuZlDQn/EeJXJKCxxX+4LMJLD00BD8qtjY9uOfix15Nms9gRVSvo1j6SjZCfEEcN4 W2v1j+X/2oGT9WQHKxJOrea+O+MPSCMVi9RdedVjZCFbEp+HPla2jeHVeeg8RR8zi2De lMYaegn7BFYVmkQawht9nu6mmHrwsolzDVn+ZromiJTqlX03PzQa6OPAI5WgsS9WAIro ovHLu0ldOpAKe/UQdpnktk8dEoQ9SHfFajdQX2OJJtDOmpgVQc3ndiqn+kZXG2ZUaB4l EikQ==
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=nW+OFa7mt63TUIE6LCa0Mc7XZgXRqaCbmrYdgqF2V8o=; b=qhU3IDVFgu2TCELl8ebG6HsYyaO/xgK6ovAMEbRX9r7RjJ1IQ40w7bX7aH/PnJRe4Y AkaNVu+VdSs24lOqSUIRx60w6+ej3W1FEZl+sHKOU6XbzTWH/M7Z9ERzqfs2ibnwGLKf aXIqAtauaSPAeIZ5NpcGcvuTk7WIjmJjJpSk0dBp+K0LdQnEzbSiaEhbKfyuGzRLsns1 gaI0WmTZ0YbnRW4IU49iLrAumj6XmCKh3y5JM8CC4c5ccnxELHdgAlS/OTemcq5xAlbN BU0Escvd3fFPxeGgEeTq/HD7Jq5EzU2AF3AVisp0BCqufEaL/fxcRBza2STr5+j58AC1 gSgQ==
X-Gm-Message-State: AIkVDXL+MaXV4oSZ1YjH4vbI9riGaQ918vhQPonmboNDqBI3eljOEv1GMavzJLnfhfK0+j/UpK/sI/9CwRy2XQVX
X-Received: by with SMTP id m1mr18004683vkb.83.1484628747441; Mon, 16 Jan 2017 20:52:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Jan 2017 20:52:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Tue, 17 Jan 2017 13:52:06 +0900
Message-ID: <>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: David Farmer <>
Content-Type: multipart/alternative; boundary=001a114e53641dad8905464311a5
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 04:52:30 -0000

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.

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.

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