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

Alexandre Petrescu <> Tue, 28 March 2017 12:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32C53129525 for <>; Tue, 28 Mar 2017 05:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cle6h75tcNHK for <>; Tue, 28 Mar 2017 05:47:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F19A2128BB6 for <>; Tue, 28 Mar 2017 05:47:24 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2SClMTO193831 for <>; Tue, 28 Mar 2017 14:47:22 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 9F1CD202653 for <>; Tue, 28 Mar 2017 14:47:22 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 9592F205FE1 for <>; Tue, 28 Mar 2017 14:47:22 +0200 (CEST)
Received: from [] ([]) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2SClI6Q020006 for <>; Tue, 28 Mar 2017 14:47:20 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <fd> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Tue, 28 Mar 2017 07:46:59 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Mar 2017 12:47:27 -0000

Le 28/03/2017 à 02:02, Simon Hobson a écrit :
> Alexandre Petrescu <> 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.

I did not see?

> It is customary to always write the "lowest value that fits"

I did not know it was customary?  Maybe it should be documented.

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.


But humans introduce further confusion when mandating these host bits to
be 0.

These bits are not necessarily 0 - they can be whatever.

That is a need to say 'whatever' - not necessarily '0'.

> As pointed out, might make as much sense as
> IFF you ignore this feature. Applying the mask to
> gives you non-zero host bits -

A-ha!  I did not know that.

> 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 being a valid IP address !

But there should be a way to say that is just one valid 
example, not the only one.

That is also a private address.

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

That is the need.

> 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?
- BSD code recognizes an LL address by its 10 first bits only (not by
   64): it drops an ND message if not convinced.  That is reason enough
   to visit the problem closely.
- much f2f conversation calls ULA an "fd00" and an LL an "fe80".  This
   goes very far when assigning addresses on interfaces.  Few if any
   assign an "fe81" or an "fc00", although both are correct LL and ULA

And I think it is so because of the textual representation of IPv6


> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list Administrative
> Requests:
> --------------------------------------------------------------------