Subject: Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt

From: Jürgen Schönwälder <[email-masked]>
Date: Sun, 1 Aug 2021 13:30:01 +0200

The description statements in RFC 6991 talk about a zone index, i.e.,
they assume the zone index is numeric (which kind of follows from my
reading of RFC 4007).

The pattern is flexible enough to accept a string as well (e.g., an
interface name). In other words, a server may accept 'fe80::1%lo0' as
valid input on an edit-config put it will return 'fe80::1%0' on a
get-config since the numeric zone index is the canonical format
(assuming the lo0 interface has the interface index 0).

/js

On Wed, Jul 28, 2021 at 10:00:23AM +1200, Brian E Carpenter wrote:
> Jürgen,
> 
> We are not disagreeing. These are exactly the sort of use cases that also
> motivate RFC6874 and RFC6874bis. 
> 
> But I have a question. In the management plane, do you think that the
> zone index (an integer) is the item of interest, or a zone identifier
> (a string)? The description at
> https://datatracker.ietf.org/doc/html/rfc6991#page-20
> only says that the numerical format is "canonical".
> 
> Regards
>    Brian
> 
> On 28-Jul-21 09:07, Jürgen Schönwälder wrote:
> > On Wed, Jul 28, 2021 at 08:04:16AM +1200, Brian E Carpenter wrote:
> >> On 26-Jul-21 23:49, tom petch wrote:
> >>> From: ipv6 <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
> >>> Sent: 25 July 2021 00:44
> >>>
> >>> There's an "interesting" issue there, especially for IPv6, which is that the interface ID (or "zone index", per RFC4007) has no meaning outside the host. So it really shouldn't need to be sent on the wire in normal circumstances.
> >>>
> >>> (The conversation around RFC6874bis is slightly relevant.)
> >>>
> >>> <tp>
> >>> Brian
> >>>
> >>> As I may have said before, the YANG Types RFC6991 provides types for IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone 
> types with a suffix 'no-zone' on the type name.  I see evidence that most 
> authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.
> >>
> >> Makes sense. The reply I just sent to Christian Amsüss probably applies to YANG too. Sending a zone index to another host is rarely meaningful or useful.
> >>
> > 
> > YANG was designed for network management purposes and there are quite
> > some use cases where communicating the zone index is somewhat essential:
> > 
> > - If you want to debug a problem, you likely need to know to which
> >   link a link-local address belongs.
> > - If you want to generate statistics for protocols using link-local
> >   addresses, you likely need to know to which links the link-local
> >   addresses belongs.
> > - If you want to configure a service to use a certain link-local
> >   address on a certain link, you may have to include the proper zone
> >   index.
> > - If an IP address is used to index lists, things can fall apart if
> >   you end up with duplicate link-local addresses on different links.
> > 
> > Whether we should have picked different names for the types may be
> > debatable but at the end it is the YANG module author's responsibility
> > to pick the appropriate types.
> > 
> > In other words, network management applications often need to be aware
> > of zone indexes in order to do the right thing. This is different from
> > end user applications (that usually have no topological awareness).
> > 
> > /js
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
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: Michael Richardson <[email-masked]>
Date: Sun, 01 Aug 2021 16:41:01 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> The few zones that I have seen have been alphanumeric and not numeric
    >> so making the numeric form canonical has always puzzled me.

    > You should widen your horizons and look at Windows. The index is more
    > fundamental than the identifier, exactly as RFC4007 says. Portable code
    > needs to dig out the index (an integer).

Under the hood, they are pretty much all an integer.

I'm happy to add something to the Interface format for a zone, but I think
that to get this past reviews, it will need a clearly articulated use case.

I also think that we could add this easily to the Interface format if we needed to
in a revision.

(WGLC closed on Friday, I am just posting the revised version now)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Aug 2021 16:43:08 -0400

> (assuming the lo0 interface has the interface index 0).

as a nit,
lo0/lo is almost always 1, because "0" means no scope :-)

[If we could go back to 1985 and change BSD, we could make them name it lo1 :-)]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Aug 2021 09:15:43 +1200

> (assuming the lo0 interface has the interface index 0).

This still makes me uncomfortable. The zone identifier syntax definition.
in RFC4007 is pretty vague. If an implementer chooses to ignore the
SHOULD on page 16, it seems that a valid name for interface index 7
could be "6". That's why "canonical" is a bit weak. (Neither Windows
nor Linux allow anything that silly, of course.)

