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

Lorenzo Colitti <> Thu, 23 February 2017 04:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A53F3129569 for <>; Wed, 22 Feb 2017 20:13:52 -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 oQ-llDQpX2F5 for <>; Wed, 22 Feb 2017 20:13:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE300129538 for <>; Wed, 22 Feb 2017 20:13:50 -0800 (PST)
Received: by with SMTP id x75so13669705vke.2 for <>; Wed, 22 Feb 2017 20:13:50 -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=h18CdDaMcraCcH0aW8ri4yiFf1OvNdYENLqKcMXz1bA=; b=P0WRW41p3bdzbMfsS1RWEf3nM3xceFLY3Bjld6Z0WEYMXn+r6/bDemEHlo58kI0+zx G1z3xENxcA1/S4FemdCzQyqdixFLCfoFxzGqxb2qKTT0UzqZyEJ/isqZcltYwWK0zjgd bweUOumAfsdg0ODQE3BWP7Q/7uE8Fu0C9HcXg09aX95nwQvmFpvJBFQZTw0SLliA7gwq ORyIqzdVkdid46C8HLuNv9lMEF3/620ZuKE9DEq24Jl/HdFXDBQCL16fq1StGfn8phJF nbBbNHQGwpi5ZryYPcIhNJV32kX9wKLf+xTJpuyygT8y4V7TAN7osSpyiDrBuADdNuaw KW9A==
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=h18CdDaMcraCcH0aW8ri4yiFf1OvNdYENLqKcMXz1bA=; b=HG5RbS/F/YcRDzRYfWpqC6IR5jY8QDqwGuLbSycZIKd9CQxaNvDRaMye0D+gr5K2kj hAjYuUbVNY+pMPjLIlt70FM1Acg+brjjXsyoDMDgL55lQMtFlMaVki/3ZkMCoFpZpT4Q DF4vd41LKxavzcieH9wAzzNEhI2xp5vSK/pgdy06PM7+NY1yJCziptQQw8HbR0UG28hx jNWFXTmQ9Iwy8OedEkE76s4R3b92vj+BqZAxwW7zPArgCwrJOXl9C1w2Viu/o7BvbY/2 +XRCLIfghe7FletyWRks35UXHfLns8RvLjnQg2GXf4Q+Xbuuy9KPrROGO/xVXtkzgTxO TyEw==
X-Gm-Message-State: AMke39kjC9LtI2CD6BIaoR7YuVwbyJvA/30bIFnXoNIM7GX91HzWf6QgAnXxy0s7u24tbfCBYhjKxDETlS78oAqe
X-Received: by with SMTP id q65mr17842228vkd.83.1487823229859; Wed, 22 Feb 2017 20:13:49 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Feb 2017 20:13:29 -0800 (PST)
In-Reply-To: <>
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Thu, 23 Feb 2017 13:13:29 +0900
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Randy Bush <>
Content-Type: multipart/alternative; boundary=001a1143703a1b124d05492ad7bd
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 04:13:52 -0000

On Thu, Feb 23, 2017 at 11:11 AM, Randy Bush <> wrote:

> 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.

Please think about the arguments in RFC 7934. If some misguided operator
assigns your device exactly one IPv6 address, that hugely constrains what
the device can do and how well it does it. And I do think that users notice
when their network is flaky.

> > 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
> concrete.

Sorry, let me clarify: it is inappropriate to change that now *in this
document*. As I said elsewhere, the IETF and 6man absolutely have the
ability to change the standard, but it should follow the proper process:
write a draft, get consensus, update whatever RFC RFC 4291bis eventually
becomes. I'm not saying we need to wait a decade.

(I do also happen to think that it would be better if we waited a decade
before changing this, because we're only 5 or so years into large-scale
deployment that will hopefully last at least 3 or 4 decades. However, I
don't expect many people to agree with me on that, so I'm not trying to
make that argument here.)

> 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.

What you do in your network is your business. If it works for you - which
we know it does - I have no problem with that. What I have a problem with
is when someone tells me that OS code needs to change because some operator
thinks that "we give this network a /120 subnet makes sense because that
matches the /24 we use IPv4, and we should be free to do that".