Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Wed, 18 January 2017 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27A541296BD for <>; Wed, 18 Jan 2017 05:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.264
X-Spam-Level: **
X-Spam-Status: No, score=2.264 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_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vx_CqUz-sg9Z for <>; Wed, 18 Jan 2017 05:08:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 805B3129467 for <>; Wed, 18 Jan 2017 05:08:24 -0800 (PST)
Received: from ([]) by with ESMTP; 18 Jan 2017 13:08:24 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 0B77AD788B; Wed, 18 Jan 2017 05:08:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=l5i8DInQF6g3tOZnrvvxUfPv+Q4=; b=reLy0Mg9M74YH7w5Zd 61reXQ6BNoxqVeBqDhPxz4s7U+xXRwhFYxoTWorki2fJfGEJ7KMADBGcXJst2k3m /+xiCJb6mNrILv2mFQ+sGAgPDsok+YhLAwkU0JtiLfWA3SvIJC9D+qP37cx7w2eu v4QiPClufFtMcp3NOpVhwZMUY=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=Jl+//z2H5MrLidIVPYWebo7KkXIjZrn1eJFKSym67+rT+sYbgIG VPXfmP/f+5+rMU9iJB68CXEpPzni8vBC+iHGHycn4jVRugp/Xq9u6jU1UOsJUdsx ijvoG0zHdNVRndivjahcn3YDfmM+sR7dq9dxEhtwH1AqO3wa/ifVerf4=
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id CB1CED788A; Wed, 18 Jan 2017 05:08:23 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 0FC7C76A5255; Wed, 18 Jan 2017 14:08:20 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
In-Reply-To: <>
Date: Wed, 18 Jan 2017 14:08:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>
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: Wed, 18 Jan 2017 13:08:25 -0000


>> I would argue that we should not make any changes to this text (apart from the eui-64 part).
> I think that the discussion on the IETF list has already shown that there is no
> consensus for the current text. I don't agree with it any more, either. It hides
> the tension between CIDR and the consistent length needed for SLAAC.
> Hence I'm still proposing that we change it. I think the median view at the moment
> is for the version that runs
>  ...  For all currently
>   allocated unicast addresses, except those that start with the binary
>   value 000, that length should be 64 bits.

The 64-bit boundary is hard to defend technically. It is for example trivial to make SLAAC deal with variable length prefixes.
Our strongest argument is probably 8+8 aka ILNP.

The other side "the CIDR argument" has no technical argument foot to stand on either. There is no technical argument why the network / routing side would require more than 64 bits.

Given that what we are left with is policy, I think it is quite harsh of you to declare that there is no consensus on the current text on the IETF list.
There are good technical arguments for why each host needs more than a single address, and if we end up in a situation similar to IPv4 where each address used has to be justified, then we have lost. There is a justified fear that allowing the 64 bit boundary to slide, we will end up in a situation similar to IPv4 addressing. E.g. charging per address.

This is where the IETF has to perform a fine balancing act. On one side ensure that the 64 bit boundary stands, at the other side ensure that all implementors do not enshrine a hard-coded boundary in their implementations.