Re: [netmod] 6021 ipv4-prefix

Kristian Larsson <kristian@spritelink.net> Fri, 26 April 2019 10:57 UTC

Return-Path: <kristian@spritelink.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BF71200A4 for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 03:57:04 -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, SPF_PASS=-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 HD7MVIBetQaY for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 03:57:01 -0700 (PDT)
Received: from Mail1.SpriteLink.NET (Mail1.SpriteLink.NET [195.182.5.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A5E120033 for <netmod@ietf.org>; Fri, 26 Apr 2019 03:57:01 -0700 (PDT)
Received: from mbp.local (c-bb9de253.014-82-73746f13.bbcust.telenor.se [83.226.157.187]) by Mail1.SpriteLink.NET (Postfix) with ESMTPSA id 2D5063F482 for <netmod@ietf.org>; Fri, 26 Apr 2019 12:56:58 +0200 (CEST)
To: netmod@ietf.org
References: <003301d4f498$4f593640$ee0ba2c0$@gmail.com> <alpine.DEB.2.20.1904180906360.3490@uplift.swm.pp.se> <20190418080643.gcdi5x4dtn64adwc@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904181128480.3490@uplift.swm.pp.se> <20190418102604.y5wyqflcudiywj2i@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904181251000.3490@uplift.swm.pp.se> <20190418111241.5csf5kkgwgxwtsnm@anna.jacobs.jacobs-university.de> <227a2452-69f9-6786-2643-822e70dc636d@spritelink.net> <20190425215134.pabdl3bbbjoivbaj@anna.jacobs.jacobs-university.de> <24fff697cde3ac2e0c9a09cf2dfa1153ca61bd90.camel@nic.cz>
From: Kristian Larsson <kristian@spritelink.net>
Message-ID: <5d6b915d-2b6b-2844-6343-5e42abe01e3b@spritelink.net>
Date: Fri, 26 Apr 2019 12:56:57 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <24fff697cde3ac2e0c9a09cf2dfa1153ca61bd90.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/09nQUKm7Gqvcue15jZeHa4O1NCI>
Subject: Re: [netmod] 6021 ipv4-prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 10:57:04 -0000


On 2019-04-26 09:39, Ladislav Lhotka wrote:
> On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
>> On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
>>>
>>> On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
>>>> On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
>>>>> On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
>>>>>> On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
>>>>>> +17.4 is not an integer, so this is an error (not because of the + but
>>>>>> because of the . followed by additional digits). +17 is I think a
>>>>>> valid
>>>>>> integer value but the + will be dropped in the canonical
>>>>>> representation.
>>>>>
>>>>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
>>>>> the
>>>>> prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>>>>> rounded
>>>>> if an integer input is expected?
>>>>
>>>> The non-prefix bits are irrelevant for the prefix and the canonical
>>>> format has the non-prefix bits all set to zero. I understand that you
>>>> prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
>>>> consider this as valid input that can be safely interpreted to mean
>>>> 2001:db8::0/64.
>>>
>>> Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
>>> error, is that implementation incorrect?
>>>
>>
>> I think so. The types do not require that non-prefix bits are zero
>> when a value is received. However, a server must report the canonical
>> value, in this case 2001:db8::/64.
> 
> Agreed. The description only says (and only for ipv6-prefix

I think it says it for ipv4-prefix too:

   ...
   The canonical format of an IPv4 prefix has all bits of
   the IPv4 address set to zero that are not part of the
   IPv4 prefix.";


> ) that the host bits
> should be zero, i.e. no strict requirement.
There is no strict requirement of what? Accepting the data? Throwing an 
error? Ambiguity of what you are referencing makes it impossible for me 
to parse your sentence. Please elaborate.

I'm having trouble unifying the following:
- Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid 
input that can safely be interpreted to mean 2001:db8::/64
- NSO instead treats 2001:db8::1/64 as a syntax error

If 6021+6991 says it is valid input, then NSO must accept it, no?

Or does 6021+6991 say such a value MAY be treated as valid input? And if 
it does accept it, it must then store or at least always return it in 
the canonical format?

    kll