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

Mark Smith <> Sun, 26 February 2017 05:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADA28129460 for <>; Sat, 25 Feb 2017 21:25:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, SPF_PASS=-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 7WHnuLYeNE7V for <>; Sat, 25 Feb 2017 21:25:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C433E1295F8 for <>; Sat, 25 Feb 2017 21:25:14 -0800 (PST)
Received: by with SMTP id f54so1471153uaa.1 for <>; Sat, 25 Feb 2017 21:25:14 -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=JpkGJ922JoNBVAq7y0nzrykIqoZEJwo641WorS7eA3w=; b=r1isRc8HjpgUUoBUeJ6Uv/T1J+5ixwFSFmOPu0exCOs88pnbMF5EIH8ywrkj3EY6YR j2A+PGs+q4ZIJoQFuF7e036xTwsMzWWXt9+BVVDUAkYVrOK5rW7CtOng85f3Kc/OuMVD dI5bzmtgbjaoAASwDr2yBU3/xq+sH6wcTGdhcR8qFJkodbKnPSzCsKHpTYHsFLKcS12V xeNgccSH0pLOIDNsHmeJEC8FbU2o6bo/mIaL9NbjP3eLYKyK+qOv/PvuPCb8ShAf5jpr 59bz+9OjYkJE/FyW/m7CN5W8L5fGAIWwWbgXukQ3368IDs0z10aKT0S2bIJk0YpuLL/l nxeA==
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=JpkGJ922JoNBVAq7y0nzrykIqoZEJwo641WorS7eA3w=; b=H2dGa4OtDAbdDHTRlAPrJIHOs/jd8HJHkbR4Fg+URqGQM5+Vtwzr4gzeuGqxsJ4p5r kUU1v1Sjo/X4Kof/vYZKAEZ1HaMv56A+xN1H4/HsXWzc0JRzoNKuQI3iyqcjLx0el4Xg eoXzsIKKzGJhUZn4Ci4qfZVcpYCU+FowPAwAjVZDkDf5pLw1q3TRHuJT7deviwB3wF7H jF4O0SzIIdCER1AXe0yPvE8GkjFUuup9H9ACQaLPP6T5ZDp1bm7k+Q8ZkW1caRUcir3b QBs3RS7f9d65sStx3fHXp5elqGCA403OVhCR3EZBgRyZQ3BhCS6+i01VShy/tZFQdxZ3 5QcQ==
X-Gm-Message-State: AMke39nIjxWL7b9qFSIQ92TO+cw3d5AqTGK/1fRalSgml/pO1MoPZ0Z5QeGBAj5mabg8GGMlblCBas2QidJW7g==
X-Received: by with SMTP id y56mr373914uay.141.1488086713800; Sat, 25 Feb 2017 21:25:13 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 25 Feb 2017 21:24:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Mark Smith <>
Date: Sun, 26 Feb 2017 16:24:43 +1100
Message-ID: <>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: David Farmer <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Alexandre Petrescu <>, 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: Sun, 26 Feb 2017 05:25:15 -0000

On 26 February 2017 at 07:40, David Farmer <> wrote:
> On Sat, Feb 25, 2017 at 1:15 PM, Brian E Carpenter
> <> wrote:

> Thinking about this a bit more; I think the non-64 lengths should be
> "OPTIONAL for host implementations of IPv6 to support", "RECOMMENDED for
> router implementations of IPv6 to support", "operational use of /127 subnet
> prefixes for point-to-point router links is RECOMMENDED",

I don't think /127s should be at a level of RECOMMENDED.

They are a way to mitigate a ND cache attack if your implementation is
vulnerable to one.

They are a way to mitigate a ICMP ping-pong attack, however that
requires the /127 prefix length to be configured on both ends of the
link, and that is not a requirement of the IPv6 protocol - there is no
requirement and no checking that all nodes attached to a link have
addresses from the prefix assigned to the link. A link with a /127 on
one end, and just a LL on the other (as could happen on links between
a service provide and a customer if there isn't configuration
discipline), is vulnerable to a ping-pong attack, yet would not be
obviously failing e.g., still deliver 100% successful Internet access
to that customer.

/127 of course prevent things that /64 can provide. For example, just
like hosts, Internet connected routers would benefit from being
protected from unsolicited inbound address scans by having a random
address within a /64 (you can't launch a TCP syn attack against a BGP
speaking router if you can't find it).

I think a RECOMMENDED and therefore default parameter is the one that
should have the greatest chance of interoperability, is the one that
is likely to provide the best security in the least secure
environment, and the one that is making the least functionality or
capability tradeoffs.

In my mind, /127s make too many tradeoffs to mitigate a couple of
attacks for which it may not be necessary or effective if
configuration is not verified as correct.

I think recommending /127s for point-to-point router links also
creates an implicit and unstated constraint that RFC8064
("Recommendation on Stable IPv6 Interface Identifiers") only applies
to hosts. If that is the actual constraint, it should have been stated
in that RFC, and ideally in the title of it.

People of course can use /127s in their own network if they choose to
and are willing to sacrifice the potential benefits to their routers
of not using /64s, because IPv6 supports it per BCP198.

I think making /127s a default recommendation for point-to-point links
is effectively saying that routers have no need for any of the
benefits hosts get from /64s, and I don't think that is the case.