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

Lorenzo Colitti <> Wed, 22 February 2017 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E3A1129A41 for <>; Wed, 22 Feb 2017 07:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0fxstGSVALh3 for <>; Wed, 22 Feb 2017 07:57:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87C16129A45 for <>; Wed, 22 Feb 2017 07:57:07 -0800 (PST)
Received: by with SMTP id g30so4475991uac.3 for <>; Wed, 22 Feb 2017 07:57:07 -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=2/tnWnIvuYT4QcpDrle9xMCLJ646fRHxwpe1Ty8TAJA=; b=vezZeEIlBZ5bXXgi7DO8MUH9u1+Pednu76w6jeFrNYnyEj/Sn026rRHStmlDYKJq6t Ku5n5hx26CgoaBr9xKk8kX2k3sy/fWlk2VETJWAknoFmWZw3DrrVeSEOu7UYvi9GBewR fGz6qWs6h2bd7c6pyjkykxI6UNFCv+f5YNpV8J2jb3vbtmll8s1zuYg2mVKcPHOtbL6v 5rcTeF/5umjfKoZhiaJzMEnMOrJpJjzN3LYgsFJDx5v6NF4LLBUls0IxddUAd3bOOfZH xHMHuuY7vFiU3pUjQHHLRjlS2dGgAunllxxqLou5HSYwOuXODtOkhRackovBcdb6Hh3g Gpzg==
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=2/tnWnIvuYT4QcpDrle9xMCLJ646fRHxwpe1Ty8TAJA=; b=byzGocESIlrQYUclF3oNVILx9BP4CKw/FaZ6CWahR3IuGSCGihwKWcYvBLrTWwNIDj 3mSDkYzQsxeXKHNIwTxvIZ3n1+AAtW99Pyh8ZqFkaRyTH1e+JXn9SgFt8PBFAiDJcKbx x8bdhzqZzcnxx3a8CT14j5U50kbZ2wgrAeiMO1Qc0jd4zEfuqPc0hDNn/TvevZz4GMsR OihAXR2KASmA05H2g8tsuGXxlOmvIfMWS2BzohIiUoGGQdUGY3EF8qrrt1G3yolO9baj XCLjv9+0sDA66B6ew4szbBwFjQhaJsXo6UrFqbLFxTBNjQzJFcliVdmbl0tdUKqq5fB9 hZCw==
X-Gm-Message-State: AMke39kq2XoT772m5Kvpqsrj5S+HMLSMrklWgL7fE5wxWQZC12w4nYULusJlKvn9DSTZ4vGBZaw63P9flXLs8i74
X-Received: by with SMTP id a4mr255664uaf.171.1487779026289; Wed, 22 Feb 2017 07:57:06 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Feb 2017 07:56:45 -0800 (PST)
In-Reply-To: <>
References: <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <>
From: Lorenzo Colitti <>
Date: Thu, 23 Feb 2017 00:56:45 +0900
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: multipart/alternative; boundary=f403045ee7785e73b70549208cc5
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: Wed, 22 Feb 2017 15:57:10 -0000

On Thu, Feb 23, 2017 at 12:31 AM, Job Snijders <> wrote:

> rfc6164 and rfc6583 are great examples that document considerations
> regarding not using a /64, it simply is not always the best fit.

RFC6583-style attacks (of which the class addressed by RFC6164 is a subset)
are low payoff and pretty easy to mitigate using very small changes to ND
implementations. You can solve most or all of the problem by using
per-interface ND queues and prioritizing existing and gleaned ND entries
over incomplete ones. You can do even better by pushing the filtering away
from the host so that you don't have to carry the packets.

Also, bear in mind that the interface ID length is *not* the same as the
prefix you route to the link. Given that you're talking about static
configuration, you can perfectly well configure all the hosts with /64
prefixes, but give them addresses that are all in a given /120 and then
route only the /120 to that link. That will also avoid all the attacks.

It also makes configuration much simpler, because you don't have to touch
any of the hosts when you run out of the /120: just increase the /120 to a
/119 on the router and move up from ::ff to ::100. That is 100% supported
by the current text of RFC4291bis, which requires that the router forward
packets to the /120.

This trick doesn't work in IPv4, so it will take a bit of getting used to
for people who only know IPv4, but I doubt that's the common case in NTT.

As such, I am confident to state that almost every deployed backbone
> uses a mixture of /64, /127, /126 and perhaps other lengths.


> There is public data that suggests that the backbone you are familiar
> with might be connected to a public internet exchange which uses a /112
> as peering lan prefix.

For the record, I don't dispute either of those.

> Also, backbone networks are a tiny percentage of the links on the planet.
> I certainly will not deny that fact. Are you familiar with the concept
> of the McNamara fallacy?

I wasn't. But that fallacy would apply to your arguments just as well as to
mine. You're the one that brought numbers to the thread first.