To be precise, consider these statements in RFC4007 page 16:

   An implementation SHOULD support at least numerical indices that are
   non-negative decimal integers as <zone_id>.
   ...
   An implementation MAY support other kinds of non-null strings as
   <zone_id>.
   ... the format MUST be used only within a
   node and MUST NOT be sent on the wire unless every node that
   interprets the format agrees on the semantics.

Remotely, there is no way to know that on my Linux machine,
%wlp2s0 and %3 are the same thing.

   Brian
 
>>>>> There's an "interesting" issue there, especially for IPv6, which is 
that the interface ID (or "zone index", per RFC4007) has no meaning outside the host. So it really shouldn't need to be sent on the wire in normal 
circumstances.
>>>> Makes sense. The reply I just sent to Christian Amsüss probably 
applies to YANG too. Sending a zone index to another host is rarely meaningful or useful.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 1 Aug 2021 23:26:09 +0200

On 1. Aug 2021, at 22:43, Michael Richardson <[email-masked]> wrote:
> 1985

More like 1981/1982...
https://elists.isoc.org/pipermail/internet-history/2021-January/006916.html

Back to the subject: I’m happy with the tags in this specification being the equivalent of the YANG no-zone types.
I’d rather wait for the dust on RFC6874bis to settle before putting in zones, and I still think CRIs (draft-ietf-core-href) are the place to do this.

If we do put them in here (draft-ietf-cbor-network-addresses), we need to put them into the address and the interface format; maybe not into the prefix format (but I’m not so sure about that).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Aug 2021 18:12:21 -0400

<#secure method=pgpmime mode=sign>

    > Back to the subject: I’m happy with the tags in this specification
    > being the equivalent of the YANG no-zone types.

okay, do you think this needs some text to explain this?

    > I’d rather wait for the dust on RFC6874bis to settle before putting in
    > zones, and I still think CRIs (draft-ietf-core-href) are the place to
    > do this.

how long will it be for the dust on RFC6874bis to settle?
Should we ask for IESG review now?
It seems that we could do this in parallel.

    > If we do put them in here (draft-ietf-cbor-network-addresses), we need
    > to put them into the address and the interface format; maybe not into
    > the prefix format (but I’m not so sure about that).

Yes, you are right Address format too.
I think we can revise (extend) the document to add what we need, once we
understand the use cases better.

The only reason to stop is if we think we got something wrong.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Aug 2021 18:21:36 -0400

> nor Linux allow anything that silly, of course.)

Is this what you mean... picking on an interface I'm not using today:

%ip link ls dev virbr0
15: virbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:14:c7:73 brd ff:ff:ff:ff:ff:ff
%sudo ip link set name "15" dev virbr0
%ip link ls dev virbr0
Device "virbr0" does not exist.

%ip link ls dev 15
15: 15: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:14:c7:73 brd ff:ff:ff:ff:ff:ff

    > non-negative decimal integers as <zone_id>.

Oh.

%sudo ip link set name "-15" dev "15"
%ip link ls dev -15
15: -15: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:14:c7:73 brd ff:ff:ff:ff:ff:ff

    > interprets the format agrees on the semantics.

:-)

    > %wlp2s0 and %3 are the same thing.

Agreed.
But, SNMP and YANG know.
So if you are doing CORECONF, then you might want to encode stuff.

And if you want to set an IPv6-LL address for a daemon to listen on, then you
need the scope.  That seems to be the place where we need this, and this
would seem to be the use case.

(Looking back at my code involving IPsec configuration over LLv6, I see that
actually, I am in trouble if v6LL addresses are ever duplicated, as I don't
send the scope)

For the Interface form, adding a third (optional) field for scope is easy.
I am open to suggestions for handling the Address format.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Aug 2021 10:33:04 +1200

> how long will it be for the dust on RFC6874bis to settle?

That's out of our hands because it includes consulting with the browser community.

There's also the question of whether the name or the number is "canonical". As you'll have noticed, I don't like ambiguity on this point.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Aug 2021 10:56:02 +1200

> I am open to suggestions for handling the Address format.

It gets a bit messy. If you transmit the zone id as a string, you
could use [address, 'eth0'] which would be distinguishable from the
other cases.

By the way, I love the thought of interface -15. RFC4007 is looking
a bit sickly to me.

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Aug 2021 03:24:28 +0200

> So if you are doing CORECONF, then you might want to encode stuff.

