Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

David Farmer <> Wed, 22 February 2017 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C14D51299C1 for <>; Wed, 22 Feb 2017 06:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Status: No, score=-3.801 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=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 534SrwbzW_Ld for <>; Wed, 22 Feb 2017 06:51:08 -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 CFF7E1299AF for <>; Wed, 22 Feb 2017 06:51:08 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 5F36FB64 for <>; Wed, 22 Feb 2017 14:51:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UCxQ2HVXfI_2 for <>; Wed, 22 Feb 2017 08:51:08 -0600 (CST)
Received: from ( []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12809B07 for <>; Wed, 22 Feb 2017 08:51:07 -0600 (CST)
Received: by with SMTP id 23so2676906vkc.1 for <>; Wed, 22 Feb 2017 06:51:07 -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=ZAaBAQwVCfJCocCodAcABV30+P1KfJHhYQHIpwc5PYc=; b=j6qZ8ydyDBD6RU2VUTWmtKod6qagzLkBLdehEQCW8GwCKHusEaQztJPdisykBXU90r Xh6CaPeYMeOIk36JSO8PYWLl2nHYclml5bx95W+Q+4v0skP0Kec9P+LRJAJj2SRulqqW pVyD9EnpD7R1yM5Lxj/Rx8AGt2LrH/ro0pQKSDwVnlBZ1AYC2wlhTpMfC/VvnlI83tW+ 4uS7h879RKDveyJWpqMzZCyloUIZsk78kbz+2zh0Dyb9ys4ih95+lLxPvAjg3WYC1ryg HJTn8X61MSFYiZzOETtKcYVx4R1nNAz9teIA+SFQZcFoL55UdcJXTFF+x2KkcvhEq/Rh GQNQ==
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=ZAaBAQwVCfJCocCodAcABV30+P1KfJHhYQHIpwc5PYc=; b=PJrIynfeo+YMsX8UP8FlSEtGRFp2J4sUE0SyuUNH8Cysk8DJUqWCkdFFq6p1uEkPtj Rq/clIAfKrD6lyJngG+j9UVLlegKOSRUBRPUsPcIpmaVEHj+7ATJUvB3K5eHbbZPj+q2 uu/Ffi7qQCbtjIf4YVUCPYNhw7IAkPiiKVo1lL05A44/B7NyHqhcgz4BpzTWqa7Uf3My MzTNWyYLk5EqMlxr3sGtZ1/ce/p8HWbWQ+SudOkfGtEihP2+eOG8Jti69x32mp6iJwbU o9oS3O+5pAkfNT9/kw8sZrx0MpGEcTwJaU9So7bsvke9A80YPFtvxKGZbfLPHPK43I81 ao7Q==
X-Gm-Message-State: AMke39k2JsAC3l6P+De3PxTCLgGUvTWbUgbcFhjfubQ/AXw3mYcbcjtl4vYTvoN23k5AJLG7BMIuKKbmpSQblag4H2YNHDUxXljR5fSP2ZxjXwsaKavCy+ZHDrCf0a9bFPuaEKRLZJsDn3c86Jk=
X-Received: by with SMTP id c188mr16441294vkg.31.1487775067434; Wed, 22 Feb 2017 06:51:07 -0800 (PST)
X-Received: by with SMTP id c188mr16441280vkg.31.1487775067183; Wed, 22 Feb 2017 06:51:07 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Feb 2017 06:51:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <>
From: David Farmer <>
Date: Wed, 22 Feb 2017 08:51:06 -0600
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Christopher Morrow <>
Content-Type: multipart/alternative; boundary=001a114dd5d062b21505491fa07e
Archived-At: <>
Cc: 6man WG <>, IETF-Discussion Discussion <>,,
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, 22 Feb 2017 14:51:11 -0000

On Tue, Feb 21, 2017 at 10:44 PM, Christopher Morrow <> wrote:
> On Tue, Feb 21, 2017 at 10:51 PM, Lorenzo Colitti <>
> wrote:
>> On Wed, Feb 22, 2017 at 12:12 PM, Christopher Morrow <
>>> wrote:
>>> But the configuration cost and management overhead is not proportional
>>>> to the hosts that are served by those interconnections, it is proportional
>>>> to the number of interconnections. A 10x100G peering interconnection that
>>>> serves X million hosts is one interface that has to be managed.
>>> isn't the dicsussion here really:
>>>   "If you want to use /64 go ahead, if you want to use /121 go for it,
>>> if you want to use SLAAC you'll get a /64 and like it"
>> Not sure. I for one wouldn't agree with that position, because I don't
>> see that /121 has enough advantages over /127 and /64 - and few enough
>> downsides for general-purpose hosts - to make it a good idea in general.
> I don't think /121 is anymore special than /127... or /64. My point was we
> don't care what prefix people use, generally, that there are cases where a
> /64 is required and that's fine, there are cases where /64 isn't and people
> can do what they want there.  It's simple enough to do SLAAC/64 on lans and
> other places.
> Requiring /64 or /127 and nothing else means when you do have to do a /120
> or something else you MAY end up fighting vendor problems because they made
> assumptions about: "only ever 64 or 127".

I have to disagree with Chis slightly, /127 and /64 are slightly special,
in that they are clearly RECOMMENDED and the others (/126 through /65)
are NOT RECOMMENDED.  The problem we have is that some people think it
isn't enough to say /64 is only RECOMMENDED and want something stronger,
the stronger option is REQUIRED, and the current and historic text says
"required".  On the other hand we have people saying REQUIRED is too
strong, because it implies that /126 through /65 are not possible to use,
which is demonstrably false.

There is no universal (Internet wide) requirement, to make the Internet
work, that all interfaces have /64 as their as their prefix.  In fact as a
host on the other side of the Internet from me, you are forbidden from
making that very assumption, you must treat my 128 IPv6 address as opaque.

Their is a local requirement that all interfaces on the same link have the
same prefix.  The easies way to achieve this is to assume a fixed prefix
everywhere, and we picked /64 for that, and built it into SLAAC.  Once we
picked it, we have also built a whole bunch of other things that depend on
that pick, many of those other things are discussed in RFC7421.

Is the operational effort to utilize other prefix lengths (/126 through
/65) justified, including the issues discussed in RFC7421?  Most of the
time, probably NO, but some times, YES it is.  Here is the crux of this
issue, some of you think it is never justified.  But tough, this simply is
not your call, and again on the other side of the Internet you are not
supposed to care anyway.

Furthermore, as currently written it is easy to misinterpret the text as
implying that a configuration of something other than /64 MUST be ignored
or overridden.  My preferred solution is to simply change "required" to
"recommended" in the current text. I'd also be ok with saying /64 is
required for SLAAC, and recommended for everything else. But, If current
"required" is kept for everything, then it needs to be clarified who the
requirement is directed at, and that there are other exceptions than just
addresses that begin with 000. I think something like the following would
would deal with the first part;

   Other than the implications for Stateless Address
   this requirement primarily constrains operators of IPv6 networks and
does not imply
   implementations of IPv6 are to ignore or override a configuration that
is in conflict with
   this requirement.

And as has been talked about, for the second part we can enumerate the
exceptions or say that there are other standards track exceptions beyond
just the addresses that begin with 000.


David Farmer     
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>