Re: Updated IID length text

Alexandre Petrescu <> Thu, 19 January 2017 09:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F73B129435 for <>; Thu, 19 Jan 2017 01:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AskVVVyMlwYo for <>; Thu, 19 Jan 2017 01:26:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14097129434 for <>; Thu, 19 Jan 2017 01:26:20 -0800 (PST)
Received: by with SMTP id h65so4561276lfi.3 for <>; Thu, 19 Jan 2017 01:26:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=pbcH97dj0CTcUENZ0VOBEjW4WCJbV/edE0tnk51+g9Y=; b=vKmwW0RtMit7J4EedlFW9FPWZqmaOp1VBEEoDvJ113R1Ee2BJgjit/+7sJkq9GEjBq SWF/21C6ZEIUto2rEiFHQG7nPiicxsEhRMViM1Vgd9caTqEiAoON0lb44v7M9nI49Gaj VvcnJwdHx2hAsTFmwwcc2mRKbAeJK955C8vmZFGujiw9R6FDiiQoiJcdE4tI63ryiFG3 FSeAOtBOnRJgMG081mbM7Nw08+5F5a119/qq8ski+wQckna3fwb1jCOXtDwaJav3uWx+ lTFRRPBOPYvKjDrF3TsbDfL+ID4D9UTGo7Ziu516fAkoSizfcn3qOBNJEArQgPaud9LH zrog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pbcH97dj0CTcUENZ0VOBEjW4WCJbV/edE0tnk51+g9Y=; b=bz29bR+D0AgBsoYdDm9K/QJQ0Tui9JEiW25esJsiDF/oHcs0U6EclXdKlkHclpZuL0 p6KNpVqY8FHjbu/CjlLUbHinCMyEYoH8eiEJ9UOcUPa9sqjnOVcqSbks08QZeGuKx8Vm pzEJzi4QYDOjL8nz6tOVzahtss2a5UvSqryXB1fnn4BjjOYV/GyuFnBtBqE63FT0DQZ+ bSR8ou05NpvWfSpvo/WyMAH3V6FbcLAQO+yxtp50TMT2WffgBvFvEBIl25XCuzbN8V2p fHVGY4OzxuzvFsb8i8FzITYmgYXJep9E+C6a6Q2Gd0xJ/szQxDqQWyWkzWSKS5Y+MH4X eSoA==
X-Gm-Message-State: AIkVDXLNyNyS/8oqSme0FYqyVMAppfiWnF78VL1ZWC0SjG0BDriOX8Jf+xtzWCLWv9N+Vg==
X-Received: by with SMTP id p3mr2626916lfg.16.1484817977707; Thu, 19 Jan 2017 01:26:17 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 14sm1409586lju.16.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 01:26:16 -0800 (PST)
From: Alexandre Petrescu <>
X-Google-Original-From: Alexandre Petrescu <>
Subject: Re: Updated IID length text
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <>
Message-ID: <>
Date: Thu, 19 Jan 2017 10:26:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Thu, 19 Jan 2017 09:26:21 -0000

Le 19/01/2017 à 04:00, Lorenzo Colitti a écrit :
> On Thu, Jan 19, 2017 at 9:37 AM, Brian E Carpenter
> < <>>
> wrote:
> However, consistent use of Stateless Address Autoconfiguration
> (SLAAC)[RFC4862] requires that all interfaces on a link use the same
> length of Interface ID. To guarantee interoperability of SLAAC, a
> fixed length of Interface ID is necessary.
> I'm not a fan of this text, because it's a weak argument. A possible
>  (uninformed) response to it might be "why do we need this SLAAC
> thing anyway? I want to use /120 prefixes and DHCPv6, just like I do
> in IPv4". And really, SLAAC is only one of the reasons why we have a
> 64-bit IID. There are lots of good arguments for this in RFC7421 -
> solid arguments, about address scarcity and future flexibility, and
> so on. We should let those provide the rationale since they can give
> a much more complete picture than we can in two lines here. Since
> you cite RFC7421 just a couple of lines down, I would just strike
> this text entirely, since it looks like the text is only there to
> justify the following normative text.
> I think I'm fine with the text that precedes it ("   IPv6 routing is
>  based on prefixes of any valid length up to 128 [BCP198]. For
> example, [RFC6164] ...)" and the text that follows it.

I am fine with that part too.

I do not agree with the part that says "IIDs are required be 64bit long".

If IIDs are required to be 64bit long (even if only in the 000-prefixed
space) then the network can not grow at the edges, at least not with

The network can not grow at the edges with SLAAC because the operators
are already at this limit; they imagine no-one needs to grow beyond it.
  They also imagine that a 2^64 is enough for an end user, w/o
understanding that /64 is but one subnet (because of SLAAC).

We need the network to grow at the edge: cascading subnets at the edge.

I could agree though the RFC2464-10MbitsEthernet be IID-len 64.
Provided that document is used only on 10Mbps wired Ethernet only (not
on WiFi, etc.)  New documents for IPv6-over-WiFi,
IPv6-over-100GBEthernet, could use other that 64bit IID lengths.



> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list Administrative
> Requests:
> --------------------------------------------------------------------