Yes, and thanks to the YANG libraries, CORECONF can do that today.

Grüße, Carsten

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 2 Aug 2021 09:08:39 +0200

Brian,

let me see whether I understand your concern. You seem to be concerned
that assigning the name "5" to an interface with interface index 7
leads to an ambiguity. Well, thats likely true since we do not
syntactically distinguish between the number 5 and the name "5". I
would expect that implementations interpret fe80::1%5 as referring to
interface 5 and not 7 (but this perhaps deserves to be clarified, if
it is a number the number is interpreted as an interface index and not
as an interface name). I assume the same 'ambiguity' may exist on CLI
tools, I would have to go and try out what they actually do.

Regarding your statement "Remotely, there is no way to know that on my
Linux machine, %wlp2s0 and %3 are the same thing.", please note that
applications having access to the IF-MIB or the ietf-interfaces YANG
module or a proprietary API exposing interface information will
understand how interface names map to interface indexes.

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Aug 2021 08:00:26 +1200

> tools, I would have to go and try out what they actually do.

Michael Richardson already gave some examples for Linux. 
 
> understand how interface names map to interface indexes.

But not if the user has chosen to change some interface names, surely?
The mapping is not algorithmic in that case, and any names held
remotely in the management plane could be out of date. IMHO it remains
very inadvisable to export the names. I'd advocate making the use of
interface numbers mandatory rather than "canonical".

   Brian

---

From: Dave Thaler <[email-masked]>
Date: Mon, 2 Aug 2021 21:47:38 +0000

I can say that Windows uses integers only, it does not use (non-integer) strings for zone-ids, and so does not have ambiguity.
Note that the zone id on a link local like fe80::1 is NOT an interface index per se, it's a link index as explained
in RFC 4007.  On Windows (and most other platforms, I suspect), the link index defaults to be identical to the interface index,
as recommended in that RFC.

Dave

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Jürgen Schönwälder
Sent: Monday, August 2, 2021 12:09 AM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]; 6MAN <[email-masked]>; tom petch <[email-masked]>
Subject: Re: changes in draft-ietf-cbor-network-addresses-05.txt

Brian,

let me see whether I understand your concern. You seem to be concerned that assigning the name "5" to an interface with interface index 7 leads to an ambiguity. Well, thats likely true since we do not syntactically distinguish between the number 5 and the name "5". I would expect that implementations interpret fe80::1%5 as referring to interface 5 and not 7 (but this perhaps deserves to be clarified, if it is a number the number is interpreted as an interface index and not as an interface name). I assume the same 'ambiguity' may exist on CLI tools, I would have to go and try out what they actually do.

Regarding your statement "Remotely, there is no way to know that on my Linux machine, %wlp2s0 and %3 are the same thing.", please note that applications having access to the IF-MIB or the ietf-interfaces YANG module or a proprietary API exposing interface information will understand how interface names map to interface indexes.

/js

