Re: [netmod] 6021 ipv4-prefix

[Ladislav Lhotka <[e-mail]>]

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) that the host bits
should be zero, i.e. no strict requirement.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67