I'm less interested in the definition of an "interface" than I am in the bits in an Interface Identifier (i.e. the bottom 64 bits of an address).
There is a formal update of the addressing architecture on this very point. https://www.rfc-editor.org/rfc/rfc7136.html#section-5 says: ...the method of generating IIDs for specific link types MAY define some local significance for certain bits. In all cases, the bits in an IID have no generic semantics; in other words, they have opaque values. In fact, the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context. Note the references to "local". If all hosts on a link agree about some magic semantics in the IID, and even agree to call the whole address a SID, it's consistent with the addressing architecture *as long as it stays local*. And don't mess with the semantics of the top 64 bits. Regards Brian Carpenter On 07-Oct-21 23:32, Robert Raszuk wrote: > Nick, > > Ok let's zoom on your point. > > *IPv6 Addressing Architecture RFC says: * > > IPv6 addresses are 128-bit identifiers for interfaces and sets of > interfaces (where "interface" is as defined in Section 2 of [IPV6]). > There are three types of addresses: > > Unicast: An identifier for a single interface. A packet sent to a > unicast address is delivered to the interface identified > by that address. > > So what is left to check is what the definition of the "interface" is. > > Some folks refer to the definition of the interface as stated verbatim in > *RFC2460/RFC8200: * > > 2. Terminology > > interface - a node's attachment to a link. > > _However we all know that outside of IPv6, SRv6 there are many more types of > interfaces which are not attached to any link. We use them every day. _ > > *RFC7223* did decent job trying to capture what the interface means and divided the interfaces into system defined and user defined: > > 1.1. Terminology > > The following terms are used within this document: > > o system-controlled interface: An interface is said to be system- > controlled if the system creates and deletes the interface > independently of what has been explicitly configured. Examples > are interfaces representing physical hardware that appear and > disappear when hardware (e.g., a line card or hot-pluggable > wireless interface) is added or removed. System-controlled > interfaces may also appear if a certain functionality is enabled > (e.g., a loopback interface might appear if the IP protocol stack > is enabled). > > o user-controlled interface: An interface is said to be user- > controlled if the creation of the interface is controlled by > adding explicit interface configuration to the running > configuration datastore and the removal of the interface is > controlled by removing explicit interface configuration from the > running configuration datastore. Examples are VLAN interfaces > configured on a system-controlled Ethernet interface. > > > So please let's consider reality here, not some badly defined dogmas from the > stone age. > > And if we will, then the SRv6 destination address is the address of a special > virtual interface in the system. The meaning of the bits outside of the > routable prefix is up to the interface creator. > > If that single sentence is missing in any spec it can be added but to me this > is obvious. > > Cheers, > R. > > > On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard <n...@foobar.org > <mailto:n...@foobar.org>> wrote: > > Eduard Metz wrote on 07/10/2021 10:03: > > For my understanding, apart from that the (definition of) SID may not be > > aligned with the literal text in below RFCs, what is the real problem? > > the concept of an ipv6 destination address is deeply ingrained in the > ipv6 protocol. So, looking at this from a deployment point of view, why > does an expediency of the sort suggested in this draft justify changing > the semantics of one of the cornerstones of the ipv6 protocol? > > The authors would need to justify this protocol modification on the same > sort of basis that any other ID might be expected to do. E.g. for > starters, including an analysis of how this would impact or potentially > impact any other RFC which references or implicitly depends on > currently-defined ipv6 addressing semantics. > > Nick > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6> > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
