Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 07 March 2017 15:52 UTC

Return-Path: <alexandre.petrescu@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 2F7941295A9 for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 07:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfHzkvbotiUX for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 07:52:43 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BD712949B for <ipv6@ietf.org>; Tue, 7 Mar 2017 07:52:40 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v27FqdI0026374; Tue, 7 Mar 2017 16:52:39 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1CB3120A6FC; Tue, 7 Mar 2017 16:52:39 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1086F20A7B0; Tue, 7 Mar 2017 16:52:39 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27Fqcg2003913; Tue, 7 Mar 2017 16:52:38 +0100
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"
To: Sander Steffann <sander@steffann.nl>
References: <CAN-Dau17q_BrUuzfvB1mLDt6p5UxYikphWaHpa8VQ2L-3kx-DA@mail.gmail.com> <D6D5B476-7F21-4F49-A81D-C2A11C30ADEC@google.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <ABE47051-FBFC-460F-89B0-FFD451410F7B@google.com> <m1cjviu-0000EYC@stereo.hq.phicoh.net> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <m1ck5mu-0000GaC@stereo.hq.phicoh.net> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <m1ckxfo-0000IMC@stereo.hq.phicoh.net> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <CAOSSMjUR203+hYFBrFBrj9Xkjux3o7fYNd4y9kNyxwpLxF11ew@mail.gmail.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <CAOSSMjUP6m-L1iNhE=BxHW+7hvt4YsZgxxtVn+qmgEVS9HeStA@mail.gmail.com> <CAJE_bqfpE-NWwG12S4CXM+ZnHdHHH31-y+_+pYhuCuq2FtqZ4w@mail.gmail.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <fdc3fa b6-fdcb-f390-e6ea-d9e49edacf52@gmail.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b86627e7-3668-304f-f12e-71ad3bfd6f7a@gmail.com>
Date: Tue, 07 Mar 2017 16:52:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HYKhuxqw_Cijz1Bo5PjeRTTbex8>
Cc: ipv6@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: Tue, 07 Mar 2017 15:52:44 -0000


Le 07/03/2017 à 15:37, Sander Steffann a écrit :
> Hi,
>
>> But this is what the text says:
>>
>> RFC4862:
>>> A link-local address is formed by combining the well-known
>>> link-local prefix FE80::0
>>
>> Hold on?  Isn't that denoting an address?  Rather than a prefix?
>>
>> FE80::0 is an address, not a prefix.  Were it a prefix it should
>> have been named FE80::/plen.
>
> True, it's written as an address. However, in step 2 it says to set
> all bits to the right of the prefix to zero.

And what is a prefix?  If specifier does not know what is a prefix how
could she expect the implementer to implement it?

> However you choose to read it, you end up with
> fe80:0000:0000:0000:0000:0000:0000:0000.

And that is an address.  Do you agree?

> In step 3 the N rightmost bits of that are overwritten with the
> N-bits-long IID.

YEs, that covers the 64bit rightmost part.  But that does not say what
to put between /10 and /64.

>> I suspect the author could not write FE80::/10 because s/he was not
>> sure whether that should be FE80::/10 or FE80::/64.
>
> The ipv6-on-ethernet explicitly states that on ethernet the
> link-local prefix is fe80::/64.

YEs, but IPv6-over-Ethernet is less important than IPv6 Addressing
Architecture.  This latter says there is an FE80::/10 (and not /64).

Do you agree IPv6 Addressing Architecture says "FE80::/10"?

>> So she came up with FE80::0, ignoring that it can be understood as
>>  an address by some.
>
> Don't make assumptions.

So why did she write "prefix FE80::0".  Isnt that wrong?

Or maybe I should not ask at all?

>
>> And naturally so, because, notationally, it is not clear whether
>> FE80::0 is even allowed, from the point of view of the "::".  We
>> know the "::" can not be preceded by 0s in the same sextet
>> (notation FE80:0::/64 is forbidden).  But we dont know whether "::"
>> could be followed by hextets made of 0s (we dont know whether
>> FE80::0:0 is allowed).
>
> Of course it is allowed.

?

> fe80:: is the same as fe80:0:0:0:0:0:0:0, is the same as
> fe80:0:0::0:0 etc.

I agree fe80:: is the same as fe80:0:0:0:0:0:0:0.

However, both fe80:: and fe80:0:0:0:0:0:0:0 are addresses, not prefixes.
  A prefix should have a '/' in its notation, like fe80::/64.

Moreover, in my interpretation, the fe80::0 is a forbidden notation,
because RFC5952 titled "IPv6 text representation" says "2001:0db8::0001
is not acceptable and must be represented as 2001:db8::1".

> Where did you get the idea that some of those notations are
> forbidden? RFC 4291 only says that "The use of "::" indicates one or
> more groups of 16 bits of zeros." nothing more nothing less. It
> doesn't mandate using :: for all groups of 16-bits of zeroes, just
> "one or more".

By RFC5952 titled "IPv6 text representation" saying "2001:0db8::0001
is not acceptable and must be represented as 2001:db8::1".

>> Notationally, we do know that an address written like FE80::1 is a
>>  full address (there is no plen specified).  It is possible to
>> assign FE80::0 as an address on an interface.
>>
>> Given that, how can the RFC4862 say "the link-local prefix
>> FE80::0"?  If so, how much trust can we put in that?  If this
>> approximation is permitted, which other approximations are allowed?
>> What does the point 2. actually meant?
>
> If you take it literally and assume that fe80::0 is an address
> instead of a prefix,

No IPv6 literal denotes a prefix without involving a /.

In IPv4: it's hard to say whether a notation like 192.168.0.0 is a /16
or a /24.

I think the same difficulty stands here.

Best is to say the plen by involving the "/".

> then it is a /128

That is another question: is FE80::/128 denoting an address or a prefix?

> those bits are 0 already. If you read it as a prefix then after point
> 2 you end up with the exact same 128 bits.
>
> However, RFC 4862 explicitly refers to "the well-known link-local
> prefix FE80::0 [RFC4291]"

That is a wrong notation.  There is no such thing as FE80::0 'prefix'.

Add that to the confusion between the fe80::/10 prefix and the fe80::/64
prefix.

You have a confusion with 3 ingredients here...

> and although it doesn't write it as a prefix, RFC 4291 section 2.4
> is very explicit that the prefix is fe80::/10.

Saying fe80::/10 is not same as saying fe80::0, sorry.

[...]
> The equation is perfectly fine. Do you really want to add "no, you
> can't single-handedly modify the input to fit the output, stick to
> the equation and the input provided to you"??? Please stop being
> silly.

?

[...]
> No, my head is quite clear today despite the attempted confusion by
> alternative interpretations.

Please clarify this: is it correct to say "prefix FE80::0"?  What is the
plen of it?  Just because it starts with "FE80" does not warrant a plen
of value 10.  Is it 9? Because after the 9th bit there are only 0s.  Or
is it 16?  Because there are two bytes in FE80.

If we dont know what the plen of "FE80::0" is, then it could be anything.

As such, what to do when the text says "2.  The left-most 'prefix
length' bits of the address are those of the link-local prefix."

Alex

>
> Cheers, Sander
>