Re: [netmod] 6021 ipv4-prefix

Juergen Schoenwaelder <> Thu, 18 April 2019 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D6AF120253 for <>; Thu, 18 Apr 2019 01:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LI2UuT9qxKMo for <>; Thu, 18 Apr 2019 01:06:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FE29120229 for <>; Thu, 18 Apr 2019 01:06:47 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id 37EEC8B2; Thu, 18 Apr 2019 10:06:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10032) with ESMTP id lUaejDi89WvP; Thu, 18 Apr 2019 10:06:46 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Jacobs University CA - G01" (verified OK)) by (Postfix) with ESMTPS; Thu, 18 Apr 2019 10:06:46 +0200 (CEST)
Received: from localhost ( []) by (Postfix) with ESMTP id 22BC9200CA; Thu, 18 Apr 2019 10:06:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10028) with ESMTP id 0Ggxl4vkXgGi; Thu, 18 Apr 2019 10:06:45 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by (Postfix) with ESMTPS id B41F0200C9; Thu, 18 Apr 2019 10:06:45 +0200 (CEST)
Received: from anna.localdomain ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 18 Apr 2019 10:06:45 +0200
Received: by anna.localdomain (Postfix, from userid 501) id A1DE4300865791; Thu, 18 Apr 2019 10:06:43 +0200 (CEST)
Date: Thu, 18 Apr 2019 10:06:43 +0200
From: Juergen Schoenwaelder <>
To: Mikael Abrahamsson <>
CC: <>
Message-ID: <>
Reply-To: Juergen Schoenwaelder <>
Mail-Followup-To: Mikael Abrahamsson <>,
References: <003301d4f498$4f593640$ee0ba2c0$> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: ( To (
Archived-At: <>
Subject: Re: [netmod] 6021 ipv4-prefix
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Apr 2019 08:06:52 -0000

On Thu, Apr 18, 2019 at 09:16:15AM +0200, Mikael Abrahamsson wrote:
> On Tue, 16 Apr 2019, wrote:
> > We might need to clarify this with the libyang folk.
> I see that Michal fixed the bug in libyang. Good.
> There is another thing I am unsure about.
> What is the netconf server supposed to do if a client tries to store
> in ipv4-prefix ? Or 2001:db8::1/64 in ipv6-prefix?
> Reading the canonical format description in 6021 one might intepret that the
> netconf server should just truncate the host bits and store these as
> and 2001:db8::/64 ? This means the netconf server actually
> stored something else than the client tried to commit (the resulting uint32
> and uint128 will have different information than was commited by the netconf
> client).

The values 2001:db8::1/64 and 2001:db8::/64 are both legal inputs but
they result in the same value. In situations where multiple inputs
resolve to the same value, we define a canonical representation. And
in the case of ipv6-prefix, the canonical representation is
2001:db8::/64. Hence, if you configure 2001:db8::1/64, then the server
will accept that input report the value back as 2001:db8::/64. The
main reason for having canonical formats is to make comparisons easy
and predictable. Think about xpath expressions - without a predictable
canonical representations, they would become rather complex since they
would have to deal with several different representations.
> Or should the netconf server throw an error if the client tries to commit
> data that is not according to the bit pattern described in the canonical
> format?

No, as explained above, the server should accept the input and convert
it into canonical format.

> I guess I am getting confused by the "canonical format" term being used in
> IPv6 for describing the ascii representation of the value, but both in IPv4
> and IPv6 it's also used to describe how the bits should be set (and not be
> set) depending on prefix/mask.

I am not sure what the problem is here. If your implementation stores
the address in binary format, then the canonical representation would
clear the unused bits - or you leave them in and you ignore them when
the server produces the canonical textual representation. This is
implementation detail (I would implement this by clearing the bits
also in the binary format but others may choose to do differently).

> Also, the IPv4 canoncical format representation doesn't describe at all the
> ascii representation, so for instance would be valid
> according to 6021. I haven't seen this to be a problem in reality though,
> because IPv4 addresses are typically "compressed" the same way, all the
> time. If we're revving 6021, then perhaps some text about ascii
> representation format should be to use the format used by the posix function
> inet_ntoa() ?

In both RFCs (6021 and 6991), I think that the pattern takes care of
leading zeros, i.e., will be rejected. I do not know
the POSIX specification of inet_ntoa(), the man pages I have (usually
close to the POSIX specification) do not detail the exact format. The
version agnostic functions are actually inet_ntop() and inet_pton()
and they may not even be a POSIX standard. And inet_ntop() and
inet_pton() likely do the right thing on most systems that also
implement RFC 5952. (The definition of inet_ntop() in the open group
specification [1] is not very tight about the textual format.)



Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>