Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Lorenzo Colitti <> Fri, 24 February 2017 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EB7E12940B for <>; Thu, 23 Feb 2017 16:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qRJ4JgeXM7zD for <>; Thu, 23 Feb 2017 16:46:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB6081293DA for <>; Thu, 23 Feb 2017 16:46:45 -0800 (PST)
Received: by with SMTP id x75so4445572vke.2 for <>; Thu, 23 Feb 2017 16:46: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=87gvIgixfuXpx/4xsqiFF0kzzPjBdadDd1JfHq3hIbM=; b=UsXaP3fqvWYx+hk7algfP+SDPFNs1WzgRF+FqQif/QbToEuveIvn7vV+Gi0N48rdrb GDeFmO0YS8+5ZjucASiCEgxSFDIpJ0/7gSwj4KutxngTFcOkY46jwlEggikEkDBtikjI Ro49WL7tyI/yfd13p2UWavAAqHzquFIZLgOn3cEPDFajCMH9EzWqsQT0vwwaAFLE2QcT i+n0KISUHERuNPDcSxYRkVg71tpX+Lz3VKnPTWHohkG2B840Fe8GR14ICadPL03FVa/C ATwwgDnFhPxkPpRvAkP7Re/i31z0kgTltbvcnZTp4QYnmRUh/yM5Xo56vQ4w05zbnyQs RLyQ==
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=87gvIgixfuXpx/4xsqiFF0kzzPjBdadDd1JfHq3hIbM=; b=QTV3dyfXhs8lyCzO5Zi6FYMzADMhmegnunPZKbaFSzmpLGmEkThPiEhLYCOQAcLlVM 3a3Z7v1UyZEiIeTynUAdQ54BrtGtQ8CkUbhxdxaHRdryBQo7ApB3a1KvMnF7m5jaRaM1 YdZv0U0sNIrbF4v6941uIh0bCGSHjJVvOD2TvwRqvu85tFHFOx8RfjwUFHSrXtVL3OM6 qZs4G9PwqKY8lvQ2Qs04sLAFa3rnPjazwoS2+sbiKD0YoAhaziLHa4iYBBBXFja7pkly 5Wd+itSRIyaeK4SpB8IsvLeEt7KXJ1Whs35nXGqxowzXgfTiA8omZud6aYzqRBfPcR+E WA7Q==
X-Gm-Message-State: AMke39kuz3vwOwZJ+AvHK8lWxNQAeKkgUGuJMR5hlSDledfjug7kSNx4mNxAo7WLq4kByTu/AC3/bfuKtoVOibMD
X-Received: by with SMTP id i188mr15665286vka.45.1487897204701; Thu, 23 Feb 2017 16:46:44 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 23 Feb 2017 16:46:24 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Fri, 24 Feb 2017 09:46:24 +0900
Message-ID: <>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Nick Hilliard <>
Content-Type: multipart/alternative; boundary=001a1142f178599c9305493c109b
Archived-At: <>
Cc: james woodyatt <>, 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: Fri, 24 Feb 2017 00:46:50 -0000

On Fri, Feb 24, 2017 at 8:38 AM, Nick Hilliard <> wrote:

> This horse bolted 20 years ago and the shed door is long rotted.
> Everyone understands that there are several situations where /64 is
> mandatory, but it's terribly silly for the IETF to pretend that anyone
> is going to pay the slightest attention to a requirement of this form.
> They won't: vendors won't and operators won't, so we need to stop
> pretending that this is a useful approach on this point.

I think you're only looking at half of the picture. Perhaps router vendors
and router operators won't pay attention to a requirement of this form, and
most haven't - though I will note that there are major router architectures
that have different performance and cost characteristics for /0-/64 and
/65-/127. (Anyone who claims that that is silly because classful addressing
is bad should think about the fact that routing is not magic, but based on
the laws of phisics, and bear in mind that routing on a >/64 prefix takes
twice the memory, and fast memory is very, very expensive.)

But even more importantly - even if router vendors and operators ignore
this requirement, host software and host implementations can rely - and, in
the 20 years since this was standardized, have been written to rely - on
this standard to provide useful functionality to their users.

If we remove the 64-bit boundary we are actually changing the balance
between the needs of network operators and host operators (a.k.a "users").
That's a big change, and it's not something we should do just because
"classful addressing is bad". I don't want a future where my ISP gives my
home network or my mobile device a /120 and I have to count myself lucky
because it's better than having a single IPv4 address.