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

Mark Smith <> Tue, 21 February 2017 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67187129C95; Tue, 21 Feb 2017 11:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Status: No, score=-1.199 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 6QroFR528ZvU; Tue, 21 Feb 2017 11:44:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A4CE129C8B; Tue, 21 Feb 2017 11:44:28 -0800 (PST)
Received: by with SMTP id k127so85717232vke.0; Tue, 21 Feb 2017 11:44:28 -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:content-transfer-encoding; bh=KEtq3N51UwbEddTR3DiW3d26tEkSw5QK89XvhvZM8hA=; b=G0eKiMsgNCwkVJe2O2G0D9/AonVynBWVckibgK28ZbMZfs2g2WyW1kwsQq4k1W1WM9 CZOtUMwSzcXzikLmkD9sJ5Y28e04lREJ5JPPHbgJNtyLId6u9kUBxjK/ct8Q7a56zPRu NzsubkThsKYiTKAdXmm+E7m81e/Y+jMAbRgMfheS0nsDx+0niGZkbLKZR6GXFA4Sr+UR f0kBphZoPTUhEACJ+GIWse03fRqvR2l4pzPOSFb9HJokeaKFbxv5q67bWo0Nq+/TJAs8 h1SOlct5IcNuSTWTdUn407NCTboyKCzW6SdvFwzXjpufFvuhs331jK0xYv3aFBBwUPUi A/Iw==
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:content-transfer-encoding; bh=KEtq3N51UwbEddTR3DiW3d26tEkSw5QK89XvhvZM8hA=; b=N/PBGcAj9rIHsMuVXU5sMOKlodiwQTUCUlat0SNEla3JJikXFNRUeVGufM/FLJo5M8 /Htjf3ZYYWZzA4xyysy0NXmFkbXJkrw68woIA3xWI3BJTrtQO05wlqwmfbG9D9BylcoO eE3ObfO4XVyNlE9VaIOf18p1DuAvKSqoUJQq1zKftlH/lJRWN0oXOo3Uvfhc01qYBF1m X6o4W9TjoRgnPEjtLkQBgUA+TewvXEsFwWmSY/KfsgBlSRUdAlS8/S8g/dxdLsI6m70S ZYVKO9UU+3HX9hCjeQFny3uUcTXdOXgP09ixLL+h5FLeUdFif+0pklKz8kA2sjo0PDhz OLAg==
X-Gm-Message-State: AMke39lEqzZVGVwEdj8ATGscTki6g3xkJx8m7XRXio+7yfHLyN8S6VB3ieIkB6cZus4Yxam/X3uFjwmbm9PAIg==
X-Received: by with SMTP id b184mr12841726vka.156.1487706267231; Tue, 21 Feb 2017 11:44:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Feb 2017 11:43:56 -0800 (PST)
In-Reply-To: <20170221172739.GT84656@Vurt.local>
References: <> <> <> <> <> <> <> <> <20170220235734.GA84656@Vurt.local> <> <20170221172739.GT84656@Vurt.local>
From: Mark Smith <>
Date: Wed, 22 Feb 2017 06:43:56 +1100
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Job Snijders <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Tue, 21 Feb 2017 19:44:29 -0000

On 22 February 2017 at 04:27, Job Snijders <> wrote:
> On Tue, Feb 21, 2017 at 09:49:32AM +0900, Lorenzo Colitti wrote:
>> On Tue, Feb 21, 2017 at 8:57 AM, Job Snijders <> wrote:
>> > ps. The "Write a draft" argument is weak at best, since we are
>> > already are discussing a draft (called
>> > 'draft-ietf-6man-rfc4291bis-07.txt'), which is in IETF Last call,
>> > which means it is in a place to discuss the contents of that draft.
>> > No reason to kick the can down the road.
>> I'm sorry, but that's really how it is. The text you dislike has been
>> the standard for almost 20 years, and is it inappropriate to change it
>> in the context of reclassifying this document from draft standard to
>> Internet standard.
> Or, perhaps it is inappropiate for the -bis document to target "Internet
> Standard" classification at this moment? ¯\_(ツ)_/¯
> Especially when solidifying recommendations in an architecture Internet
> Standard-to-be, the utmost care should be taken to verify whether the
> paper reality (RFCs) and operational reality (what people do, for
> $reasons) are aligned.

Flexibility isn't cheaper, it is more operationally expensive, because
it creates opportunity for complexity and errors.

A very simple example to demonstrate the additional cost of flexibility.

You showed the the distribution of prefix lengths in an AS. That may
have taken say 5 minutes to assemble and calculate? If all your prefix
lengths were /64s, you could have saved 5 minutes because you would
know the single value.

Multiply that sort of example 5 minutes over the many times you deal
with the complexity and errors that will occur when having a range of
prefix lengths, and that will add up to a significant amount of time.
It was an unavoidable cost in IPv4 because it was necessary to stretch
the usable life of IPv4's 32 bits of address space. It is an avoidable
cost in IPv6.

IPv4 too started out with a fixed or well known boundary between the
network portion and the host portion.


"   Addresses are fixed length of four octets (32 bits).  An address
    begins with a one octet network number, followed by a three octet
    local address.  This three octet field is called the "rest" field."

I advocate for /48s for all customers over a mix of /56s and /48s for
the same reason. The cost of managing the different prefix lengths and
resolving errors when the incorrect size prefix is assigned to a
customer are significant compared to the savings in RIR fees, and
perhaps may eliminate all those savings. When there is a single value
or size, there is no ambiguity and no opportunity for error.

I think many network engineers (and many technical people in general)
consider flexibility to be a a desirable property because they think
it means they'll be able to adapt to any future requirement without
any significant constraints. It's an understandable view (which I used
to have), however, I don't think they often consider the cost that
flexibility creates. I've also haven't seen that flexibility pay off
as much as it is supposed to.

> In those years sufficient data has been collected to conclude that /64
> is not the "be all and end all".

Alternatively, it could show that people are applying IPv4 practices
they're familiar with to IPv6, even when it isn't necessary. They're
missing out on operational savings from simplicity.