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

Randy Bush <> Thu, 23 February 2017 02:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B56D129E1E; Wed, 22 Feb 2017 18:11:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0kjm4kYNC1Os; Wed, 22 Feb 2017 18:11:56 -0800 (PST)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5D83129E13; Wed, 22 Feb 2017 18:11:56 -0800 (PST)
Received: from localhost ([] by with esmtp (Exim 4.86_2) (envelope-from <>) id 1cgiss-0007Pd-1R; Thu, 23 Feb 2017 02:11:54 +0000
Date: Thu, 23 Feb 2017 09:11:50 +0700
Message-ID: <>
From: Randy Bush <>
To: Lorenzo Colitti <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
In-Reply-To: <>
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
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: Thu, 23 Feb 2017 02:11:58 -0000

> As a host developer I strongly oppose that. 

as a network operator, i strongly opposed classfulness and will hold my
breath and have a tantrum.

> It will make life easier for network operators but make life harder
> for host OS developers, host operators, and host users.

users do not notice, except when device programmers break things.  i am
a host operator, and i do not need classfulness.  slaac is nice in small
lans, and the /64 id is fine for the slaac niche.

> And it is absolutely inappropriate to change this nowin given that the /64
> boundary has been the standard for the last 20 years. 

the other week you were saying i should be patient and we could change
it in another decade from now.  now you say forever, it's cast in

well, we are breaking that concrete, have broken it for years, and it's
time 6man wakes up, smells the coffee, and gets with reality.