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

Mark Smith <markzzzsmith@gmail.com> Wed, 22 February 2017 17:42 UTC

Return-Path: <markzzzsmith@gmail.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 1E211129695; Wed, 22 Feb 2017 09:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PTqfmoz4QPJM; Wed, 22 Feb 2017 09:42:55 -0800 (PST)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 A056212968B; Wed, 22 Feb 2017 09:42:55 -0800 (PST)
Received: by mail-ua0-x236.google.com with SMTP id c32so6576963uac.1; Wed, 22 Feb 2017 09:42:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M53hEkOhNWc6dHH4UW4Xu10ECbV1XYaW5W8seA1JB7w=; b=A+0bupadL71zcckzl98fbnLcpbFemXmeCpVOhT9NW+Ortpuv5ArVpEubVGkS1gplMH /je3z7BOJdD0LRO8k5zFMVaaImBVGCz4el8NrofLeSMHEoIJdhVFMVnYCrgmefmLhsuG oYlcMRUFnaLO0jK0ikEEg4vXF2MGPQOxysisExwNwDu2pjZA6v4vwVOdDxlFvGXkLLWx agDReqiJIMMjYPSQQ2rJTfoVg92qFal+BqPw9uEmkiVHw3nNg3HkXucUZfC2WW/r985z d/77EbLrymwNKROVV2RMroNtQVu8XpRG3fk1nLMgT6sGUneep8XbtsrWkvp6q6H71R9y EA8w==
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=M53hEkOhNWc6dHH4UW4Xu10ECbV1XYaW5W8seA1JB7w=; b=r8DHZplVu0vujgCYwp56tG7ZpDStAJgBMW7JQKAjOr8/dTtU1Z1/eFFC0fjhFqSPJl HECEaKOY02cQ+Dt9Tp5rA5hMlG7TWZZRb3PUR6nBYrnmQTd3m0L0PNLedeq2fxp5TfEN h6LJBdxwFKYzVH2P/bNipTsuXfuHPR8WtcW+epipeP/d7OyGhwgQF0t3NJWnaNdrvPsp KsjSs/ZEe1OawlSW/v9mS/hkcuKW7fZifAkD4sOIFC34yHW6/kEOCGXQZ1wjHkwt8BLV 5XxhNesFiIU1vdk5yTqUgqtik/sONwWBeXpNoHhrsBJiNq7AAKkMtOPFAGJMiweuYq6q DBqg==
X-Gm-Message-State: AMke39l7p3Al9Bf14/m7peLo+P5yE+OOOswpi5ytW+O+f51KqO/sqWigcF5xpVGY+gFivJdMtuhKY8pScCOfTQ==
X-Received: by 10.176.23.89 with SMTP id k25mr14588205uaf.49.1487785374771; Wed, 22 Feb 2017 09:42:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.38.2 with HTTP; Wed, 22 Feb 2017 09:42:24 -0800 (PST)
In-Reply-To: <20170221202821.GB32367@Vurt.local>
References: <m2lgt6ed7j.wl-randy@psg.com> <4514E052-25C1-4C85-AB1D-0B53FD9DA0E1@employees.org> <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com> <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org> <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com> <ECF27195-4A6B-4AFC-8950-83876F333BD4@employees.org> <20170220235734.GA84656@Vurt.local> <CAKD1Yr3p=8b9Dmmb9GvGMq1u00xnE2ScmaF_a3FJXiteL=ZhBQ@mail.gmail.com> <20170221172739.GT84656@Vurt.local> <CAO42Z2xEqnz4=E7JDOA_FCg_RxkMuZgnBc3KuaxwY1oZryed9g@mail.gmail.com> <20170221202821.GB32367@Vurt.local>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 23 Feb 2017 04:42:24 +1100
Message-ID: <CAO42Z2yK_rZksa4xQkuW8Q_hwaitH610m6kVBmFisN7toaSoPw@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Job Snijders <job@ntt.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1POtkXbKLIEB2QG6R67AZHZlnT0>
Cc: 6man WG <ipv6@ietf.org>, 6man-chairs@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, IETF <ietf@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 17:42:57 -0000

<snip>
> > In those years sufficient data has been collected to conclude that
> > /64 is not the "be all and end all".
>
> Alternatively, it could show that people are applying IPv4 practices
> they're familiar with to IPv6, even when it isn't necessary. They're
> missing out on operational savings from simplicity.

>Have you read rfc1925 section 2.4?


My operational experience is why I value simplicity, consistency and
less variation, as I've worked on and troubleshooted networks that
have been unnecessarily complex.

I think RFC1925 2.12 is more important.


> You are grossly overstating these 'operational savings'.


I've seen 4x/24s on a router interface because renumbering hosts into
a single /22 was operationally too expensive. Those hosts also were
being left with default "class B" subnet masks because that was
allowing their broadcast based discovery to work. Fortunately their
router was performing proxy ARP which then allowed them to access
other off-link destinations within the Class B address space.

I've seen a router with 25 subnets on its interface because they were
collapsed down from many PCs acting as routers, and renumbering the
hosts into a single large enough prefix was too operationally
expensive. That also meant the router was sending two RIP packets for
each update because the limit is 25 routes in a RIP packet.

If you see those sorts of things, and have experience with other
protocols like IPX where subnets are always large enough for any
number of devices the layer 2 technology can support, you value the
simplicity of /64s everywhere, even on links with two addresses.


>Also, for the
>sake of this dialogue I'll apply Hanlon's razor and operate under the
>assumption that you are not familiar with my work environment.

>I am amazed your reaction to my sharing of real-world data is the
>equivalent of "well, i think you are doing it wrong".
>A lack of empathy
>is exhibited in that you do not wonder _why_ things are what they are.


I know quite well why IPv4 has been operated the way it has.

Your data doesn't measure motivation.

If I see a set of prefix lengths in IPv6 that vary like IPv4 ones
would, which is what your data set showed, then I think the motivation
is that IPv4 addressing methods and thinking have been applied to
IPv6.

If your mix of prefix lengths was only /64s, or only /64s and /127s,
then I think that shows an understanding of IPv6 addressing models and
intents.

A lot of IPv4's addressing models and methods are a consequence of
IPv4 never being designed to be used to build the Internet we have
today.

Here's what Vint Cerf has said about IPv4's address size and design context.

http://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

IPv4 was designed for a research network that escaped and became a
global network. IPv6 is really the first protocol designed by the IETF
to solve a global internetwork problem. Let's leave behind unnecessary
practices that have been used to extend IPv4's life, and that make
things unnecessarily complicated and more costly to operate and
troubleshoot.


Regards,
Mark.