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

Lorenzo Colitti <> Tue, 17 January 2017 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7673A1298D0 for <>; Mon, 16 Jan 2017 17:08:47 -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 eOeWivURLh0q for <>; Mon, 16 Jan 2017 17:08:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8A5312994F for <>; Mon, 16 Jan 2017 17:08:45 -0800 (PST)
Received: by with SMTP id k127so37889878vke.0 for <>; Mon, 16 Jan 2017 17:08:45 -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=bfunVc9Iw7ub2GHEzCIxISw4bhfkVI2hJSVMRoujADQ=; b=QDyO+E6g7gzm+ObA14mzDI+354RkbiDMJTq5mE9x6zr3QulifDJwMHMUc1SZmQZuPD kqJE5AJaHtb0m+Lo2KRMdpsZhDoV53R58o3bImNmnBIK+IgMrjEoPF2ft/BqCoDYIdDB lQdxOFnCav2lt9o113e1yGoiMkMDWJQgpmDml7SqVgwhmSkQpzgvmOHaUNPTM642n8aR NfjHCkJjwBALEd7NA1+NBKiCp+e7wmH2BKiWdbaRPvmokvjZoqL7/cLvT6dUprqqt9mw 88M2tcN/Geo2yC+aJiIeV20s2er1Xi/dniND0hawZ+WNLy8MlYQOT3VmmA36HsfkgrlS rllg==
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=bfunVc9Iw7ub2GHEzCIxISw4bhfkVI2hJSVMRoujADQ=; b=OKg+LJIUFZMetSfM0Lz8IpI7OFQMnYqDTaEo2sRk1sTugEiZLH+NDmcDmEKIFUWSN7 wAiyI+OsT2CE0rW1Ux3BLiAX6q+m2D5FuADhdBW6IoR1N7xxof/2389rI4cyklv7WBtV X31cxgqcAFogyYDmU2CYeCf4C47ZDllTj/zJFvoseH6c7ZRoaaMBnuNNH89Pj0cyUHOJ cZDRHMzBobrW9ciM0pjbJ9JvfFBYvJwyHXthMKB/m1me/If/B/u343b71DfQgAn/QNiM yC+6YjbMQ9wkMIoK+XXBdTVOGHdHVFTlN5zrs511JZxw2aYLJT8b0HYsir19l8UqM/xz Kl+g==
X-Gm-Message-State: AIkVDXJwejRl+gu8fAmIXGzPl9b1WFok14ptHSl3o58zhAnTTrkgY920dRk1j8QiF/j6fthW8NDbflN3Wsh2RuYx
X-Received: by with SMTP id m1mr17685637vkb.83.1484615324741; Mon, 16 Jan 2017 17:08:44 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Jan 2017 17:08:24 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Tue, 17 Jan 2017 10:08:24 +0900
Message-ID: <>
Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
To: Brian E Carpenter <>
Content-Type: multipart/alternative; boundary=001a114e53640f7ed505463ff1c4
Archived-At: <>
Cc: 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 01:08:47 -0000

On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter <> wrote:

> > what's the specific rationale for this change? Is it a bug in 4291 which
> > you're proposing that we resolve in 4291 bis? If so, what is the bug?
> The bug is that in SLAAC, the IID length is a parameter, not a constant,
> and that in routing protocols, the prefix length is a parameter, not
> a constant. The addressing architecture needs to recognise that.

There is no bug here.

What that text in 4291 says is that if you run SLAAC on a Global Unicast
address not starting with ::/3, then the length of the IID is 64. But when
running SLAAC on non-Global Unicast addresses, or Global Unicast addresses
in ::/3, then the length of the IID is not specified in RFC 4291 (and
presumably left up to the IPv6-over-foo documents).

That is why, for example, RFC 2464 has to say that on Ethernet, the
link-local address "is formed by appending the Interface Identifier [...]
to the prefix FE80::/64". It also says that the IID length is always 64
bits and SLAAC prefixes must be /64. If IPv6 all addresses were classful
and the IID length were always 64 bits there would be no need to say that.

Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform
to the addressing architecture, not the other way around. But that is not
in any way necessary to resolve a conflict between the two documents,
because there is no conflict.

> BTW: if the reason for the text is a perceived contradiction between the
> > fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all
> > bit lengths" - I don't see a contradiction.
> I suggest discussing that with Randy Bush.

While Randy's "I want to use smaller subnets than /64 because classful
addressing is stupid" is a valid position, that does not mean that there is
a contradiction between the two specifications.

So again - what is the text trying to accomplish? I don't see a bug in the
specs. Therefore, it seems to me that the proposed text is changing the
IPv6 architecture in a pretty fundamental way, and I don't think it's
reasonable to do that at the same time that we elevate it to full standard.