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

Simon Hobson <linux@thehobsons.co.uk> Tue, 28 March 2017 07:02 UTC

Return-Path: <linux@thehobsons.co.uk>
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 4942F126C7B for <ipv6@ietfa.amsl.com>; Tue, 28 Mar 2017 00:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 eeyQHZfg5a9L for <ipv6@ietfa.amsl.com>; Tue, 28 Mar 2017 00:02:48 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728FB129874 for <ipv6@ietf.org>; Tue, 28 Mar 2017 00:02:42 -0700 (PDT)
X-Quarantine-ID: <5P0b75E0Q8MC>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <20[...]
Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 01AC01BC37 for <ipv6@ietf.org>; Tue, 28 Mar 2017 07:02:44 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <fdf728eb-90f5-facd-3cbe-5f3ba8cac0d1@gmail.com>
Date: Tue, 28 Mar 2017 08:02:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E162D74A-7A40-4266-921B-DA55998563BD@thehobsons.co.uk>
References: <20170223134026.GI5069@gir.theapt.org> <CAN-Dau0n6oFm538XdJOcuO1yg92BCDD3mBu5YfBVm_+g-gtcKA@mail.gmail.com> <CAL9jLaYO=uYgVfSZ0SoSe0SujJ1xgwEKE8WLzo_keJHywgXTtg@mail.gmail.com> <CAN-Dau1vJV5O_Ythp6THkAu4-YZXV82Upny1V+ybbjCVZQQX=A@mail.gmail.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <de4988be-6031-08d9-84ce-21c3fa4f9bc9@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <CAO42Z2z7v4gDk91b6Of-1sczV88m3B9kzn0MeJU_VBJ416k6Ww@mail.gmail.com> <ae35b45a-0398-840f-fc0d-1f64dd2fcc58@gmail.com> <CAJE_bqdZezDRti5LqCKnmU9QkwwhdejP22gXwk3wLKiS0mhx+Q@mail.gmail.com> <dfc8570d-fff0-39fe-a53f-db2c81c0ec8f@gmail.com> <CAJE_bqdHv0vw_kFFBZ2NE98t0nhkCR5rz8f=UOpwmvqtVjNqhg@mail.gmail.com> <d7c50847-47b4-48a7-d2c4-7b207898c84b@gmail.com> <CAJE_bqdzZ6VBCN_+FvX6Np=21PuuPCFX3mOuZ6MVQd=zj7aE5A@mail.gmail.com> <CAJE_bqfD_wkSgR1XBWSFXeVxZ+Qx+ai2qKoND89NW__m6yG2YQ@mail.gmail.com> <fd f728eb-90f5-facd-3cbe-5f3ba8cac0d1@gmail.com>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KF8j4kswJ8vI97YtbabGZzo7LFg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 28 Mar 2017 07:02:50 -0000

Alexandre Petrescu <alexandre.petrescu@gmail.com>; wrote:

> Actually one can wonder why RFC writers decided to write fe80::/10 when they could have written fe81::/10 equaly well.  Or even fe90::/10 or febf::/10.  All these designate the same 10bits - the mask 1111 1110 10.

I thought this was answered a good few messages ago. It is customary to always write the "lowest value that fits" - ie the one where all the non-prefix bits are zero.
So fe80::/10 fits - all the bits after the first 10 are zero
fe81::/10 does not fit - when you mask off the non-prefix bits you get a different value

So while in terms of maths, after doing the masking you get the same result, by not applying the "all host bits are zero" rule - you have introduced confusion for humans.

As pointed out, 172.17.0.0/12 might make as much sense as 172.16.0.0/12 IFF you ignore this feature. Applying the mask to 172.17.0.0/12 gives you non-zero host bits - hence why we don't use that.
It's all to do with consistency and avoidance of confusion. And we need as much of that as we can - I know plenty of supposedly network capable people who cannot understand the concept of 172.16.1.0/23 being a valid IP address !

But to be frank, I still can't see what the proposal is about - just what use case does it solve ?