On Mon, Aug 02, 2021 at 09:15:43AM +1200, Brian E Carpenter wrote:
> > The description statements in RFC 6991 talk about a zone index, 
> > i.e., they assume the zone index is numeric (which kind of follows 
> > from my reading of RFC 4007).
> > 
> > interface name). In other words, a server may accept 'fe80::1%lo0' 
> > as valid input on an edit-config put it will return 'fe80::1%0' on a 
> >> We are not disagreeing. These are exactly the sort of use cases 
> >> that also motivate RFC6874 and RFC6874bis.
> >>
> >> But I have a question. In the management plane, do you think that 
> >> the zone index (an integer) is the item of interest, or a zone 
> >> identifier (a string)? The description at
> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> >> atatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6991%23page-20&amp;data=04%7C
> >> 01%7Cdthaler%40microsoft.com%7C97af2d86016a459f696e08d9558475ae%7C7
> >> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637634849687636890%7CUnkn
> >> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> >> WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=chsLlIl1jF0ur69C40qQmykxHdMOFVVm
> >> n%2F76Dz5Tels%3D&amp;reserved=0 only says that the numerical format 
> >> is "canonical".
> >>
> >> Regards
> >>    Brian
> >>
> that the interface ID (or "zone index", per RFC4007) has no meaning 
> outside the host. So it really shouldn't need to be sent on the wire in normal circumstances.
> >>>>>
> >>>>> As I may have said before, the YANG Types RFC6991 provides types 
> >>>>> for IPv4 and IPv6 addresses both with a zone index.  It also 
> >>>>> provides no-zone
> >> types with a suffix 'no-zone' on the type name.  I see evidence 
> >> that most authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.
> >>>>
> >>> YANG was designed for network management purposes and there are 
> >>> quite some use cases where communicating the zone index is somewhat essential:
> >>>
> >>> debatable but at the end it is the YANG module author's 
> >>> responsibility to pick the appropriate types.
> >>>
> >>> In other words, network management applications often need to be 
> >>> aware of zone indexes in order to do the right thing. This is 
> >>> different from end user applications (that usually have no topological awareness).
> >>>
> >>> /js
> >>>
> >>
> >> -------------------------------------------------------------------
> >> - IETF IPv6 working group mailing list [email-masked] Administrative 
> >> Requests: 
> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> >> ww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Cdthaler%
> >> 40microsoft.com%7C97af2d86016a459f696e08d9558475ae%7C72f988bf86f141
> >> af91ab2d7cd011db47%7C1%7C0%7C637634849687636890%7CUnknown%7CTWFpbGZ
> >> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> >> 0%3D%7C1000&amp;sdata=Ft619aB5dy1pEjf%2BKLuLROiYuvDZzdzsLtnF8tZ43sQ
> >> %3D&amp;reserved=0
> Administrative Requests: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Cdthaler%40micr
> osoft.com%7C97af2d86016a459f696e08d9558475ae%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637634849687636890%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> ;sdata=Ft619aB5dy1pEjf%2BKLuLROiYuvDZzdzsLtnF8tZ43sQ%3D&amp;reserved=0

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C97af2d86016a459f696e08d9558475ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637634849687646845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9lZP9EDMFdnwqoZK5R07PNAfgk5SjhTjKVWEscnBBWI%3D&amp;reserved=0>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C97af2d86016a459f696e08d9558475ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637634849687646845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WiI313YbpnNllsVBQ4u0jNCA5yf7owmWWyU74lr49IU%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 3 Aug 2021 07:53:27 +0200

> But not if the user has chosen to change some interface names, surely?

In the IF-MIB, ifName is read-only (so you can't change it via SNMP,
but this says nothing about other APIs) and ifIndex is used as the key
of the table. In ietf-interfaces, the config true interface/name is
used as the key of the list and the interface/if-index is a config
false property of the list. This change to refer to interfaces by name
instead of a number was the result of a long discussion and it
reflects that most routers and bridges use names to refer to
interfaces (and so does the *nix world).

> interface numbers mandatory rather than "canonical".

The mapping is on many systems never purly algorithmic as software can
choose how newly created interfaces are named. And some people want
interface named by the customer networks they connect, others want to
have semantically meaningful vlan names. And lets not forget that
there was an interesting time where Linux could end up with different
interface names for the same physical interfaces on every reboot that
caused some serious surprises.

Synchronization of config changes is a general problem in the network
management world and not specific to changes of interface names. There
are boxes that disable or discourage access to the CLI so that all
changes go through a management daemon and then good management
protocols can take care. Some people moved to streaming approaches to
reduce the synchonization pains, where boxes are configured to push
all changes to management systems.

Given that ietf-interfaces does key interfaces by name (which reflects
the common practice of network operators to refer to router interfaces
by name), it seems the ship has sailed.

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Aug 2021 09:04:11 +1200

> by name), it seems the ship has sailed.

In some contexts, but not all. In the cbor-network-addresses context,
if we do anything, it would seem wise to support an integer and a string
format, to cover the bases. But I'd be inclined to leave it as a future
extension.

    Brian

>>>>>> authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to 
have specified 'ip-address' and 'ip-address-zone' rather than ip-address' 
and io-address-no-zone'.

---

From: Erik Kline <[email-masked]>
Date: Fri, 6 Aug 2021 17:37:38 -0700

> format, to cover the bases. But I'd be inclined to leave it as a future

Deferring for another document (and, presumably, some more clearly
articulated motivation) makes sense to me.  I'm sorry I triggered
the digression, though the conversation has been interesting.

--

WRT to names vs indices vs <other>, I think 4007 S6 defining "zone index"
as a core concept is fairly straightforward, though I think it's things
like RFCs 3493 and 3542 that make these unsigned integer indices the de
facto standard.  (if_nametoindex() is just a nicety, as every other
zone-aware API call uses unsigned ints)