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

Lorenzo Colitti <lorenzo@google.com> Wed, 22 February 2017 15:22 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3310129A0B for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 07:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNJko2zwcRtb for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 07:22:22 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AB0129A0C for <ipv6@ietf.org>; Wed, 22 Feb 2017 07:22:19 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id k127so3477903vke.0 for <ipv6@ietf.org>; Wed, 22 Feb 2017 07:22:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ovAjBDctGwVM5OPLtQxwT6xz4KPyD5uLzTYROzlqzec=; b=bV6kZpsQmc1F9MYOepCpHUli2awSRwQlTsxFHdUvYfvynO4iVCIUGH9X2+6crrAxqn GOQUvdMNAt/obLq464iXvGys2FsXAQ7BocRoMaVU/H6oWNY/U01g91W/jsV+tAyJ5y3t zK3e4dih+sYznnALIFZnaSVnH59ow4X+gkHtLX8j3bR4kiefZ8dy2BLysJZZQAy4bmE6 yZnot2bUrP2n/8GChwmqu71s9CTaVC89l31aN0RU7pm4eqJeBJtrO5EkwZJ+A2fQU1L7 j7xW6/E0QJXJQDQoI/eH/Y2qvO0h18fi7KEaF+ZVOZjuCP3HIGj9C9CXshPw2aISb4df mG0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ovAjBDctGwVM5OPLtQxwT6xz4KPyD5uLzTYROzlqzec=; b=WPF+oWR+yIWaBVGnR6Mw5MqakpTpLcjWct4g1XrpG2S8R53f6S3YHHGM5a0l6fAM2c 3QB5bGL+JPdiqhz6BsH76IvEqKsDTI3uU7C/+F50A2TCKxat+KRC/E/7cSHxkzalpYqR itA9YgCLcxIOFoKnIbr/iJpMbHuR879Aqdn/cxB+gemeKnRyS4zkRv9E7voWocYvq3at 16cS4MckA/Gfn30VKWEc+dk99tcZWdiQkT8M+QkgVETQapsjlu+LkKz8wMFCeLHvfXlD Zfx41300VnMGDnPuYaK0BQxToQ2xJUEoUIP8lloGBNO3+Gs38x6oQR74oYOLi5wKi+AW wZ3Q==
X-Gm-Message-State: AMke39nbuXaZpnAiVwskq0BMfNeelU1cmkE0AcpeA7jIRxJtCurz6T/s3/hWz3TJqKCbA7Gx1mphwMbp5xZ/jvQv
X-Received: by 10.31.142.68 with SMTP id q65mr16161253vkd.83.1487776937955; Wed, 22 Feb 2017 07:22:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Wed, 22 Feb 2017 07:21:56 -0800 (PST)
In-Reply-To: <CAN-Dau2K9nOF_NnxEX1uLkjWuNJtcM-x4xwWm=1WAoY6QAjzXg@mail.gmail.com>
References: <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org> <m2wpcqeuot.wl-randy@psg.com> <44F7BEDA-CF11-4E1E-BA6F-88794DEC1AF7@employees.org> <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <CAL9jLaY-7JqeNqotWsrQZ6JqNJ9NdzQT8Jt7Pd_YZwCpNgk6VQ@mail.gmail.com> <CAN-Dau2K9nOF_NnxEX1uLkjWuNJtcM-x4xwWm=1WAoY6QAjzXg@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 23 Feb 2017 00:21:56 +0900
Message-ID: <CAKD1Yr3LTYQjbMofphBi7Z_2zHMuK2T_YcQ7S73JSKGfSu3Zhg@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: David Farmer <farmer@umn.edu>
Content-Type: multipart/alternative; boundary=001a1143703ae4b0d40549200f60
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sqHwkLSZLIpKxR906cwA4TpWjnY>
Cc: 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2017 15:22:23 -0000

On Wed, Feb 22, 2017 at 11:51 PM, David Farmer <farmer@umn.edu>; wrote:

> There is no universal (Internet wide) requirement, to make the Internet
> work, that all interfaces have /64 as their as their prefix.
>

Where "make the Internet work" means what, exactly? I assume you don't mean
"experiences no loss in functionality" - all it takes is one implementation
that breaks when configured with a non-/64 prefix to make the statement
false.

That might seem like a specious distinction, but if you think about it more
broadly, then I think you'll agree that "work" is not black and white, and
also covers degraded functionality. In which case it's absolutely true that
moving away from /64 everywhere is going to cause some amount of loss of
functionality. The question is how much, and whether that's acceptable.


> Their is a local requirement that all interfaces on the same link have the
> same prefix.
>

Actually, there isn't. The requirement for working communication is that
all hosts are configured with a prefix length that covers all hosts on the
link (or, more narrowly, all hosts they want to talk to). It IS a
requirement in IPv4 because of the broadcast address, but it's not in IPv6.
Again, this might seem like nitpicking, but if you think about it some
more, I think you might realize that some of what is being written on this
thread is based on unstated assumptions that are not necessarily correct,
and in many cases based only on IPv4 practices where they were actually
necessary for reasons that are no longer applicable in IPv6.


> Is the operational effort to utilize other prefix lengths (/126 through
> /65) justified, including the issues discussed in RFC7421?  Most of the
> time, probably NO, but some times, YES it is.  Here is the crux of this
> issue, some of you think it is never justified.
>

I think this is where the disconnect lies. As a host OS developer and app
developer, my work is not impacted by what you, Job, or Chris, individually
do in your networks. My work is impacted by the minimum common denominator,
because that is what constrains the code I need to write.

If we don't have a fixed subnet size, that minimum common denominator
quickly ends up being /128-to-the-host. I don't want to end up at /128
because it makes my code more complex and brittle and my users' experience
much more battery intensive and less reliable. (Again, see RFC 7934.)

If we do have a fixed subnet size, and the only loss is that that backbone
operators cannot use RFC 4291bis to complain if host vendors refuse to
implement configuring /117 prefixes on their links, then I truly believe
that that is a better outcome for the Internet as a whole. As you point
out, /117 already "works", anyway - at least in your definition of "works".

When I was still involved in writing its addressing plans, the backbone I
am familiar with ran on a mix of /127, link-local point to point, and
/64-to-the-rack with some operational measures to defend against ND cache
exhaustion attacks. I never found the lack of /117 prefix lengths to be a
limitation.