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

Simon Hobson <linux@thehobsons.co.uk> Tue, 28 March 2017 13:20 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 3F799129539 for <ipv6@ietfa.amsl.com>; Tue, 28 Mar 2017 06:20:16 -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 8KtKYZi_HLMb for <ipv6@ietfa.amsl.com>; Tue, 28 Mar 2017 06:20:13 -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 6ED34129680 for <ipv6@ietf.org>; Tue, 28 Mar 2017 06:20:12 -0700 (PDT)
X-Quarantine-ID: <6V-9beGwcH_8>
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.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 070041BC37 for <ipv6@ietf.org>; Tue, 28 Mar 2017 13:20:23 +0000 (UTC)
Content-Type: text/plain; charset=windows-1252
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: <1b6154d2-14a7-0d85-7a81-18a5367c0330@gmail.com>
Date: Tue, 28 Mar 2017 14:19:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <33465746-86AA-4F1E-974F-63208A6928AA@thehobsons.co.uk>
References: <20170223134026.GI5069@gir.theapt.org> <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> <E162D74A-7A40-4266-921B-DA55998563BD@thehobsons.co.uk> <1b6154d2-14a7-0d85-7a81-18a5367c03 30@gmail.com>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IezVenNUAEXxUAsQeLoMDNs0dqo>
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 13:20:16 -0000

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

>> It is customary to always write the "lowest value that fits"
> 
> I did not know it was customary?  Maybe it should be documented.

It probably is somewhere - but I'm not a walking encyclopaedia of RFCs 1

> As opposed to IPv4 decimal notation, in IPv6 hexa it's very difficult to
> compare visually two IPv6 addresses, and tell which is lower value.
> 
>> - 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
> 
> Well, makes sense.
> 
> But from this to say that LL addresses are _only_ those that start with
> fe80 there is a long way.
> 
>> 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.
> 
> Ok.
> 
> But humans introduce further confusion when mandating these host bits to
> be 0.
> 
> These bits are not necessarily 0 - they can be whatever.

It depends on the context. If you are talking about a HOST address, then clearly the host identifier part of the address will be non-zero. If you are talking about a subnet (or prefix on IPv6 terminology) then it's non-sensical to have the host identifier non-zero.

Taking a simple example. If you talk about 192.168.0.123/24 then I'd take that as meaning the host with host identifier "123" in the subnet 192.168.0.0/24. If you used it in the context of anything other than talking about a host address then I;d take you task for not using the *network* address of 192.168.0.0/24.

>> 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 there should be a way to say that 172.16.0.0/12 is just one valid example, not the only one.
> 
> That 172.17.0.0/12 is also a private address.

172.17.0.0/12 is a HOST address, it is not a NETWORK address. As explained above, if you apply the right operations, it comes down to being HOST 1.0.0 in NETWORK 172.16.0.0/12. There is absolutely no confusion here, that's really basic IPv4 operations. Sadly a lot of people can't cope with these basics !

> Just like when one types 'ls abc*' vs typing 'ls abcd'.

Those two commands are not the same. The first is about all files starting abc (analogous to all IPs or hosts in a subnet), the second is about the one file abcd (analogous to a single IP/host in a network).

>> But to be frank, I still can't see what the proposal is about - just
>> what use case does it solve ?
> 
> Well, the discussion is issued from the following observations:
> - rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
>  calls it fe80::/64 - which is right?

Right, so this is really nothing about using masks, prefix notation, etc - it's purely that somewhere along the line there's been an inconsistency in definition. One definition says one thing, another says something else.
By one definition, fe81::<some 64 bit ID> is a link local address, while by another definition it isn't.
I would suggest that the way to deal with that is to discuss which is correct and have one or both RFCs updated so they say the same thing. Unless there's something in the context that makes them both right.
Given that there are implementations "in the wild" relying on fe80::<something>/64, it might be hard to settle on the wider ranging definition and accept that the rest of fe80::/10 is effectively lost to other uses - having been lost in the gap between the definitions.