Openthread: Spinel: confusing overload of Interface Identifier term
The choice of the name for the "Interface Identifier" (IID) field in the Spinel header could lead to confusion.
_IP Version 6 Addressing Architecture_ [RFC 4291] defines that term, "Interface Identifier" (also abbreviated IID), to signify the 64-bit remainder of a global scope unicast address after the subnet prefix.
In IPv6 terms, this field in the Spinel header is more closely related to the "zone index" concept described in Section 6 _Zone Indices of IPv6 Scoped Address Architecture_ [RFC 4007], except its scope is limited to the communication channel between an OS its Spinel couterpart NCP.
I wonder if renaming this field as Zone Index Number (ZIN) would be helpful in avoiding this confusion.
jhwoodyatt
All 5 comments
Excellent observation.
What about "interface index"?
darconeous
on 20 Mar 2017
Reading up on RFC 4007, but my gut feeling is that "Zone Index Number" might not imply the right scope.
darconeous
on 20 Mar 2017
In other words, the "IID" was intended to be considered (for all practical purposes) like a separate physical link.
darconeous
on 21 Mar 2017
I'm working on a proposed revision.
I have a hunch that precision here will turn out to be important when bringing this to IETF. People with all kinds of different ideas about how operating systems can implement IPv6 nodes by offloading some of their interface functions to co-processor hardware will be reviewing this document. Hopefully, we can avoid a lot of semantic confusion when they all start talking at once.
To be precise with the RFC 4007 text, a link-local unicast zone index (link-local has since become the only kind of unicast zone index, though there are still multiple kinds of multicast zone indices) is associated within an IPv6 node to a specific IPv6 link. Every interface has a link-local unicast IPv6 address, and the zone index is used within the scope of the node as an identifier for the link.
I suppose renaming this field "zone index number" might be a point of confusion because it could leave people wondering about the distinction between unicast and multicast zone indices.
How about "network link index" (NLI) instead?
jhwoodyatt
on 21 Mar 2017
Sounds like a winner to me.
darconeous
on 21 Mar 2017
Related issues
nibanks
路
6Comments
LuDuda
路
4Comments
simonlingoogle
路
6Comments
jwhui
路
5Comments
hubertmis
路
4Comments
Most helpful comment
I'm working on a proposed revision.
I have a hunch that precision here will turn out to be important when bringing this to IETF. People with all kinds of different ideas about how operating systems can implement IPv6 nodes by offloading some of their interface functions to co-processor hardware will be reviewing this document. Hopefully, we can avoid a lot of semantic confusion when they all start talking at once.
To be precise with the RFC 4007 text, a link-local unicast zone index (link-local has since become the only kind of unicast zone index, though there are still multiple kinds of multicast zone indices) is associated within an IPv6 node to a specific IPv6 link. Every interface has a link-local unicast IPv6 address, and the zone index is used within the scope of the node as an identifier for the link.
I suppose renaming this field "zone index number" might be a point of confusion because it could leave people wondering about the distinction between unicast and multicast zone indices.
How about "network link index" (NLI) instead?