Re: Review of draft-ietf-6man-rfc4291bis-06

Mark Smith <> Sat, 14 January 2017 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9793E1294D6; Fri, 13 Jan 2017 22:37:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Status: No, score=-2.198 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 KpiCwNfpQVNI; Fri, 13 Jan 2017 22:37:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B223129412; Fri, 13 Jan 2017 22:37:25 -0800 (PST)
Received: by with SMTP id x75so46689429vke.2; Fri, 13 Jan 2017 22:37:25 -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=pUT6QvioyyNww5EhWv2PJc9RZsRP1bvtGbAxNhFd3L4=; b=IvcL4rxvsCyDGtH81/4Mdf9qSqOwri6UYeQ3sPeD9zupwhRQLnI7Vj6h/PFi/2NkYT mYFuId8e8X8B3S4+B1URBh4H+hfZjGhKP/PUFk4jbgFQTCx/8Klmri+Ze54Xc0g6fPrL 0nPrLWAZEBhJqxEGMCd20bWN22vYud7E7YPC1WvsiIViXBggqoacLoWIH4Gh0yM5Ln1U tDWdytAVS/GjOmFLVScLjM3uZSajCr2JUQfWn02zAow5eFFP4HOuDlX/rIRJf4Y6NM3K kTXaIJKBfIiD2E8/b2hFCDfqrMB/Q8qgjXTWOvFp0Ght2xkupBjsjAowGtgwyXP4ceO4 K1RQ==
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=pUT6QvioyyNww5EhWv2PJc9RZsRP1bvtGbAxNhFd3L4=; b=b+v0aWKVFSLD6Qts3XpSoroTMMksNwKqpzaltk9mo0qPJiWtLFu/y3uIPesm479URE tglrDnOvvIIkXlAQKeS1y4e8+3F+Lrkw3v0fQ9A0eVf86okGGtJAW0zuSaDjKLKgRpYw 1QerW9JRjjJJADxb445q3KupEO2oh61C+Na1d6wbWp032l2zTgWfWB3oxuGQZXbugWPF 5m+aD59GJFT8QqJPtR8JZgRAlejGQLe0l1m79E/NkYFDNtC4AWu+QblgOpULbEDkPjbU jLyb5tXXYoeAzPTRnoewB5Sf4uJzoSzX0v+BB6q/z3WCUzoWDVilptHu5Uj4mzKvUTqB 9GdA==
X-Gm-Message-State: AIkVDXJqZa3/gBIYCMmFCwPy/rbfK8ElU5WPkdqmqvYWvxT0h2ewu/axgGtzhQypVQ5A7vWQhwDE5Gq2Elvinw==
X-Received: by with SMTP id d126mr11318853vkb.165.1484375844234; Fri, 13 Jan 2017 22:37:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 13 Jan 2017 22:37:23 -0800 (PST)
Received: by with HTTP; Fri, 13 Jan 2017 22:37:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <>
From: Mark Smith <>
Date: Sat, 14 Jan 2017 17:37:23 +1100
Message-ID: <>
Subject: Re: Review of draft-ietf-6man-rfc4291bis-06
To: David Farmer <>
Content-Type: multipart/alternative; boundary="001a114dd4cce8a94b0546082efe"
Archived-At: <>
Cc: 6man WG <>, IETF <>,, Bob Hinden <>,, John C Klensin <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Jan 2017 06:37:27 -0000

On 14 Jan. 2017 15:36, "David Farmer" <> wrote:

On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter <> wrote:

> ....
> Which is exactly why we have so far only delegated 1/8 of the
> IPv6 address space for global unicast allocation, leaving a *lot*
> of space for fixing our mistakes. Moving away from /64 as the
> recommended subnet size might, or might not, prove to be necessary in
> the long term future. That's why the point about routing being
> classless is fundamental. I do think we need to be a bit more
> precise on this point in 4291bis.
>     Brian

Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and
I'm fine with that, but that's not what the following says.

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421

It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an
Imperative as discussed in section 6 of RFC2119.

I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support
that and believe it to be the consensus of the IETF. Maybe even explicitly
noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support
by SLACC.  But it is not correct to say the /64 is REQUIRED.

I don't think /127s should really be recommended either.

They don't guarantee that the ping pong problem is solved, because it
depends on both ends being configured with the /127 prefix length by the
operator or operators at each end if the link. There is no protocol
requirement that both ends of a link have the same prefix and prefix
length, nor is there any protocol checking of that condition.

For example, if an ISP configures a /127 on their end of the customer's
link, but the customer just configures a default route on their end over
the link, it is a legitimate configuration by the protocols, Internet
access will work (so the customer might assume the link is configured
correctly), and yet the link is vulnerable to a ping pong attach despite it
"having" a /127 prefix.

So it is a mitigation, however it relies on the operator or operators being
disciplined about the configuration, and comes at the cost of other things
that may be useful if a 64 bit IID was available e.g. protect against
discovery of link addresses via unsolicited inbound probing if the IIDs are
random (which may include static configuration of an offline generated
random 64 bit IID).


I also believe RFC7608 supports this conclusion.


David Farmer     
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>

IETF IPv6 working group mailing list
Administrative Requests: