Subject: [netmod] question regarding IPv6 address format / canonical

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Dec 2018 09:20:59 +0100 (CET)

Hi,

we've had an interesting interop problem, and we don't know if this is a 
client, server, or just interop problem. However, I thought I'd bring it 
to the attention here.

The server produced an output that was in the format of:

2a00:db8:1:2:3::5:0

When the client then asked for information about this object it used:

2a00:db8:1:2:3:0:5:0

The netconf server then returned no answer, because it didn't consider 
these to be the same (string match).

I have included what I think is relevant text below, it seems the client 
reformatted the address into canonical format. However, the description 
below seems to indicate that all those IPv6 types are ok. If the server 
must use canonical format, is there a MUST somewhere that says so?

What does it mean that something is a "canonical format"?

https://tools.ietf.org/html/rfc6021

typedef ipv6-address {
      type string {
...
      }
      description
       "The ipv6-address type represents an IPv6 address in full,
        mixed, shortened, and shortened-mixed notation.  The IPv6
        address may include a zone index, separated by a % sign.
        The zone index is used to disambiguate identical address
        values.  For link-local addresses, the zone index will
        typically be the interface index number or the name of an
        interface.  If the zone index is not present, the default
        zone of the device will be used.

        The canonical format of IPv6 addresses uses the compressed
        format described in RFC 4291, Section 2.2, item 2 with the
        following additional rules: the :: substitution must be
        applied to the longest sequence of all-zero 16-bit chunks
        in an IPv6 address.  If there is a tie, the first sequence
        of all-zero 16-bit chunks is replaced by ::.  Single
        all-zero 16-bit chunks are not compressed.  The canonical
        format uses lowercase characters and leading zeros are
        not allowed.  The canonical format for the zone index is
        the numerical format as described in RFC 4007, Section
        11.2.";
      reference
       "RFC 4291: IP Version 6 Addressing Architecture
        RFC 4007: IPv6 Scoped Address Architecture
        RFC 5952: A Recommendation for IPv6 Address Text Representation";
    }

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 Dec 2018 09:46:31 +0100

Hi Mikael,

> The server produced an output that was in the format of:

Correct - this is the canonical value.

> these to be the same (string match).

This is a bug in server implementation.

> What does it mean that something is a "canonical format"?

It is the value that the server (conceptually) uses internally. See sec. 9.1 in
RFC 7950.

Lada

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Dec 2018 09:51:53 +0100 (CET)

> Correct - this is the canonical value.

"Single all-zero 16-bit chunks are not compressed. "

So that doesn't seem like the canonical value to me?

>> When the client then asked for information about this object it used:

This is the canonical value according to my interpretation.

> This is a bug in server implementation.

Can you please elaborate? What is the bug here?

> It is the value that the server (conceptually) uses internally. See sec. 9.1 in

Ok, so if the server doesn't re-format and always uses string in the 
canonical format, that's a clear bug?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Dec 2018 10:11:44 +0100

> canonical format, that's a clear bug?

Yes. How the server does things internally does not matter but
comparisons must conceptually use the canonical format (and this is
why it is so important to define the canonical representation in type
definitions).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Dec 2018 14:46:29 +0100

> why it is so important to define the canonical representation in type

When we are at it: defining the canonical format for a derived type so
that it differs from the base type (as it is here) is problematic
because it is specified only in a description and tools thus cannot take
it into account automatically. So I expect problems like the one
reported by Mikael to be quite common - and if not for the IPv6 address,
then certainly for other derived types.

Lada