Re: [netmod] 6021 ipv4-prefix

[tom petch <[e-mail]>]

----- Original Message -----
From: "Kristian Larsson" <[e-mail]>
Sent: Thursday, April 25, 2019 11:07 PM

> On 2019-04-25 23:51, 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.
>
> Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type
> ip-prefix (or ip6-prefix).
>
> It would be interesting to hear Martins opinion on this.

Kristian

No way can I approach being Martin but ..

this topic has been active on the 6man list and to some extent on the
main IETF list with one very active participant arguing that because
widely-used implementations allow something that the RFC does not
(making use of the 64 zero bits of fe80::/10) then the RFC is wrong and
should be changed.  Happily this seems to be a minority view but, like a
hydra, the thread keeps coming back to life in another form see e.g.

Re: encoding link ID in link-local addrs
Re: about violation of standards
Globally Unique Link Local Addresses
mailing list activity
who should try to explain
who shouuld update

even

Re: [Technical Errata Reported] RFC7421 (5699)

In fact almost any post to 6man in the past 10 days (of which there are
many)

Tom Petch

> Kind regards,
>     Kristian.
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod