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

Job Snijders <> Fri, 03 March 2017 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB55B1294BF for <>; Fri, 3 Mar 2017 02:28:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Nrwuik2wFw0 for <>; Fri, 3 Mar 2017 02:28:11 -0800 (PST)
Received: from ( [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 860EF12943E for <>; Fri, 3 Mar 2017 02:28:11 -0800 (PST)
Received: by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <>) id 1cjkRG-000BWP-4V (; Fri, 03 Mar 2017 10:28:10 +0000
Date: Fri, 3 Mar 2017 17:27:34 +0700
From: Job Snijders <>
To: Lorenzo Colitti <>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Message-ID: <20170303102734.GW1024@Vurt.local>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <>
Cc: IETF IPv6 Mailing List <>
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, 03 Mar 2017 10:28:13 -0000

On Fri, Mar 03, 2017 at 01:49:48PM +0900, Lorenzo Colitti wrote:
> On Fri, Mar 3, 2017 at 7:21 AM, Nick Hilliard <> wrote:
> > > Let me rephrase the question. I asked for use cases for longer-than-/64
> > > prefixes and listed the ones I have seen so far:
> > >
> > >   * "I only need 3 addresses" (but not "I only need 3 addresses and
> > >     here's why I can't accept 2^64 instead of 3")
> > >   * ND exhaustion attacks
> > >
> > > Do you have additional use cases? "This is the way we've done it for 20
> > > years" is not a use case.
> >
> > Thank you for rephrasing the question in a neutral way.  Here is my answer:
> >
> >
> >
> > We will probably need to agree to disagree on it.
> >
> Actually, I agree with the comment itself. What I would like you to do is
> implement your comment. I think what I above call "use cases" is what your
> linked email calls "field deployment issues". If so, then my question
> becomes: can you provide concrete examples of said field deployment issues?
> What can't you do if all your subnets are fixed to /64?
> If we don't have concrete examples, all we have is "some operators say
> fixed /64 is bad". But we don't know why they say it's bad, and how bad it
> is, or even how many of those operators say it's bad. If nobody disagreed
> with the staetments being made by the operators on this thread, that would
> be fine. But because there *is* disagreement, then reaching consensus
> requires finding a balance between what those operators say is best and
> what others in this thread (mostly host developers) say is best. That
> requires concrete examples, so that we can all look at the engineering
> tradeoffs together.
> I'm going to ask again: what's the harm if all your IID lengths are /64 or
> /127? What can't you do? (Other than use IPv6-translatable addresses, which
> we should have an exception for.) You're free not to answer that question
> at all, or to answer it with more general statements around operator
> feedback being important to standards development, as you have so far, but
> if you don't answer it with specific examples, I don't expect that you'll
> be able to convince the other side of the debate any more than you have so
> far.

I am surprised you say stuff like "If we don't have concrete examples" -
i shared actual data with the group. Is there a communication breakdown?

/127 doesnt work with all equipment, /64 might leave one or both parties
open to nd cache attacks, /126 works most of the time (hence 52% of NTTs
interfaces are configured with /126), /124 or /120 is useful when you
have more than two bgp speakers in a single layer-2 segment, etc.

You've argued that you can mitigate nd cache issues, by applying
non-trivial mechanisms, some of which are more theoretical then
practical. Operators have chosen to entirely eliminate any risk of cache
exhaustion issues by making linknets smaller.

If I have a hammer, a nail, and a piece of wood; why would I use QoS or
routing tricks?

What I would've expected from IETF crowd is appreciation for continuing
to deploy IPv6 in face of all the troubles we've seen over the years,
instead we're being told "U R NUMBERING WRONG!!" and see absolute
dismissal for current operational practices and recognition why the
state of affairs is what it is.

It is upsetting that this information needs to be repeated over and over
again. Why are you not listening? The last decennia has already proven
that flexibility is a necessity to operate the networks.

The dogs bark, but the caravan goes on.